From diffserv-admin@ietf.org Mon May 1 02:08: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 CAA21502; Mon, 1 May 2000 02:08: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 BAA07402; Mon, 1 May 2000 01: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 BAA07374 for ; Mon, 1 May 2000 01:37:09 -0400 (EDT) Received: from smtppop3.gte.net (smtppop3.gte.net [207.115.153.22]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA14220 for ; Mon, 1 May 2000 01:37:08 -0400 (EDT) Received: from 10 (lsanca1-ar5-216-197.dsl.gtei.net [4.33.216.197]) by smtppop3.gte.net with SMTP ; id AAA22549705 Mon, 1 May 2000 00:36:18 -0500 (CDT) Message-ID: <000501bfb32f$4ce87200$c5d82104@dsl.gtei.net> From: "Bill Courtney" To: "Pawan Goyal" Cc: , , References: <200004302252.RAA06543@mangal.csres.utexas.edu> Subject: Re: [Diffserv] issues with RFC 2598 Date: Sun, 30 Apr 2000 22:37: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.2314.1300 X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2314.1300 Content-Transfer-Encoding: 7bit Sender: diffserv-admin@ietf.org Errors-To: diffserv-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Diffserv Discussion List X-BeenThere: diffserv@ietf.org Content-Transfer-Encoding: 7bit Pawal, I spoke too tersely and identified the wrong algorithm. I should have said "WF2Q+" rather than "WF2Q". Also, the start and finish times in WF2Q+ are kept "per session" (not necesarily "per queue"). I was assuming that each session had a FIFO and that a representative of each session is kept in one of two heaps, the ineligible heap or the eligible heap, based on start time versus virtual time. (Thus my use of "queue" rather than "session".) Clearly, this is my own interpretation of how one might implement WF2Q+, and is not something that Bennett and Zhang said in "Hierarchical Packet Fair Queuing Algorithms," although in that paper they do discuss maintaining only one start and finish time per session. My point in my previous posting was that with this algorithm (WF2Q+), very good behavior is obtained and the finish time for a packet is not necessarily calculated or even knowable when a packet arrives. Following up on this notion, I wondered whether using a definition for EF PHB that spoke of a finish time only for the packet at the head of the EF aggregate queue might not give us a simple and reasonable criterion for deciding when a scheduler is compliant. I then offered a simple criterion. Whether it's reasonable remains to be seen. I apologize to Bennett & Zhang for misidentifying WF2Q and WF2Q+ in my previous posting. I apologize in advance if anything in this posting misrepresents their work. Bill ----- Original Message ----- From: Pawan Goyal To: Bill Courtney Cc: ; ; Sent: Sunday, April 30, 2000 3:52 PM Subject: Re: [Diffserv] issues with RFC 2598 > > 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. > > > > The assertion that WF2Q assigns a start and finish tag to each queue rather > than each packet is incorrect. It can be shown that if a modification is made > to assign start and finish tags to each queue rather than packet, then the > fairness and delay properties of WF2Q no longer hold. > > Pawan > _______________________________________________ diffserv mailing list diffserv@ietf.org http://www1.ietf.org/mailman/listinfo/diffserv Archive: http://www-nrg.ee.lbl.gov/diff-serv-arch/ From mailman-owner@ietf.org Mon May 1 05:01: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 FAA22415 for ; Mon, 1 May 2000 05:01: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 FAA10874 for ; Mon, 1 May 2000 05:01:18 -0400 (EDT) Date: Mon, 1 May 2000 05:01:18 -0400 (EDT) Message-Id: <200005010901.FAA10874@optimus.ietf.org> From: mailman-owner@ietf.org Subject: ietf.org mailing list memberships reminder To: diffserv-archive@ns.ietf.org X-No-Archive: yes Precedence: bulk X-Mailman-Version: 1.0 Precedence: bulk List-Id: Diffserv Discussion List This is a reminder, sent out once a month, about your ietf.org mailing list memberships. It includes your subscription info and how to use it to change it or unsubscribe from a list. You can visit the URLs to change your membership status or configuration, including unsubscribing, setting digest-style delivery or disabling delivery altogether (e.g., for a vacation), and so on. In addition to the URL interfaces, you can also use email to make such changes. For more info, send a message to the '-request' address of the list (for example, diffserv-request@ietf.org) containing just the word 'help' in the message body, and an email message will be sent to you with instructions. If you have questions, problems, comments, etc, send them to mailman-owner@ietf.org. Thanks! Passwords for diffserv-archive@optimus.ietf.org: List Password // URL ---- -------- diffserv@ietf.org aUvt http://www1.ietf.org/mailman/options/diffserv/diffserv-archive@optimus.ietf.org From diffserv-admin@ietf.org Tue May 2 09:13: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 JAA00279; Tue, 2 May 2000 09:13: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 IAA17006; Tue, 2 May 2000 08:27: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 IAA16977 for ; Tue, 2 May 2000 08:27: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 IAA28787 for ; Tue, 2 May 2000 08:27:24 -0400 (EDT) Received: from acharny_pc2 ([161.44.189.106]) by pilgrim.cisco.com (8.8.8-Cisco List Logging/8.8.8) with ESMTP id IAA21846; Tue, 2 May 2000 08:26:48 -0400 (EDT) Message-Id: <4.2.0.58.20000502075744.00d9bd50@pilgrim.cisco.com> X-Sender: acharny@pilgrim.cisco.com X-Mailer: QUALCOMM Windows Eudora Pro Version 4.2.0.58 Date: Tue, 02 May 2000 08:30:03 -0400 To: "Bill Courtney" , From: Anna Charny Subject: Re: [Diffserv] issues with RFC 2598 Cc: , leboudec@epfl.ch In-Reply-To: <000701bfb2e6$5e03e900$c5d82104@dsl.gtei.net> References: <4.2.0.58.20000417234549.00ca2cb0@pilgrim.cisco.com> <4.2.0.58.20000427204001.00d671b0@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 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/ From diffserv-admin@ietf.org Tue May 2 10:28: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 KAA01907; Tue, 2 May 2000 10:28: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 JAA17845; Tue, 2 May 2000 09: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 JAA17748 for ; Tue, 2 May 2000 09:31:15 -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 JAA00670 for ; Tue, 2 May 2000 09:31:13 -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 GAA04113 for ; Tue, 2 May 2000 06:31:14 -0700 (PDT) Received: by nt-exchange1.pmc-sierra.bc.ca with Internet Mail Service (5.5.2650.21) id <2094QB1B>; Tue, 2 May 2000 06:31:14 -0700 Message-ID: <336ECDAFDF7DD311B9E30090277AEE4101B40504@nt-exchange-bby.pmc-sierra.bc.ca> From: Shahram Davari To: diffserv@ietf.org Subject: RE: [Diffserv] issues with RFC 2598 Date: Tue, 2 May 2000 06:28:31 -0700 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: text/plain; charset="iso-8859-1" Sender: diffserv-admin@ietf.org Errors-To: diffserv-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Diffserv Discussion List X-BeenThere: diffserv@ietf.org 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/ From diffserv-admin@ietf.org Tue May 2 12:52: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 MAA05062; Tue, 2 May 2000 12:52: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 MAA19967; Tue, 2 May 2000 12:06: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 MAA19936 for ; Tue, 2 May 2000 12:06:17 -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 MAA04059 for ; Tue, 2 May 2000 12:06:13 -0400 (EDT) Received: by PACKETBDC with Internet Mail Service (5.5.2448.0) id ; Tue, 2 May 2000 12:11:58 -0400 Message-ID: <7F4AC78738EAD2119D86009027626C6D07EE91@PACKETBDC> From: Jon Bennett To: "'pawang@surya.csres.utexas.edu'" Cc: "'the.courtneys@gte.net'" , "'diffserv@ietf.org'" Subject: RE: [Diffserv] issues with RFC 2598 Date: Tue, 2 May 2000 12:11: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 (Sorry for not responding yesterday, but I did not receive messages from the list over the weekend and had to have someone tell me to check the archive, and yes I do have message delivery turned on, and have received messages since, although I note that at least one of the working group chairs still has message delivery disabled..........) Pawan, Pawan Goyal writes >> 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. >> > >The assertion that WF2Q assigns a start and finish tag to each queue rather >than each packet is incorrect. It can be shown that if a modification is made >to assign start and finish tags to each queue rather than packet, then the >fairness and delay properties of WF2Q no longer hold. > >Pawan While we only presented WF2Q+ with the use of per session rather than per-packet timestamps it would apply equally to WF2Q. It certainly does not impact on the fairness or delay properties of WF2Q. That it is valid to maintain a timestamp for just the head of the queue is in fact the basis of our presentation of the hierarchical implementation of WF2Q(+). While per-queue timestamps may result in a slightly different output pattern of packets compared to per-packet timestamps, the output is still *valid*, in that it still maintains all the fairness and delay guarantees. [NOTE :In the interests of total accuracy this strictly true only for the case of Rate Proportional Processor Sharing (RPPS), for the non-RPPS case there are a couple of ways this can be addressed in those cases where it would actually matter. Since this is a very esoteric point I will not go into the details. I will add that even in the non-RPPS case this would only be an issue the presence of highly sophisticated rate/delay allocation policies employing complex Call Admission Control (CAC) and very strict leaky bucket *drop* policing of the type that would only be used for traffic with per-flow reservations. So this would not be an issue for an aggregate service such as diff-serv. If anyone has any questions on this I'll be happy to take them directly.] 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, 2 May 2000 12:40:48 -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 MAA04787 for ; Tue, 2 May 2000 12:40:47 -0400 (EDT) Received: by PACKETBDC with Internet Mail Service (5.5.2448.0) id ; Tue, 2 May 2000 12:46:28 -0400 Message-ID: <7F4AC78738EAD2119D86009027626C6D07EE92@PACKETBDC> From: Jon Bennett To: "'the.courtneys@gte.net'" Cc: "'pawang@surya.csres.utexas.edu'" , "'Kent.Benson@tellabs.com'" , "'diffserv@ietf.org>'" Subject: Re: [Diffserv] issues with RFC 2598 Date: Tue, 2 May 2000 12:46:22 -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 Bill Courtney writes >I spoke too tersely and identified the wrong algorithm. I should have said >"WF2Q+" rather than "WF2Q". Also, the start and finish times in WF2Q+ are >kept "per session" (not necesarily "per queue"). For the record Pawan was right to complain (and I missed the point he was making in my first response) that if you just make the change of implementing per-queue timestamps with the *fluid* virtual time function of WF2Q that things could go wrong. While this can be fixed in much the same way as the non-RPPS case can be handled, his statement was in fact correct. I suspect that it would be best if everyone just assumed that WF2Q+ was implied anytime implementation was being discussed unless it is explicitly stated that the fluid model is being discussed to avoid the confusion that keeps resulting. >I was assuming that each >session had a FIFO and that a representative of each session is kept in one >of two heaps, the ineligible heap or the eligible heap, based on start time >versus virtual time. (Thus my use of "queue" rather than "session".) >Clearly, this is my own interpretation of how one might implement WF2Q+, and >is not something that Bennett and Zhang said in "Hierarchical Packet Fair >Queuing Algorithms," although in that paper they do discuss maintaining only >one start and finish time per session. Actually the two heap implementation has a problem when lots of ineligible sessions become eligible, because you may need to move everyone from one heap to the other in a single packet time. We present a number of hardware implementations that avoid this problem in our various papers. For software implementations one of Hui Zhang's students, Ion Stoica has a very elegant data structure that effectively combines the two heaps eliminating the need to move sessions between the two heaps. (I should add that he developed this independently of the work I did with Hui Zhang, and prior to his becoming Hui's student.) >My point in my previous posting was that with this algorithm (WF2Q+), very >good behavior is obtained and the finish time for a packet is not >necessarily calculated or even knowable when a packet arrives. Following up >on this notion, I wondered whether using a definition for EF PHB that spoke >of a finish time only for the packet at the head of the EF aggregate queue >might not give us a simple and reasonable criterion for deciding when a >scheduler is compliant. I then offered a simple criterion. Whether it's >reasonable remains to be seen. Your approach does seem to have yielded a very nice formulation of the problem. An additional benefit that it appears to have is that by not concentrating on the delay of an individual packet it allows the EF traffic to be served by policies such as round robin rather than implying the EF aggregate must be served by a FIFO. 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, 2 May 2000 17:58:27 -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 RAA09454 for ; Tue, 2 May 2000 17:58:25 -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 QAA09002; Tue, 2 May 2000 16:57:55 -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 QAA10016; Tue, 2 May 2000 16:57:55 -0500 (CDT) Reply-To: From: "Kent Benson" To: , Cc: Subject: RE: [Diffserv] issues with RFC 2598 Date: Tue, 2 May 2000 17:00:32 -0500 Message-ID: <000001bfb481$d6f7ad00$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 Importance: Normal In-Reply-To: <000701bfb2e6$5e03e900$c5d82104@dsl.gtei.net> X-MimeOLE: Produced By Microsoft MimeOLE V4.72.3110.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 Bill, Thanks for your suggestions. Your definition seems to have quite a few nice properties. We've bounced quite a few scenarios off of it and so far the results have been quite good. There is one problem case described below but a blending of our proposals fixes this while preserving the nice properties of your criterion. (I apologize in advance if I have misrepresented your definition or screwed up the math.) Our two proposals are (after a little re-writing) 1) F_i=max{a_i,F_(i-1)}+(L_i/R_c) and 2) F_i=min[d_(i-1),F_(i-1)]+(L_i/R_c) when Q=1 F_i=a_i+(L_i/R_c) when Q=0 where d_i<=F_i+E in each case. They could be combined to form this definition 3) F_i=max{a_i,min[d_(i-1),F_(i-1)]}+(L_i/R_c) This definition avoids the problem seen in the following example. (This is an example from a previous e-mail so it might look familiar.) A link is configured for 1/2 EF traffic. Assume that MTU-sized EF packets are arriving at only 2/3 of the configured rate or 1/3 of the link rate. Assume it takes T time units to send an MTU-sized packet at the line rate. For this router, suppose that there is a fixed interval of time, 3T, between when a packet arrives and when it becomes eligible to be transmitted on the output link. This delay could be caused by such things header processing and route look-up as well as propagation delay through a multi-stage switching fabric. Thus, packets arrive at the output link scheduler 3T later than they arrive at the router. If the router is lightly loaded each of the packets will experience a delay of 4T (3T fixed delay, 0 scheduling delay, T transmission delay). Thus, packet 1 has an arrival time of a_1=0 and a departure time of d_1=4T, packet 2 has a_2=3T and d_2=7T, and so on. (The arrival and departure times of the EF packets are shown in the table below.) Since there is always at least one EF packet in the router at all times, the system stays at state Q=1 according to proposal 2 above. In this state the finish time of the packet i+1 can be at most L_i/R_c greater than the finish time of packet i. This is a problem since L_i/R_c=2T while packets are only arriving every 3T time units. Please see the table for the finishing times, F_i (2), and latest allowed departure times (called max d_i (2) in the table and calculated as F_i+E). If this input pattern continues no any finite E would prevent the departures times from eventually becoming non-conforming. Definition 3 gives the finish times and the latest allowable departure times F_i (3) and max d_i (3) as shown in the table. Using definition 3 all of the departure times for this input pattern are conforming as long as E>=2T. EF Packet Number: 1 2 3 4 5 6 ... Arrival (at router): 0 3T 6T 9T 12T 15T ... Arrival (at output link): 3T 6T 9T 12T 15T 18T ... Departure: 4T 7T 10T 13T 16T 19T ... F_i (2): 2T 4T 6T 8T 10T 12T ... max d_i (2): 2T+E 4T+E 6T+E 8T+E 10T+E 12T+E ... Fi (3): 2T 5T 8T 11T 14T 17T ... max d_i (3): 2T+E 5T+E 8T+E 11T+E 14T+E 17T+E ... I don't think this new criterion affects any of the other properties of your definition (except it does do away with the separation between the Q=0 and Q=1 states). Even though conformance definition 3 includes each packet's arrival time to the system, a WFQ-like output link scheduler would not need to know these times. They would only be needed for conformance testing. The output link scheduler could still use the time a packet arrives at the output port for its internal calculations (as long as the E term is set properly). Thanks, Kent >-----Original Message----- >From: the.courtneys@gte.net [mailto:the.courtneys@gte.net] >Sent: Sunday, April 30, 2000 3:55 PM >To: Kent.Benson@tellabs.com; acharny@cisco.com >Cc: diffserv@ietf.org >Subject: Re: [Diffserv] issues with RFC 2598 > > >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 > _______________________________________________ diffserv mailing list diffserv@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 May 2 19:16: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 TAA10237; Tue, 2 May 2000 19:16: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 SAA24414; Tue, 2 May 2000 18:46:05 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id SAA24383 for ; Tue, 2 May 2000 18:46:01 -0400 (EDT) Received: from mail-gw.hursley.ibm.com (mail-gw.hursley.ibm.com [194.196.110.15]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA10000 for ; Tue, 2 May 2000 18:45: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 XAA47662; Tue, 2 May 2000 23:45:28 +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 XAA25780; Tue, 2 May 2000 23:45:26 +0100 (BST) Message-ID: <390F5A0C.3FDA1EA4@hursley.ibm.com> Date: Tue, 02 May 2000 17:43: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: Jon Bennett CC: "'the.courtneys@gte.net'" , "'pawang@surya.csres.utexas.edu'" , "'Kent.Benson@tellabs.com'" , "'diffserv@ietf.org>'" Subject: Re: [Diffserv] issues with RFC 2598 References: <7F4AC78738EAD2119D86009027626C6D07EE92@PACKETBDC> 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 discussion is going a lot deeper into implementation details than is really relevant to an IETF WG. We don't do formal compliance work in the IETF. Personally I think you are (collectively) trying to refine the details too much and losing sight of the global constraints, which is all that a PHB spec such as RFC 2598 is intended to specify. Kent reminded us of the key definition of the EF PHB: > "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." When we finalized RFC 2598 this wording seemed to be unambiguous, necessary, and sufficient, otherwise it would not have gained WG consensus. Would anyone like to propose a specific, simple change to this wording? On the other hand, discussion of implementation details belongs on the diffserv implementation list (see http://www.tip.csiro.au/dsimplementation ) Brian Carpenter diffserv co-chair Jon Bennett wrote: > > Bill Courtney writes > > >I spoke too tersely and identified the wrong algorithm. I should have said > >"WF2Q+" rather than "WF2Q". Also, the start and finish times in WF2Q+ are > >kept "per session" (not necesarily "per queue"). > > For the record Pawan was right to complain (and I missed the point he was > making in my first response) that if you just make the change of > implementing per-queue timestamps with the *fluid* virtual time function of > WF2Q that things could go wrong. While this can be fixed in much the same > way as the non-RPPS case can be handled, his statement was in fact correct. > > I suspect that it would be best if everyone just assumed that WF2Q+ was > implied anytime implementation was being discussed unless it is explicitly > stated that the fluid model is being discussed to avoid the confusion that > keeps resulting. > > >I was assuming that each > >session had a FIFO and that a representative of each session is kept in one > >of two heaps, the ineligible heap or the eligible heap, based on start time > >versus virtual time. (Thus my use of "queue" rather than "session".) > >Clearly, this is my own interpretation of how one might implement WF2Q+, > and > >is not something that Bennett and Zhang said in "Hierarchical Packet Fair > >Queuing Algorithms," although in that paper they do discuss maintaining > only > >one start and finish time per session. > > Actually the two heap implementation has a problem when lots of ineligible > sessions become eligible, because you may need to move everyone from one > heap to the other in a single packet time. We present a number of hardware > implementations that avoid this problem in our various papers. For software > implementations one of Hui Zhang's students, Ion Stoica has a very elegant > data structure that effectively combines the two heaps eliminating the need > to move sessions between the two heaps. (I should add that he developed this > independently of the work I did with Hui Zhang, and prior to his becoming > Hui's student.) > > >My point in my previous posting was that with this algorithm (WF2Q+), very > >good behavior is obtained and the finish time for a packet is not > >necessarily calculated or even knowable when a packet arrives. Following > up > >on this notion, I wondered whether using a definition for EF PHB that spoke > >of a finish time only for the packet at the head of the EF aggregate queue > >might not give us a simple and reasonable criterion for deciding when a > >scheduler is compliant. I then offered a simple criterion. Whether it's > >reasonable remains to be seen. > > Your approach does seem to have yielded a very nice formulation of the > problem. An additional benefit that it appears to have is that by not > concentrating on the delay of an individual packet it allows the EF traffic > to be served by policies such as round robin rather than implying the EF > aggregate must be served by a FIFO. > > 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 $/=unpack('H*',$_);$_=`echo 16dio\U$k"SK$/SM$n\EsN0p[lN*1 > lK[d2%Sa2/d0$^Ixp"|dc`;s/\W//g;$_=pack('H*',/((..)*)$/) > > _______________________________________________ > diffserv mailing list > diffserv@ietf.org > http://www1.ietf.org/mailman/listinfo/diffserv > Archive: http://www-nrg.ee.lbl.gov/diff-serv-arch/ -- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - Brian E Carpenter Program Director, Internet Standards & Technology, IBM On assignment for IBM at http://www.iCAIR.org Attend INET 2000: http://www.isoc.org/inet2000 Non-IBM email: brian@icair.org _______________________________________________ diffserv mailing list diffserv@ietf.org http://www1.ietf.org/mailman/listinfo/diffserv Archive: http://www-nrg.ee.lbl.gov/diff-serv-arch/ From diffserv-admin@ietf.org Wed May 3 00:40: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 AAA14789; Wed, 3 May 2000 00:40: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 AAA26770; Wed, 3 May 2000 00:09: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 AAA26740 for ; Wed, 3 May 2000 00:09:39 -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 AAA14534 for ; Wed, 3 May 2000 00:09:40 -0400 (EDT) Received: by PACKETBDC with Internet Mail Service (5.5.2448.0) id ; Wed, 3 May 2000 00:15:24 -0400 Message-ID: <7F4AC78738EAD2119D86009027626C6D07EE98@PACKETBDC> From: Jon Bennett To: "'Brian E Carpenter'" Cc: Jon Bennett , "'the.courtneys@gte.net'" , "'pawang@surya.csres.utexas.edu'" , "'Kent.Benson@tellabs.com'" , "'diffserv@ietf.org>'" , "'kmn@cisco.com'" Subject: RE: [Diffserv] issues with RFC 2598 Date: Wed, 3 May 2000 00:15:23 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2448.0) Content-Type: text/plain; charset="iso-8859-1" Sender: diffserv-admin@ietf.org Errors-To: diffserv-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Diffserv Discussion List X-BeenThere: diffserv@ietf.org Brian, > Kent reminded us of the key definition of the EF PHB: > > > "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." > > When we finalized RFC 2598 this wording seemed to be > unambiguous, necessary, and sufficient, otherwise it > would not have gained WG consensus. Regardless of any previous consensus it has been demonstrated that the definition in RFC 2598 can not be implemented by any known scheduler. It has also been shown by several people that the definition can not be implemented in principle by any known or unknown work conserving scheduler. As a consequence it is not implementable by a strict priority scheduler or by any of the implementation examples presented in RFC 2598. Do you have any technical arguments to counter these statements? Unless you can present such arguments if would seem that the definition in RFC 2598 can not be "necessary and sufficient". > Would anyone like to propose a specific, > simple change to this wording? A number of proposals have been put forward, all of which are substantial improvements over RFC 2598 in that they can actually be implemented by a number of schedulers such as strict priority or weighted fair queueing unlike RFC 2598 which has been repeatedly shown to be unimplementable. > On the other hand, discussion of implementation details belongs > on the diffserv implementation list > (see http://www.tip.csiro.au/dsimplementation ) The discussion of implementation details has been solely for the purpose of determining that there exist reasonable implementations of the definitions that have been proposed. Are you suggesting that determining whether or not a proposed standard can be successfully implemented is not a relevant topic for discussion by an IETF WG? 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 May 3 10: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 KAA02720; Wed, 3 May 2000 10: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 JAA06427; Wed, 3 May 2000 09:33: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 JAA06398 for ; Wed, 3 May 2000 09:33:46 -0400 (EDT) Received: from nec.com (mail1.nec.com [143.101.112.2]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA01876 for ; Wed, 3 May 2000 09:33:46 -0400 (EDT) Received: from Marconi.cnad.dl.nec.com (marconi [143.101.24.11]) by nec.com (8.9.3/8.9.3) with ESMTP id IAA06149 for ; Wed, 3 May 2000 08:33:43 -0500 (CDT) Received: from cngconn.esd.dl.nec.com (cngconn.esd.dl.nec.com [143.101.28.60]) by Marconi.cnad.dl.nec.com (8.8.8/8.8.5) with ESMTP id IAA16100 for ; Wed, 3 May 2000 08:33:42 -0500 (CDT) Received: by CNGCONN with Internet Mail Service (5.5.2448.0) id ; Wed, 3 May 2000 08:33:44 -0500 Message-ID: From: "Wilson, Greg" To: "'diffserv@ietf.org'" Date: Wed, 3 May 2000 08:33:37 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2448.0) Content-Type: text/plain; charset="iso-8859-1" Subject: [Diffserv] "Critical" traffic in a DS Domain Sender: diffserv-admin@ietf.org Errors-To: diffserv-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Diffserv Discussion List X-BeenThere: diffserv@ietf.org All- What would be the best DS configuration for data that falls into a "critical" category. IE: Network Control Traffic, Heartbeats, Error Messages, or any other kind of data that directly controls the primary functionality of a far-end, time sensitive device that is connected to the network. This kind of traffic, if delayed or dropped, can cause problems or perceived problems with the affected devices. I am looking to find a PHB that focuses on this kind of "critical" traffic. Thanks -Greg Wilson gwilson@necam.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 May 3 10:29: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 KAA03113; Wed, 3 May 2000 10:29: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 JAA06465; Wed, 3 May 2000 09:34: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 JAA06440 for ; Wed, 3 May 2000 09:34: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 JAA01887 for ; Wed, 3 May 2000 09:34: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 OAA57600 for ; Wed, 3 May 2000 14:34: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 OAA21774 for ; Wed, 3 May 2000 14:34:12 +0100 (BST) Message-ID: <39102AD6.735CEB2F@hursley.ibm.com> Date: Wed, 03 May 2000 08:34:14 -0500 From: Brian E Carpenter Reply-To: brian@icair.org 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] WG poll on choice of terminology Sender: diffserv-admin@ietf.org Errors-To: diffserv-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, The use of the term "behavior aggregate" to recurse to cover an entire DS domain has been a matter of controversy at the Adelaide IETF and on the mailing list. Sifting through public and private emails on this, we've found that the intent of draft-ietf-diffserv-ba-def-01.txt is nicely covered by either of two terms. We'd like to see what the WG consensus choice is so that we can use this in the next document revision. The proposed terms are: 1) per-domain behavior (PDB) or 2) intra-domain service (IDS) These are intended to be defined upon a specific DS domain (as defined in RFCs 2474 & 2475), though of course, any particular definition may impose further constraints on the topology or technology of DS domain for which it is useful. Please indicate your choice of terminology in a one line reply with one choice - PDB or IDS - to brian@icair.org (not to the whole list please!!!) by May 10 at the latest. We'll total the results and declare a winner. If you want to discuss/debate further please do this on the list with a different subject header. Thanks 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 Wed May 3 10:38: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 KAA03318; Wed, 3 May 2000 10:38: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 KAA06957; Wed, 3 May 2000 10:02: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 KAA06926 for ; Wed, 3 May 2000 10:02:05 -0400 (EDT) Received: from mail-gw.hursley.ibm.com (mail-gw.hursley.ibm.com [194.196.110.15]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA02533 for ; Wed, 3 May 2000 10:02: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 PAA30124; Wed, 3 May 2000 15:01:18 +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 PAA21776; Wed, 3 May 2000 15:00:55 +0100 (BST) Message-ID: <39103119.2B3A0FEB@hursley.ibm.com> Date: Wed, 03 May 2000 09:00:57 -0500 From: Brian E Carpenter Organization: IBM X-Mailer: Mozilla 4.61 [en] (Win98; I) X-Accept-Language: en,fr MIME-Version: 1.0 To: Jon Bennett CC: "'the.courtneys@gte.net'" , "'pawang@surya.csres.utexas.edu'" , "'Kent.Benson@tellabs.com'" , "'diffserv@ietf.org>'" , "'kmn@cisco.com'" Subject: Re: [Diffserv] issues with RFC 2598 References: <7F4AC78738EAD2119D86009027626C6D07EE98@PACKETBDC> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: diffserv-admin@ietf.org Errors-To: diffserv-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Diffserv Discussion List X-BeenThere: diffserv@ietf.org Content-Transfer-Encoding: 7bit Jon, I'm not claiming technical expertise and I'm not going to enter the technical argument. I'm asking that the people who assert that there is a problem with the EF definition cited below come up with a specific, simple proposed rewrite that we can then discuss with the EF authors. Brian Jon Bennett wrote: > > Brian, > > > Kent reminded us of the key definition of the EF PHB: > > > > > "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." > > > > When we finalized RFC 2598 this wording seemed to be > > unambiguous, necessary, and sufficient, otherwise it > > would not have gained WG consensus. > > Regardless of any previous consensus it has been demonstrated > that the definition in RFC 2598 can not be implemented by any > known scheduler. It has also been shown by several people that > the definition can not be implemented in principle by any known > or unknown work conserving scheduler. As a consequence it is not > implementable by a strict priority scheduler or by any of the > implementation examples presented in RFC 2598. > > Do you have any technical arguments to counter these statements? > > Unless you can present such arguments if would seem that the > definition in RFC 2598 can not be "necessary and sufficient". > > > Would anyone like to propose a specific, > > simple change to this wording? > > A number of proposals have been put forward, all of which are > substantial improvements over RFC 2598 in that they can actually > be implemented by a number of schedulers such as strict priority > or weighted fair queueing unlike RFC 2598 which has been repeatedly > shown to be unimplementable. > > > On the other hand, discussion of implementation details belongs > > on the diffserv implementation list > > (see http://www.tip.csiro.au/dsimplementation ) > > The discussion of implementation details has been solely > for the purpose of determining that there exist reasonable > implementations of the definitions that have been proposed. > Are you suggesting that determining whether or not a > proposed standard can be successfully implemented is > not a relevant topic for discussion by an IETF WG? > > jon > > _______________________________________________ > diffserv mailing list > diffserv@ietf.org > http://www1.ietf.org/mailman/listinfo/diffserv > Archive: http://www-nrg.ee.lbl.gov/diff-serv-arch/ -- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - Brian E Carpenter Program Director, Internet Standards & Technology, IBM On assignment for IBM at http://www.iCAIR.org 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 May 3 10:46: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 KAA03441; Wed, 3 May 2000 10:46: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 KAA07187; Wed, 3 May 2000 10: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 KAA07081 for ; Wed, 3 May 2000 10:10:58 -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 KAA02814 for ; Wed, 3 May 2000 10:10:57 -0400 (EDT) Received: [from mothost.mot.com (mothost.mot.com [129.188.137.101]) by motgate2.mot.com (motgate2 2.1) with ESMTP id HAA21398; Wed, 3 May 2000 07:10:57 -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 HAA17772; Wed, 3 May 2000 07:10:56 -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 KAA17642; Wed, 3 May 2000 10:10:54 -0400 (EDT) Message-Id: <200005031410.KAA17642@noah.dma.isg.mot.com> X-Mailer: exmh version 1.6.7 5/3/96 To: brian@icair.org cc: Diff Serv In-reply-to: Your message of "Wed, 03 May 2000 08:34:14 EDT." <39102AD6.735CEB2F@hursley.ibm.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Wed, 03 May 2000 10:10:53 -0400 From: Dan Grossman Subject: [Diffserv] Chairs' WG poll on choice of terminology Sender: diffserv-admin@ietf.org Errors-To: diffserv-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Diffserv Discussion List X-BeenThere: diffserv@ietf.org Before answering the chairs' poll, it would be a good idea to review the definitions in RFC 2475, especially of 'service' and 'per-hop behavior'. If, after review and consideration, you believe that the thing defined in the BA draft is a generalization of a per-hop behavior, then vote for PDB. If you think it quacks like a service, then vote for IDS. 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 May 3 12:51: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 MAA06013; Wed, 3 May 2000 12:51: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 MAA08701; Wed, 3 May 2000 12:14: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 MAA08670 for ; Wed, 3 May 2000 12:14:07 -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 MAA05260 for ; Wed, 3 May 2000 12:14:05 -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 JAA05024; Wed, 3 May 2000 09:13:52 -0700 (PDT) Received: by nt-exchange1.pmc-sierra.bc.ca with Internet Mail Service (5.5.2650.21) id <2094Q3K3>; Wed, 3 May 2000 09:13:53 -0700 Message-ID: <336ECDAFDF7DD311B9E30090277AEE4101B40510@nt-exchange-bby.pmc-sierra.bc.ca> From: Shahram Davari To: "'Brian E Carpenter'" Cc: "'diffserv@ietf.org>'" Subject: RE: [Diffserv] issues with RFC 2598 Date: Wed, 3 May 2000 08:58:48 -0700 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: text/plain; charset="iso-8859-1" Sender: diffserv-admin@ietf.org Errors-To: diffserv-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Diffserv Discussion List X-BeenThere: diffserv@ietf.org Brian, Just to summarize there are currently two possibilities: 1) Small changes to the RFC-2598 wording. In which case EF can only be implemented using priority scheduling, and has a 50% link share limitation. 2) Significant changes to RFC-2598. In which case EF can be implemented using variety of schedulers, and alleviates the 50% share limitation. Regards, Shahram >-----Original Message----- >From: Brian E Carpenter [mailto:brian@hursley.ibm.com] >Sent: Wednesday, May 03, 2000 10:01 AM >To: Jon Bennett >Cc: 'the.courtneys@gte.net'; 'pawang@surya.csres.utexas.edu'; >'Kent.Benson@tellabs.com'; 'diffserv@ietf.org>'; 'kmn@cisco.com' >Subject: Re: [Diffserv] issues with RFC 2598 > > >Jon, > >I'm not claiming technical expertise and I'm not going to enter the >technical argument. I'm asking that the people who assert that >there is a problem with the EF definition cited below come up with >a specific, simple proposed rewrite that we can then discuss with >the EF authors. > > Brian > >Jon Bennett wrote: >> >> Brian, >> >> > Kent reminded us of the key definition of the EF PHB: >> > >> > > "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." >> > >> > When we finalized RFC 2598 this wording seemed to be >> > unambiguous, necessary, and sufficient, otherwise it >> > would not have gained WG consensus. >> >> Regardless of any previous consensus it has been demonstrated >> that the definition in RFC 2598 can not be implemented by any >> known scheduler. It has also been shown by several people that >> the definition can not be implemented in principle by any known >> or unknown work conserving scheduler. As a consequence it is not >> implementable by a strict priority scheduler or by any of the >> implementation examples presented in RFC 2598. >> >> Do you have any technical arguments to counter these statements? >> >> Unless you can present such arguments if would seem that the >> definition in RFC 2598 can not be "necessary and sufficient". >> >> > Would anyone like to propose a specific, >> > simple change to this wording? >> >> A number of proposals have been put forward, all of which are >> substantial improvements over RFC 2598 in that they can actually >> be implemented by a number of schedulers such as strict priority >> or weighted fair queueing unlike RFC 2598 which has been repeatedly >> shown to be unimplementable. >> >> > On the other hand, discussion of implementation details belongs >> > on the diffserv implementation list >> > (see http://www.tip.csiro.au/dsimplementation ) >> >> The discussion of implementation details has been solely >> for the purpose of determining that there exist reasonable >> implementations of the definitions that have been proposed. >> Are you suggesting that determining whether or not a >> proposed standard can be successfully implemented is >> not a relevant topic for discussion by an IETF WG? >> >> jon >> >> _______________________________________________ >> diffserv mailing list >> diffserv@ietf.org >> http://www1.ietf.org/mailman/listinfo/diffserv >> Archive: http://www-nrg.ee.lbl.gov/diff-serv-arch/ > >-- >- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - >Brian E Carpenter >Program Director, Internet Standards & Technology, IBM >On assignment for IBM at http://www.iCAIR.org >Attend INET 2000: http://www.isoc.org/inet2000 >Non-IBM email: brian@icair.org > >_______________________________________________ >diffserv mailing list >diffserv@ietf.org >http://www1.ietf.org/mailman/listinfo/diffserv >Archive: http://www-nrg.ee.lbl.gov/diff-serv-arch/ > _______________________________________________ diffserv mailing list diffserv@ietf.org http://www1.ietf.org/mailman/listinfo/diffserv Archive: http://www-nrg.ee.lbl.gov/diff-serv-arch/ From diffserv-admin@ietf.org Wed May 3 13:11:26 2000 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA06665; Wed, 3 May 2000 13:11: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 MAA08782; Wed, 3 May 2000 12:16: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 MAA08753 for ; Wed, 3 May 2000 12:16:41 -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 MAA05389 for ; Wed, 3 May 2000 12:16:38 -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 RAA31914; Wed, 3 May 2000 17:16:08 +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 RAA18518; Wed, 3 May 2000 17:16:06 +0100 (BST) Message-ID: <391050C8.CA298023@hursley.ibm.com> Date: Wed, 03 May 2000 11:16:08 -0500 From: Brian E Carpenter Organization: IBM X-Mailer: Mozilla 4.61 [en] (Win98; I) X-Accept-Language: en,fr MIME-Version: 1.0 To: "Wilson, Greg" CC: "'diffserv@ietf.org'" Subject: Re: [Diffserv] "Critical" traffic in a DS Domain 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 Class Selector 6 or 7 (RFC 2474, section 4.2.2.2) Brian "Wilson, Greg" wrote: > > All- > > What would be the best DS configuration for data that falls into a > "critical" category. IE: Network Control Traffic, Heartbeats, Error > Messages, or any other kind of data that directly controls the primary > functionality of a far-end, time sensitive device that is connected to the > network. This kind of traffic, if delayed or dropped, can cause problems or > perceived problems with the affected devices. > > I am looking to find a PHB that focuses on this kind of "critical" traffic. > > Thanks > -Greg Wilson > gwilson@necam.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 May 3 13:16: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 NAA06758; Wed, 3 May 2000 13:16: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 MAA09227; Wed, 3 May 2000 12:35: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 MAA09203 for ; Wed, 3 May 2000 12:35:17 -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 MAA05752 for ; Wed, 3 May 2000 12:35:15 -0400 (EDT) Received: from [129.193.4.9] by mailhub1.trw.com; Wed, 3 May 2000 09:35:10 -0700 Received: from imssp02.sp.trw.com ([129.4.53.75]) by navieg1.trw.com (Norton AntiVirus for Internet Email Gateways 1.0) ; Wed, 03 May 2000 16:35:10 0000 (GMT) Received: by imssp02.sp.TRW.COM with Internet Mail Service (5.5.2650.21) id ; Wed, 3 May 2000 09:35:06 -0700 Message-Id: <11A8C5C44A7BD211A7A40000D11BB1B201FDF272@mbsp06.sp.TRW.COM> From: Bill Courtney To: Kent.Benson@tellabs.com, the.courtneys@gte.net, acharny@cisco.com Cc: diffserv@ietf.org Subject: RE: [Diffserv] issues with RFC 2598 Date: Wed, 3 May 2000 09:35:06 -0700 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: text/plain; charset="iso-8859-1" Sender: diffserv-admin@ietf.org Errors-To: diffserv-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Diffserv Discussion List X-BeenThere: diffserv@ietf.org Kent, Where do you find these extraordinary counter-examples? I think that your fusion of the two definitions into definition 3) is an excellent suggestion. It addresses non-queuing delay in the router in a simple manner. Where there is no non-queuing delay, it is equivalent to the two-state definition that I suggested earlier and uses a nice single-line definition. It is unfortunate that each packet p_i has an associated arrival time, a_i, that needs to be kept in memory, but I cannot think of a simpler natural method that allows the definition to cope with non-queuing delay. Thanks, Bill -----Original Message----- From: Kent Benson [mailto:Kent.Benson@tellabs.com] Sent: Tuesday, May 02, 2000 3:01 PM To: the.courtneys@gte.net; acharny@cisco.com Cc: diffserv@ietf.org Subject: RE: [Diffserv] issues with RFC 2598 Bill, Thanks for your suggestions. Your definition seems to have quite a few nice properties. We've bounced quite a few scenarios off of it and so far the results have been quite good. There is one problem case described below but a blending of our proposals fixes this while preserving the nice properties of your criterion. (I apologize in advance if I have misrepresented your definition or screwed up the math.) Our two proposals are (after a little re-writing) 1) F_i=max{a_i,F_(i-1)}+(L_i/R_c) and 2) F_i=min[d_(i-1),F_(i-1)]+(L_i/R_c) when Q=1 F_i=a_i+(L_i/R_c) when Q=0 where d_i<=F_i+E in each case. They could be combined to form this definition 3) F_i=max{a_i,min[d_(i-1),F_(i-1)]}+(L_i/R_c) This definition avoids the problem seen in the following example. (This is an example from a previous e-mail so it might look familiar.) A link is configured for 1/2 EF traffic. Assume that MTU-sized EF packets are arriving at only 2/3 of the configured rate or 1/3 of the link rate. Assume it takes T time units to send an MTU-sized packet at the line rate. For this router, suppose that there is a fixed interval of time, 3T, between when a packet arrives and when it becomes eligible to be transmitted on the output link. This delay could be caused by such things header processing and route look-up as well as propagation delay through a multi-stage switching fabric. Thus, packets arrive at the output link scheduler 3T later than they arrive at the router. If the router is lightly loaded each of the packets will experience a delay of 4T (3T fixed delay, 0 scheduling delay, T transmission delay). Thus, packet 1 has an arrival time of a_1=0 and a departure time of d_1=4T, packet 2 has a_2=3T and d_2=7T, and so on. (The arrival and departure times of the EF packets are shown in the table below.) Since there is always at least one EF packet in the router at all times, the system stays at state Q=1 according to proposal 2 above. In this state the finish time of the packet i+1 can be at most L_i/R_c greater than the finish time of packet i. This is a problem since L_i/R_c=2T while packets are only arriving every 3T time units. Please see the table for the finishing times, F_i (2), and latest allowed departure times (called max d_i (2) in the table and calculated as F_i+E). If this input pattern continues no any finite E would prevent the departures times from eventually becoming non-conforming. Definition 3 gives the finish times and the latest allowable departure times F_i (3) and max d_i (3) as shown in the table. Using definition 3 all of the departure times for this input pattern are conforming as long as E>=2T. EF Packet Number: 1 2 3 4 5 6 ... Arrival (at router): 0 3T 6T 9T 12T 15T ... Arrival (at output link): 3T 6T 9T 12T 15T 18T ... Departure: 4T 7T 10T 13T 16T 19T ... F_i (2): 2T 4T 6T 8T 10T 12T ... max d_i (2): 2T+E 4T+E 6T+E 8T+E 10T+E 12T+E ... Fi (3): 2T 5T 8T 11T 14T 17T ... max d_i (3): 2T+E 5T+E 8T+E 11T+E 14T+E 17T+E ... I don't think this new criterion affects any of the other properties of your definition (except it does do away with the separation between the Q=0 and Q=1 states). Even though conformance definition 3 includes each packet's arrival time to the system, a WFQ-like output link scheduler would not need to know these times. They would only be needed for conformance testing. The output link scheduler could still use the time a packet arrives at the output port for its internal calculations (as long as the E term is set properly). Thanks, 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 May 3 13:52: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 NAA07468; Wed, 3 May 2000 13:52: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 NAA09771; Wed, 3 May 2000 13:16:59 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id NAA09743 for ; Wed, 3 May 2000 13:16:56 -0400 (EDT) Received: from ennovatenetworks.com (ennovatenetworks.com [208.227.99.254]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA06775 for ; Wed, 3 May 2000 13:16:55 -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 NAA13013; Wed, 3 May 2000 13:15:53 -0400 (EDT) (envelope-from bkumar@ennovatenetworks.com) Reply-To: From: "Brijesh Kumar" To: "'Wilson, Greg'" , Subject: RE: [Diffserv] "Critical" traffic in a DS Domain Date: Wed, 3 May 2000 13:19:34 -0400 Message-ID: <00de01bfb523$c10e83e0$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: 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 In his previous mail, Greg Wilson writes: > -----Original Message----- > All- > > What would be the best DS configuration for data that falls into a > "critical" category. IE: Network Control Traffic, Heartbeats, Error > Messages, or any other kind of data that directly controls the primary > functionality of a far-end, time sensitive device that is > connected to the > network. This kind of traffic, if delayed or dropped, can > cause problems or > perceived problems with the affected devices. > > I am looking to find a PHB that focuses on this kind of > "critical" traffic. I don't think there is any PHB that exactly captures the requirements for network Critical category as defined by you. You can use class selector code points for such a traffic, and schedule this traffic at a priority above or below EF. You can define such a behavior, and the only requirement seems to be that you document the chosen behavior. 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 May 3 13:59:57 2000 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA07597; Wed, 3 May 2000 13:59:57 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id NAA09999; Wed, 3 May 2000 13:29: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 NAA09975 for ; Wed, 3 May 2000 13:29: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 NAA07011 for ; Wed, 3 May 2000 13:29:01 -0400 (EDT) Received: from airborne.cisco.com (airborne.cisco.com [171.71.154.32]) by sj-msg-core-2.cisco.com (8.9.3/8.9.1) with ESMTP id KAA04266; Wed, 3 May 2000 10:04:08 -0700 (PDT) Received: from sbrim-nt.cisco.com (rtp-dial-2-92.cisco.com [10.83.96.92]) by airborne.cisco.com (Mirapoint) with ESMTP id ABG02130; Wed, 3 May 2000 10:03:58 -0700 (PDT) Message-Id: <4.3.2.3.2.20000503125629.00b2db70@airborne.cisco.com> X-Sender: sbrim@airborne.cisco.com X-Mailer: QUALCOMM Windows Eudora Version 4.3.2.3 (Beta) Date: Wed, 03 May 2000 13:03:54 -0400 To: Brian E Carpenter From: Scott W Brim Subject: Re: [Diffserv] "Critical" traffic in a DS Domain Cc: "Wilson, Greg" , "'diffserv@ietf.org'" In-Reply-To: <391050C8.CA298023@hursley.ibm.com> References: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: diffserv-admin@ietf.org Errors-To: diffserv-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Diffserv Discussion List X-BeenThere: diffserv@ietf.org Of course it's not just the DSCPs that matter, it's the end-to-end service (here we go again :-)). The class selectors promise nothing about loss or delay, except in relative terms. If you want to be sure of zero delay, zero loss, you need a service which provides that -- which you could implement with class selectors 6 and 7, or EF or AF. You're feeding right into the per-domain behavior discussion that's been going on (see draft-ietf-diffserv-ba-def-01.txt). At 11:16 05/03/2000 -0500, Brian E Carpenter wrote: >Class Selector 6 or 7 (RFC 2474, section 4.2.2.2) > > Brian > >"Wilson, Greg" wrote: > > > > All- > > > > What would be the best DS configuration for data that falls into a > > "critical" category. IE: Network Control Traffic, Heartbeats, Error > > Messages, or any other kind of data that directly controls the primary > > functionality of a far-end, time sensitive device that is connected > to the > > network. This kind of traffic, if delayed or dropped, can cause > problems or > > perceived problems with the affected devices. > > > > I am looking to find a PHB that focuses on this kind of "critical" > traffic. > > > > Thanks > > -Greg Wilson > > gwilson@necam.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 May 3 14:06: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 OAA07770; Wed, 3 May 2000 14:06: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 NAA10289; Wed, 3 May 2000 13:36: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 NAA10262 for ; Wed, 3 May 2000 13:36:26 -0400 (EDT) Received: from michael.checkpoint.com (michael.checkpoint.com [199.203.73.68]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA07189 for ; Wed, 3 May 2000 13:36:21 -0400 (EDT) Received: from sumsum (localhost [127.0.0.1]) by michael.checkpoint.com (8.9.3/8.9.1) with SMTP id UAA19476 for ; Wed, 3 May 2000 20:35:49 +0300 (IDT) Reply-To: From: "Oded Gonda" To: Date: Wed, 3 May 2000 20:36:28 +0200 Message-ID: <001001bfb52e$7f1726d0$e98d96d4@checkpoint.com> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0011_01BFB53F.429FF6D0" X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook 8.5, Build 4.71.2173.0 Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2014.211 Subject: [Diffserv] Class Selector Compliant PHBs Sender: diffserv-admin@ietf.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_0011_01BFB53F.429FF6D0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Hi, RFC 2474 defines: Class Selector Codepoint: any of the eight codepoints in the range ' xxx000' (where 'x' may equal '0' or '1'). Class Selector Codepoints are discussed in Sec. 4.2.2. Class Selector Compliant PHB: a per-hop behavior satisfying the Class Selector PHB Requirements specified in Sec. 4.2.2.2. Are there any known PHBs which are not Class Selector Compliant? Oded. ------=_NextPart_000_0011_01BFB53F.429FF6D0 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
Hi,
 
RFC = 2474=20 defines:
 
   Class Selector = Codepoint: any of=20 the eight codepoints in the range '
   xxx000' (where 'x' = may equal=20 '0' or '1').  Class Selector Codepoints
   are = discussed in=20 Sec. 4.2.2.

   Class=20 Selector Compliant PHB: a per-hop behavior satisfying the=20 Class
   Selector PHB Requirements specified in Sec.=20 4.2.2.2.
 

Are there=20 any known PHBs which are not Class Selector=20 Compliant?
 
Oded.
   =
------=_NextPart_000_0011_01BFB53F.429FF6D0-- _______________________________________________ diffserv mailing list diffserv@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 May 3 14:44: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 OAA08858 for ; Wed, 3 May 2000 14:44: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 OAA10999; Wed, 3 May 2000 14:20: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 OAA10970 for ; Wed, 3 May 2000 14:20:49 -0400 (EDT) Received: from mailsrv.campio.com ([38.186.47.7]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA08200 for ; Wed, 3 May 2000 14:20:46 -0400 (EDT) Received: by MAILSRV with Internet Mail Service (5.5.2650.21) id ; Wed, 3 May 2000 11:25:30 -0700 Message-ID: From: Kyung Park To: bkumar@ennovatenetworks.com Cc: "'Wilson, Greg'" , diffserv@ietf.org Subject: RE: [Diffserv] "Critical" traffic in a DS Domain Date: Wed, 3 May 2000 11:25:29 -0700 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01BFB52C.F5ED2A54" Sender: diffserv-admin@ietf.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_01BFB52C.F5ED2A54 Content-Type: text/plain; charset="iso-8859-1" Can we assign those kinds of traffic to the EF or AF? What is the rules for assign traffic to specific CS, EF or AF PHB? Thanks, ------------------------------------------- Kyung Park Campio communications http://www.campio.com > -----Original Message----- > From: Brijesh Kumar [mailto:bkumar@ennovatenetworks.com] > Sent: Wednesday, May 03, 2000 10:20 AM > To: 'Wilson, Greg'; diffserv@ietf.org > Subject: RE: [Diffserv] "Critical" traffic in a DS Domain > > > In his previous mail, Greg Wilson writes: > > -----Original Message----- > > All- > > > > What would be the best DS configuration for data that falls into a > > "critical" category. IE: Network Control Traffic, > Heartbeats, Error > > Messages, or any other kind of data that directly controls > the primary > > functionality of a far-end, time sensitive device that is > > connected to the > > network. This kind of traffic, if delayed or dropped, can > > cause problems or > > perceived problems with the affected devices. > > > > I am looking to find a PHB that focuses on this kind of > > "critical" traffic. > > > I don't think there is any PHB that exactly captures the > requirements for > network Critical category as defined by you. You can use > class selector > code points for such a traffic, and schedule this traffic at > a priority > above > or below EF. You can define such a behavior, and the only > requirement seems > to be that you document the chosen behavior. > > 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/ > ------_=_NextPart_001_01BFB52C.F5ED2A54 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable RE: [Diffserv] "Critical" traffic in a DS = Domain

Can we assign those kinds of traffic to the EF or = AF?
What is the rules for assign traffic to specific =
CS, EF or AF PHB?

Thanks,
-------------------------------------------
Kyung = Park            = Campio communications
http://www.campio.com


> -----Original Message-----
> From: Brijesh Kumar [mailto:bkumar@ennovatenetwor= ks.com]
> Sent: Wednesday, May 03, 2000 10:20 AM
> To: 'Wilson, Greg'; diffserv@ietf.org
> Subject: RE: [Diffserv] "Critical" = traffic in a DS Domain
>
>
> In his previous mail, Greg Wilson = writes:
> > -----Original Message-----
> > All-
> >
> > What would be the best DS configuration = for data that falls into a
> > "critical" category.  = IE:  Network Control Traffic,
> Heartbeats, Error
> > Messages, or any other kind of data that = directly controls
> the primary
> > functionality of a far-end, time sensitive = device that is
> > connected to the
> > network.  This kind of traffic, if = delayed or dropped, can
> > cause problems or
> > perceived problems with the affected = devices.
> >
> > I am looking to find a PHB that focuses on = this kind of
> > "critical" traffic.
>
>
> I don't think there is any PHB that exactly = captures the
> requirements for
> network Critical category as defined by you. = You can use
> class selector
> code points for such a traffic, and schedule = this traffic at
> a priority
> above
> or below EF. You can define such a behavior, = and the only
> requirement seems
> to be that you document the chosen = behavior.
>
> 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/
>

------_=_NextPart_001_01BFB52C.F5ED2A54-- _______________________________________________ diffserv mailing list diffserv@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 May 3 15:04: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 PAA09178 for ; Wed, 3 May 2000 15:04: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 OAA11464; Wed, 3 May 2000 14:46: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 OAA11433 for ; Wed, 3 May 2000 14:46:15 -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 OAA08883 for ; Wed, 3 May 2000 14:46:13 -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 LAA15097; Wed, 3 May 2000 11:46:06 -0700 (PDT) Received: by nt-exchange1.pmc-sierra.bc.ca with Internet Mail Service (5.5.2650.21) id <2094QQ4R>; Wed, 3 May 2000 11:46:06 -0700 Message-ID: <336ECDAFDF7DD311B9E30090277AEE4101B40513@nt-exchange-bby.pmc-sierra.bc.ca> From: Shahram Davari To: "'ogonda@checkpoint.com'" , diffserv@ietf.org Subject: RE: [Diffserv] Class Selector Compliant PHBs Date: Wed, 3 May 2000 11:43:19 -0700 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: text/plain; charset="iso-8859-1" Sender: diffserv-admin@ietf.org Errors-To: diffserv-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Diffserv Discussion List X-BeenThere: diffserv@ietf.org Hi, Yes. For example if CS1 to CS3 are mapped to AF11 and CS4 to CS7 are mapped to AF22. In this case there is not necessarily any relationship between AF11 and AF22, while the CS-PHB requires a timely forwarding and prefrential treatment relationship. Regards, Shahram -----Original Message----- From: Oded Gonda [mailto:ogonda@checkpoint.com] Sent: Wednesday, May 03, 2000 2:36 PM To: diffserv@ietf.org Subject: [Diffserv] Class Selector Compliant PHBs Hi, RFC 2474 defines: Class Selector Codepoint: any of the eight codepoints in the range ' xxx000' (where 'x' may equal '0' or '1'). Class Selector Codepoints are discussed in Sec. 4.2.2. Class Selector Compliant PHB: a per-hop behavior satisfying the Class Selector PHB Requirements specified in Sec. 4.2.2.2. Are there any known PHBs which are not Class Selector Compliant? Oded. _______________________________________________ diffserv mailing list diffserv@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 May 3 15:16: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 PAA09381 for ; Wed, 3 May 2000 15:16: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 OAA11620; Wed, 3 May 2000 14:59: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 OAA11581 for ; Wed, 3 May 2000 14:58: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 OAA09043 for ; Wed, 3 May 2000 14:58:03 -0400 (EDT) Received: from zubin.dnrc.bell-labs.com ([135.180.130.56]) by dirty; Wed May 3 14:57:21 EDT 2000 Received: from lucent.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 OAA22265; Wed, 3 May 2000 14:57:17 -0400 (EDT) Message-ID: <3910775F.70723BF8@lucent.com> Date: Wed, 03 May 2000 12:00: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: Kyung Park CC: diffserv@ietf.org Subject: Rules Re: [Diffserv] "Critical" traffic in a DS Domain References: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: diffserv-admin@ietf.org Errors-To: diffserv-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Diffserv Discussion List X-BeenThere: diffserv@ietf.org Content-Transfer-Encoding: 7bit > What is the rules for assign traffic to specific > CS, EF or AF PHB? At risk of sounding unhelpful, the answer is "it depends on what you're trying to do". But I'm being serious. Diffserv provides the building blocks - the rules for how you use them depend on what you're building. And so far the WG isn't developing e2e specifications, because everyone has a slightly different idea of what services they want. It isn't even clear we'd be able to standardize any particular solutions, since there's such an interdependency between network topology, PHB assignment, and per-hop resource allocations. And since it'd be hard to standardize, its outside WG scope. 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 May 3 15:47: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 PAA09888 for ; Wed, 3 May 2000 15:47: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 PAA12100; Wed, 3 May 2000 15:20: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 PAA12071 for ; Wed, 3 May 2000 15:20:33 -0400 (EDT) Received: from ennovatenetworks.com (ennovatenetworks.com [208.227.99.254]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA09509 for ; Wed, 3 May 2000 15:20:32 -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 PAA17030; Wed, 3 May 2000 15:20:00 -0400 (EDT) (envelope-from bkumar@ennovatenetworks.com) Reply-To: From: "Brijesh Kumar" To: "'Kyung Park'" , Cc: "'Wilson, Greg'" , Subject: RE: [Diffserv] "Critical" traffic in a DS Domain Date: Wed, 3 May 2000 15:23:39 -0400 Message-ID: <00e501bfb535$168d0ce0$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: 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 In his previous mail, Kyung Park writes: >Can we assign those kinds of traffic to the EF or AF? >What is the rules for assign traffic to specific >CS, EF or AF PHB? Some nodes may indeed map (some, if not all) CS code points to different PHBs(EF, AF or the vendor defined), others may implement them as a separate PHBs as defined in RFC 2474 section 4.2.2.4 with the relationship with EF, AF and BE chosen almost arbitrarily. I think that the class selector code point compliant PHBs will prove worthless in a network consisting of multi-vendor nodes as there is no standard way to achieve any useful end to end deterministic behavior by deploying the CS compliant PHBs. Only using nodes that have consistency in how they treat network control traffic using CS code points, the end to end behavior can be made deterministic. Cheers, --brijesh Ennovate Networks Inc. > -----Original Message----- > From: Brijesh Kumar [mailto:bkumar@ennovatenetworks.com] > Sent: Wednesday, May 03, 2000 10:20 AM > To: 'Wilson, Greg'; diffserv@ietf.org > Subject: RE: [Diffserv] "Critical" traffic in a DS Domain > > > In his previous mail, Greg Wilson writes: > > -----Original Message----- > > All- > > > > What would be the best DS configuration for data that falls into a > > "critical" category. IE: Network Control Traffic, > Heartbeats, Error > > Messages, or any other kind of data that directly controls > the primary > > functionality of a far-end, time sensitive device that is > > connected to the > > network. This kind of traffic, if delayed or dropped, can > > cause problems or > > perceived problems with the affected devices. > > > > I am looking to find a PHB that focuses on this kind of > > "critical" traffic. > > > I don't think there is any PHB that exactly captures the > requirements for > network Critical category as defined by you. You can use > class selector > code points for such a traffic, and schedule this traffic at > a priority > above > or below EF. You can define such a behavior, and the only > requirement seems > to be that you document the chosen behavior. > > 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 May 3 16:03: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 QAA10298 for ; Wed, 3 May 2000 16:03: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 PAA12521; Wed, 3 May 2000 15:44: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 PAA12489 for ; Wed, 3 May 2000 15:44:28 -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 PAA09856 for ; Wed, 3 May 2000 15:44:28 -0400 (EDT) Received: [from pobox2.mot.com (pobox2.mot.com [136.182.15.8]) by motgate.mot.com (motgate 2.1) with ESMTP id MAA01964; Wed, 3 May 2000 12:44:21 -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 MAA01821; Wed, 3 May 2000 12:44:21 -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 PAA29680; Wed, 3 May 2000 15:44:20 -0400 (EDT) Message-Id: <200005031944.PAA29680@noah.dma.isg.mot.com> X-Mailer: exmh version 1.6.7 5/3/96 To: Grenville Armitage cc: Kyung Park , diffserv@ietf.org Subject: Re: Rules Re: [Diffserv] "Critical" traffic in a DS Domain In-reply-to: Your message of "Wed, 03 May 2000 12:00:47 EDT." <3910775F.70723BF8@lucent.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Wed, 03 May 2000 15:44:20 -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 This discussion is another reminder that, RFC 2475 notwithstanding, there are many folks who equate 'PHB' with 'edge-to-edge service'. I'm sure that many of us have to deal with this problem more often than we'd like. I don't know how to better educate the public, but if we don't do something, these problems will persist. _______________________________________________ diffserv mailing list diffserv@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 May 3 16:14:47 2000 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA10519 for ; Wed, 3 May 2000 16:14: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 QAA12951; Wed, 3 May 2000 16:00:53 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id QAA12840 for ; Wed, 3 May 2000 16:00:45 -0400 (EDT) Received: from icasun1.epfl.ch (root@icasun1.epfl.ch [128.178.151.148]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA10207 for ; Wed, 3 May 2000 16:00:44 -0400 (EDT) Received: from icanoteb14 (ra-epfl-007.epfl.ch [128.178.84.207]) by icasun1.epfl.ch (8.8.X/EPFL-8.1d for ICA) with SMTP id WAA27471; Wed, 3 May 2000 22:00:38 +0200 (MET DST) Message-Id: <4.1.20000503205301.017d45c0@icamail1.epfl.ch> Message-Id: <4.1.20000503205301.017d45c0@icamail1.epfl.ch> Message-Id: <4.1.20000503205301.017d45c0@icamail1.epfl.ch> X-Sender: leboudec@icamail1.epfl.ch X-Mailer: QUALCOMM Windows Eudora Pro Version 4.1 Date: Wed, 03 May 2000 22:01:24 +0200 To: diffserv@ietf.org From: Jean-Yves Le Boudec Subject: Re: [Diffserv] issues with RFC 2598 Cc: Anna Charny In-Reply-To: <39103119.2B3A0FEB@hursley.ibm.com> References: <7F4AC78738EAD2119D86009027626C6D07EE98@PACKETBDC> Mime-Version: 1.0 Content-Type: multipart/alternative; boundary="=====================_30676129==_.ALT" Sender: diffserv-admin@ietf.org Errors-To: diffserv-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Diffserv Discussion List X-BeenThere: diffserv@ietf.org --=====================_30676129==_.ALT Content-Type: text/plain; charset="us-ascii" Anna Charny and I support the last proposal by Bill and Kent, namely, replace the definition in RFC 2598 by The departure time d(k) for the kth packet of an EF aggregate must satisfy d(k) <= f(k) + L where f(k) is defined recursively by f(0)=0 f(k) = max (a(k), min(f(k-1), d(k-1)) + l(k) / R In the above, a(k) is the arrival time, l(k) is the length of packet in bits, R is the configured rate and L is the latency (or error term) of the node. The reasons are the following. 1. This definition is implementable (WF2Q+ is an example), yet does not tie the servive into any specific implementation 2. It is close to the spirit of the initial definition in RFC2598 (which was not implementable). 3. We can compute end-to-end delays in a diff-serv context. Points 1 and 2 have been discussed in this mailing list already. About point 3, consider that the initial proposition by Kent, namely f(k) = max (a(k), f(k-1)) + l(k) / R, is called "Guaranteed Rate Scheduling" by Goyal, Lam and Vin in 1995 [1]. One can show [2] that it is equivalent to the so called "rate-latency service curve property" of Cruz and others. Now we have shown in [3] that end-to-end delay bounds can be computed in a diffserv context with an assumption that can be essentially stated as: the nodes have the rate-latency service curve property. The new definition is stronger than the initial proposition by Kent, thus the results in [3] still hold with the new definition. Note that this new definition has an impact of the volkswagen (VW) service definition in draft-ietf-diffserv-ba-vw-00. Indeed, the delay computations in draft-ietf-diffserv-ba-vw-00 are overly optimistic. See reference [3] for proven end-to-end delay bounds. JY References: ---------- [1] P. Goyal, S. S. Lam, and H. Vin, “Determining end-to-end delay bounds in heterogeneous networks,” in 5th Int. Workshop on Network and Operational System Support for Digital Audio and Video (Durham, NH, Apr. 1995). [2] J.Y. Le Boudec, "Application of Network Calculus To Guaranteed Service Networks", IEEE Trans on Information theory, (44) 3, May 1998 [3] A. Charny and J.Y. Le Boudec "Delay Bounds in a Network with Aggregate Scheduling", http://dscwww.epfl.ch./EN/publications/ps_files/tr00_022.ps At 5/3/00, Brian E Carpenter wrote: >Jon, > >I'm not claiming technical expertise and I'm not going to enter the >technical argument. I'm asking that the people who assert that >there is a problem with the EF definition cited below come up with >a specific, simple proposed rewrite that we can then discuss with >the EF authors. --=====================_30676129==_.ALT Content-Type: text/html; charset="us-ascii" Anna Charny and I support the last proposal by Bill and Kent, namely, replace the definition in RFC 2598 by

The departure time d(k) for the kth packet of an EF aggregate must satisfy d(k) <= f(k) + L

where f(k) is defined recursively by

f(0)=0
f(k) = max (a(k), min(f(k-1), d(k-1)) + l(k) / R

In the above, a(k) is the arrival time, l(k) is the length of packet in bits, R is the configured rate and L is the latency (or error term) of the node.

The reasons are the following.

1. This definition is implementable (WF2Q+ is an example), yet does not tie the servive into any specific implementation
2. It is close to the spirit of the initial definition in RFC2598 (which was not implementable).
3. We can compute end-to-end delays in a diff-serv context.

Points 1 and 2 have been discussed in this mailing list already. About point 3, consider that the initial proposition by Kent, namely f(k) = max (a(k), f(k-1)) + l(k) / R, is called "Guaranteed Rate Scheduling" by Goyal, Lam and Vin in 1995 [1]. One can show [2] that it is equivalent to the so called "rate-latency service curve property" of Cruz and others. Now we have shown in [3] that end-to-end delay bounds can be computed in a diffserv context with an assumption that can be essentially stated as: the nodes have the rate-latency service curve property. The new definition is stronger than the initial proposition by Kent, thus the results in [3] still hold with the new definition.

Note that this new definition has an impact of the volkswagen (VW) service definition in draft-ietf-diffserv-ba-vw-00. Indeed, the delay computations in draft-ietf-diffserv-ba-vw-00 are overly optimistic. See reference [3] for proven end-to-end delay bounds.

JY


References:
----------

[1] P. Goyal, S. S. Lam, and H. Vin, “Determining end-to-end delay bounds in heterogeneous networks,” in 5th Int. Workshop on Network and Operational System Support for Digital Audio and Video (Durham, NH, Apr. 1995).


[2] J.Y. Le Boudec, "Application of Network Calculus To Guaranteed Service Networks", IEEE Trans on Information theory, (44) 3, May 1998

[3] A. Charny and J.Y. Le Boudec "Delay Bounds in a Network with Aggregate Scheduling", http://dscwww.epfl.ch./EN/publications/ps_files/tr00_022.ps


At 5/3/00, Brian E Carpenter wrote:
>Jon,
>
>I'm not claiming technical expertise and I'm not going to enter the
>technical argument. I'm asking that the people who assert that
>there is a problem with the EF definition cited below come up with
>a specific, simple proposed rewrite that we can then discuss with
>the EF authors. --=====================_30676129==_.ALT-- _______________________________________________ diffserv mailing list diffserv@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 May 3 17:17: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 RAA11444 for ; Wed, 3 May 2000 17:17: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 QAA13797; Wed, 3 May 2000 16:58: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 QAA13768 for ; Wed, 3 May 2000 16:58:30 -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 QAA11063 for ; Wed, 3 May 2000 16:58:29 -0400 (EDT) Received: from jschnizl1-pc (dhcp-sjc5-1-248.cisco.com [171.70.18.248]) by diablo.cisco.com (8.8.6 (PHNE_14041)/CISCO.SERVER.1.2) with SMTP id NAA21677; Wed, 3 May 2000 13:57:57 -0700 (PDT) Message-Id: <4.1.20000503164919.00a1b1b0@diablo.cisco.com> X-Sender: jschnizl@diablo.cisco.com X-Mailer: QUALCOMM Windows Eudora Pro Version 4.1 Date: Wed, 03 May 2000 16:57:25 -0400 To: Grenville Armitage From: John Schnizlein Subject: Re: Rules Re: [Diffserv] "Critical" traffic in a DS Domain Cc: diffserv@ietf.org In-Reply-To: <3910775F.70723BF8@lucent.com> References: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: diffserv-admin@ietf.org Errors-To: diffserv-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Diffserv Discussion List X-BeenThere: diffserv@ietf.org At 12:00 PM 05/03/2000 -0700, Grenville Armitage wrote: > >> What is the rules for assign traffic to specific >> CS, EF or AF PHB? > >... And so far the WG isn't developing e2e >specifications, because everyone has a slightly different idea >of what services they want. It isn't even clear we'd be able >to standardize any particular solutions, since there's such >an interdependency between network topology, PHB assignment, >and per-hop resource allocations. And since it'd be hard to >standardize, its outside WG scope. Minor correction: It is not because it is hard to standardize, it is because what traffic is given what treatment is a matter of business agreement that it is outside WG scope. The building-block approach is that it is also not necessary to standardize service specifications; network operators are expected to create a wide variety of service alternatives for the market to sort out. I know you know this, but your summary statement might have misled people who have not read the old discussions on this point. 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 Thu May 4 02:15: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 CAA29896 for ; Thu, 4 May 2000 02:15: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 BAA23094; Thu, 4 May 2000 01:49: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 BAA23063 for ; Thu, 4 May 2000 01:49:09 -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 BAA23224 for ; Thu, 4 May 2000 01:49:08 -0400 (EDT) Received: (cpmta 570 invoked from network); 3 May 2000 22:48:37 -0700 Received: from sj-isp-nat-pool-2.cisco.com (HELO van-pc5.packetdesign.com) (204.69.198.2) by smtp.packetdesign.com with SMTP; 3 May 2000 22:48:37 -0700 X-Sent: 4 May 2000 05:48:37 GMT Message-Id: <4.3.1.2.20000503224430.00a7e8d0@mail.packetdesign.com> X-Sender: nichols@mail.packetdesign.com X-Mailer: QUALCOMM Windows Eudora Version 4.3.1 Date: Wed, 03 May 2000 22:48:19 -0700 To: diffserv@ietf.org From: Kathleen Nichols Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Subject: [Diffserv] WG business - poll Sender: diffserv-admin@ietf.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 use of the term "behavior aggregate" to recurse to cover an entire DS domain has been a matter of controversy at the Adelaide IETF and on the mailing list. Sifting through public and private emails on this, we've found that the intent of the ba-def draft is nicely covered by either of two terms and we'd like to see what the WG consensus choice is so that we can use this in the next document revision. The proposed terms are: 1) per-domain behavior (PDB) or 2) intra-domain service (IDS) These are intended to be defined upon a specific DS domain (as defined in RFCs 2474 & 2475), though of course, any particular definition may impose further constraints on the topology or technology of DS domain for which it is useful. Please indicate your choice of terminology by emailing nichols@packetdesign.com by May 12 with one choice - PDB or IDS. Brian & Kathie, WG co-chairs _______________________________________________ diffserv mailing list diffserv@ietf.org http://www1.ietf.org/mailman/listinfo/diffserv Archive: http://www-nrg.ee.lbl.gov/diff-serv-arch/ From diffserv-admin@ietf.org Thu May 4 04: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 EAA00951 for ; Thu, 4 May 2000 04: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 DAA24407; Thu, 4 May 2000 03:48: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 DAA24376 for ; Thu, 4 May 2000 03:48: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 DAA00761 for ; Thu, 4 May 2000 03:48:00 -0400 (EDT) Received: from zubin.dnrc.bell-labs.com ([135.180.130.56]) by dirty; Thu May 4 03:46:58 EDT 2000 Received: from dnrc.bell-labs.com (ex-vpn64.pa.bell-labs.com [135.250.1.64]) by zubin.dnrc.bell-labs.com (8.9.3/8.9.3) with ESMTP id DAA24563; Thu, 4 May 2000 03:46:53 -0400 (EDT) Message-ID: <39112BBF.B53372BA@dnrc.bell-labs.com> Date: Thu, 04 May 2000 00:50:23 -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: diffserv@ietf.org Subject: Re: Rules Re: [Diffserv] "Critical" traffic in a DS Domain References: <4.1.20000503164919.00a1b1b0@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 I believe your observation is a specific instance, rather than a correction, of my point. Designing e2e services from a technical standpoint is non-trivial because of all the interdependent variables - variables that may be driven by a number of considerations including business agreements (as you noted), engineering expediency, or legacy network topologies. (Not all diffserv networks will be built by businesses, and defining e2e services for enterprise diffserv networks is still out of scope - because it is non-trivial.) cheers, gja John Schnizlein wrote: > > At 12:00 PM 05/03/2000 -0700, Grenville Armitage wrote: > > > >> What is the rules for assign traffic to specific > >> CS, EF or AF PHB? > > > >... And so far the WG isn't developing e2e > >specifications, because everyone has a slightly different idea > >of what services they want. It isn't even clear we'd be able > >to standardize any particular solutions, since there's such > >an interdependency between network topology, PHB assignment, > >and per-hop resource allocations. And since it'd be hard to > >standardize, its outside WG scope. > > Minor correction: > It is not because it is hard to standardize, it is because > what traffic is given what treatment is a matter of business > agreement that it is outside WG scope. The building-block > approach is that it is also not necessary to standardize > service specifications; network operators are expected to > create a wide variety of service alternatives for the market > to sort out. > > I know you know this, but your summary statement might have > misled people who have not read the old discussions on this point. > > John > > _______________________________________________ > 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 Thu May 4 14:06: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 OAA13067 for ; Thu, 4 May 2000 14:06: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 NAA29187; Thu, 4 May 2000 13:07: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 NAA29157 for ; Thu, 4 May 2000 13:07:39 -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 NAA11704 for ; Thu, 4 May 2000 13:07:38 -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 SAA18412; Thu, 4 May 2000 18:07:06 +0100 Received: from hursley.ibm.com (gsine01.us.sine.ibm.com [9.14.6.41]) by sp3at21.hursley.ibm.com (AIX4.2/UCB 8.7/8.7.3) with ESMTP id SAA25248; Thu, 4 May 2000 18:07:04 +0100 (BST) Message-ID: <3911AE32.75060DBF@hursley.ibm.com> Date: Thu, 04 May 2000 12:06:58 -0500 From: Brian E Carpenter Organization: IBM X-Mailer: Mozilla 4.61 [en] (Win98; I) X-Accept-Language: en,fr MIME-Version: 1.0 To: Kathleen Nichols CC: diffserv@ietf.org Subject: Re: [Diffserv] WG business - poll References: <4.3.1.2.20000503224430.00a7e8d0@mail.packetdesign.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 Aargh. Kathie and I got out of step. Sorry, but she's in throes of changing email addresses and I, oh well, no excuse for me. One poll is enough. Since mine was announced first... if you've already replied to brian@icair.org, please don't reply to Kathie. Brian Kathleen Nichols wrote: > > The use of the term "behavior aggregate" to recurse to > cover an entire DS domain has been a matter of controversy > at the Adelaide IETF and on the mailing list. Sifting > through public and private emails on this, we've found > that the intent of the ba-def draft is nicely covered by either > of two terms and we'd like to see what the WG consensus choice > is so that we can use this in the next document revision. > > The proposed terms are: > > 1) per-domain behavior (PDB) > or > 2) intra-domain service (IDS) > > These are intended to be defined upon a specific DS domain (as > defined in RFCs 2474 & 2475), though of course, any particular > definition may impose further constraints on the topology or > technology of DS domain for which it is useful. > > Please indicate your choice of terminology by emailing > nichols@packetdesign.com by May 12 with one choice - PDB or IDS. > > Brian & Kathie, WG 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/ _______________________________________________ diffserv mailing list diffserv@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 May 4 15:11:30 2000 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA14381 for ; Thu, 4 May 2000 15:11:29 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id OAA00314; Thu, 4 May 2000 14:41: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 OAA00279 for ; Thu, 4 May 2000 14:41: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 OAA13748 for ; Thu, 4 May 2000 14:41:19 -0400 (EDT) Received: from sp3at21.hursley.ibm.com (sp3at21.hursley.ibm.com [9.20.45.21]) by mail-gw.hursley.ibm.com (AIX4.3/UCB 8.8.8/8.8.8) with ESMTP id TAA60614; Thu, 4 May 2000 19:40:48 +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 TAA23020; Thu, 4 May 2000 19:40:46 +0100 (BST) Message-ID: <3911C3B5.37E57ADD@hursley.ibm.com> Date: Thu, 04 May 2000 13: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: Grenville Armitage CC: John Schnizlein , diffserv@ietf.org Subject: Re: Rules Re: [Diffserv] "Critical" traffic in a DS Domain References: <4.1.20000503164919.00a1b1b0@diablo.cisco.com> <39112BBF.B53372BA@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 OK, but this (and Dan Grossman's point) is *exactly* why the co-chairs took up the formerly-known-as-BA draft, as the next level of building block. Brian Grenville Armitage wrote: > > I believe your observation is a specific instance, rather than > a correction, of my point. Designing e2e services from a > technical standpoint is non-trivial because of all the > interdependent variables - variables that may be driven by a > number of considerations including business agreements (as you > noted), engineering expediency, or legacy network topologies. > (Not all diffserv networks will be built by businesses, and > defining e2e services for enterprise diffserv networks is > still out of scope - because it is non-trivial.) > > cheers, > gja > > John Schnizlein wrote: > > > > At 12:00 PM 05/03/2000 -0700, Grenville Armitage wrote: > > > > > >> What is the rules for assign traffic to specific > > >> CS, EF or AF PHB? > > > > > >... And so far the WG isn't developing e2e > > >specifications, because everyone has a slightly different idea > > >of what services they want. It isn't even clear we'd be able > > >to standardize any particular solutions, since there's such > > >an interdependency between network topology, PHB assignment, > > >and per-hop resource allocations. And since it'd be hard to > > >standardize, its outside WG scope. > > > > Minor correction: > > It is not because it is hard to standardize, it is because > > what traffic is given what treatment is a matter of business > > agreement that it is outside WG scope. The building-block > > approach is that it is also not necessary to standardize > > service specifications; network operators are expected to > > create a wide variety of service alternatives for the market > > to sort out. > > > > I know you know this, but your summary statement might have > > misled people who have not read the old discussions on this point. > > > > John > > > > _______________________________________________ > > 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 Thu May 4 15: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 PAA14397 for ; Thu, 4 May 2000 15:12: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 OAA00256; Thu, 4 May 2000 14:39: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 OAA00224 for ; Thu, 4 May 2000 14:39:38 -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 OAA13681 for ; Thu, 4 May 2000 14:39: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 TAA46042; Thu, 4 May 2000 19:38:23 +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 TAA20382; Thu, 4 May 2000 19:38:17 +0100 (BST) Message-ID: <3911C321.4E695CEC@hursley.ibm.com> Date: Thu, 04 May 2000 13:36: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: bkumar@ennovatenetworks.com CC: "'Kyung Park'" , diffserv@ietf.org, "'Wilson, Greg'" Subject: Re: [Diffserv] "Critical" traffic in a DS Domain References: <00e501bfb535$168d0ce0$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, There is no requirement for network control traffic to get determinisitic delay. The requirement is for it to get there as fast as possible, in front of any competing traffic. The class selectors are fine for that (as they have been for many years in their previous disguise as IP Precedence). It will be interesting to observe whether ISPs decide to push network control traffic in front of real time traffic, but it isn't a standards issue. Brian Brijesh Kumar wrote: > > In his previous mail, Kyung Park writes: > > >Can we assign those kinds of traffic to the EF or AF? > >What is the rules for assign traffic to specific > >CS, EF or AF PHB? > > Some nodes may indeed map (some, if not all) CS code points to > different PHBs(EF, AF or the vendor defined), others may implement > them as a separate PHBs as defined in RFC 2474 section 4.2.2.4 with > the relationship with EF, AF and BE chosen almost arbitrarily. > > I think that the class selector code point compliant PHBs will prove > worthless in a network consisting of multi-vendor nodes as there > is no standard way to achieve any useful end to end deterministic > behavior by deploying the CS compliant PHBs. Only using nodes that > have consistency in how they treat network control traffic using CS > code points, the end to end behavior can be made deterministic. > > Cheers, > > --brijesh > > Ennovate Networks Inc. > > > > > -----Original Message----- > > From: Brijesh Kumar [mailto:bkumar@ennovatenetworks.com] > > Sent: Wednesday, May 03, 2000 10:20 AM > > To: 'Wilson, Greg'; diffserv@ietf.org > > Subject: RE: [Diffserv] "Critical" traffic in a DS Domain > > > > > > In his previous mail, Greg Wilson writes: > > > -----Original Message----- > > > All- > > > > > > What would be the best DS configuration for data that falls into a > > > "critical" category. IE: Network Control Traffic, > > Heartbeats, Error > > > Messages, or any other kind of data that directly controls > > the primary > > > functionality of a far-end, time sensitive device that is > > > connected to the > > > network. This kind of traffic, if delayed or dropped, can > > > cause problems or > > > perceived problems with the affected devices. > > > > > > I am looking to find a PHB that focuses on this kind of > > > "critical" traffic. > > > > > > I don't think there is any PHB that exactly captures the > > requirements for > > network Critical category as defined by you. You can use > > class selector > > code points for such a traffic, and schedule this traffic at > > a priority > > above > > or below EF. You can define such a behavior, and the only > > requirement seems > > to be that you document the chosen behavior. > > > > 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/ -- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - Brian E Carpenter Program Director, Internet Standards & Technology, IBM On assignment for IBM at http://www.iCAIR.org Attend INET 2000: http://www.isoc.org/inet2000 Non-IBM email: brian@icair.org _______________________________________________ diffserv mailing list diffserv@ietf.org http://www1.ietf.org/mailman/listinfo/diffserv Archive: http://www-nrg.ee.lbl.gov/diff-serv-arch/ From diffserv-admin@ietf.org Thu May 4 15: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 PAA14408 for ; Thu, 4 May 2000 15:12: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 OAA00157; Thu, 4 May 2000 14:31: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 OAA00128 for ; Thu, 4 May 2000 14:31: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 OAA13523 for ; Thu, 4 May 2000 14:31: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 TAA29218; Thu, 4 May 2000 19:31:00 +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 TAA20444; Thu, 4 May 2000 19:30:57 +0100 (BST) Message-ID: <3911C16B.874F976D@hursley.ibm.com> Date: Thu, 04 May 2000 13:28: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: Grenville Armitage CC: Kyung Park , diffserv@ietf.org Subject: Re: Rules Re: [Diffserv] "Critical" traffic in a DS Domain References: <3910775F.70723BF8@lucent.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 Exactly. The "rules" are actually what we call "policy" and they are set by people for each individual network. No doubt standard industry practice will emerge over the next few years. Brian Grenville Armitage wrote: > > > What is the rules for assign traffic to specific > > CS, EF or AF PHB? > > At risk of sounding unhelpful, the answer is "it depends on what > you're trying to do". But I'm being serious. Diffserv provides > the building blocks - the rules for how you use them depend on > what you're building. And so far the WG isn't developing e2e > specifications, because everyone has a slightly different idea > of what services they want. It isn't even clear we'd be able > to standardize any particular solutions, since there's such > an interdependency between network topology, PHB assignment, > and per-hop resource allocations. And since it'd be hard to > standardize, its outside WG scope. > > 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 May 4 18:30: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 SAA19814 for ; Thu, 4 May 2000 18:30: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 RAA02607; Thu, 4 May 2000 17:47: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 RAA02576 for ; Thu, 4 May 2000 17:47:40 -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 RAA19066 for ; Thu, 4 May 2000 17:47:38 -0400 (EDT) Received: from cisco.com (dhcp-o-38-206.cisco.com [171.71.38.206]) by omega.cisco.com (8.8.8-Cisco List Logging/8.8.8) with ESMTP id OAA18508 for ; Thu, 4 May 2000 14:47:09 -0700 (PDT) Message-ID: <3911F055.B11E9C1F@cisco.com> Date: Thu, 04 May 2000 14:49:09 -0700 From: Kathleen Nichols X-Mailer: Mozilla 4.61 [en] (Win98; U) X-Accept-Language: en MIME-Version: 1.0 To: diffserv@ietf.org Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Subject: [Diffserv] poll again Sender: diffserv-admin@ietf.org Errors-To: diffserv-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, as Brian said, we fumbled the token, so please disregard my email and respond to Brian. I believe that Brian expected, under ordinary circumstances, I would see his posting and that would have completed the token passing we'd started. However, I seem to have been temporarily turned off by the ietf diffserv mailman software. I turned it back on, but nothing's happened yet. ...and here I thought we'd just had a quiet day or two... _______________________________________________ diffserv mailing list diffserv@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 May 5 08:10: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 IAA15932 for ; Fri, 5 May 2000 08:10: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 HAA13616; Fri, 5 May 2000 07:31: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 HAA13587 for ; Fri, 5 May 2000 07:31:09 -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 HAA14561 for ; Fri, 5 May 2000 07:31:09 -0400 (EDT) Received: from airborne.cisco.com (airborne.cisco.com [171.71.154.32]) by sj-msg-core-2.cisco.com (8.9.3/8.9.1) with ESMTP id EAA14076 for ; Fri, 5 May 2000 04:30:44 -0700 (PDT) Received: from sbrim-nt.cisco.com (rtp-dial-2-206.cisco.com [10.83.96.206]) by airborne.cisco.com (Mirapoint) with ESMTP id ABJ02687; Fri, 5 May 2000 04:30:36 -0700 (PDT) Message-Id: <4.3.2.3.2.20000505072446.00b3bad0@airborne.cisco.com> X-Sender: sbrim@airborne.cisco.com X-Mailer: QUALCOMM Windows Eudora Version 4.3.2.3 (Beta) Date: Fri, 05 May 2000 07:30:33 -0400 To: diffserv@ietf.org From: Scott W Brim Subject: Re: [Diffserv] "Critical" traffic in a DS Domain In-Reply-To: <3911C321.4E695CEC@hursley.ibm.com> References: <00e501bfb535$168d0ce0$d001010a@tst.ennovatenetworks.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 13:36 05/04/2000 -0500, Brian E Carpenter wrote: >There is no requirement for network control traffic to get determinisitic >delay. The requirement is for it to get there as fast as possible, in front >of any competing traffic. The class selectors are fine for that (as they >have been for many years in their previous disguise as IP Precedence). > >It will be interesting to observe whether ISPs decide to push network >control traffic in front of real time traffic, but it isn't a standards >issue. For at least some "network control" traffic (we used to know what this means, I'm not sure we do anymore), what you want is that it get "prompt" forwarding -- perhaps less forwarding priority than some other traffic under normal conditions -- but very low loss under any conditions. We may have a standards issue in supporting this edge-to-edge. ...Scott _______________________________________________ diffserv mailing list diffserv@ietf.org http://www1.ietf.org/mailman/listinfo/diffserv Archive: http://www-nrg.ee.lbl.gov/diff-serv-arch/ From diffserv-admin@ietf.org Mon May 8 19: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 TAA22915 for ; Mon, 8 May 2000 19:35: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 TAA04311; Mon, 8 May 2000 19:12: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 TAA04280 for ; Mon, 8 May 2000 19:12:46 -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 TAA22400 for ; Mon, 8 May 2000 19:12:44 -0400 (EDT) Received: from sp3at21.hursley.ibm.com (sp3at21.hursley.ibm.com [9.20.45.21]) by mail-gw.hursley.ibm.com (AIX4.3/UCB 8.8.8/8.8.8) with ESMTP id AAA34816 for ; Tue, 9 May 2000 00:12:12 +0100 Received: from hursley.ibm.com (lig32-225-217-146.us.lig-dial.ibm.com [32.225.217.146]) by sp3at21.hursley.ibm.com (AIX4.2/UCB 8.7/8.7.3) with ESMTP id AAA20154 for ; Tue, 9 May 2000 00:12:10 +0100 (BST) Message-ID: <3916C119.4DA4965B@hursley.ibm.com> Date: Mon, 08 May 2000 08:28:57 -0500 From: Brian E Carpenter Organization: IBM X-Mailer: Mozilla 4.61 [en] (Win98; I) X-Accept-Language: en,fr MIME-Version: 1.0 To: Diff Serv Subject: Re: [Diffserv] issues with RFC 2598 References: <7F4AC78738EAD2119D86009027626C6D07EE98@PACKETBDC> <39103119.2B3A0FEB@hursley.ibm.com> <3910627F.6D4EA454@cisco.com> <3911A285.7F6F5360@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 Just a comment from a co-chair: Van is going to give his comments on the whole thread as soon as he can, but external circumstances have delayed this. When we get his comments we can move forward in this discussion. 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 May 10 20:15:26 2000 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA05259 for ; Wed, 10 May 2000 20:15:26 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id TAA11236; Wed, 10 May 2000 19:41:19 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id TAA11205 for ; Wed, 10 May 2000 19:41:15 -0400 (EDT) Received: from dfssl.exchange.microsoft.com ([131.107.88.59]) by ietf.org (8.9.1a/8.9.1a) with SMTP id TAA05033 for ; Wed, 10 May 2000 19:41:14 -0400 (EDT) Received: from 172.30.236.11 by dfssl.exchange.microsoft.com (InterScan E-Mail VirusWall NT); Wed, 10 May 2000 16:31:12 -0700 (Pacific Daylight Time) Received: from SIT.platinum.corp.microsoft.com ([172.30.236.233]) by yuri.dns.microsoft.com with Microsoft SMTPSVC(5.0.2195.2023); Wed, 10 May 2000 16:38:36 -0700 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01BFBAD8.04458852" Date: Wed, 10 May 2000 16:32:33 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.0.4362.4 Message-ID: <19398D273324D3118A2B0008C7E9A5690681E0CB@SIT.platinum.corp.microsoft.com> Thread-Topic: Incompatibility between Diffserv and PPP based tunneling protocols Thread-Index: Ab+62L4imXIiRD7ISO+39RMZ4Hml9Q== From: "Rajesh Sundaram" To: , X-OriginalArrivalTime: 10 May 2000 23:38:36.0234 (UTC) FILETIME=[DC5B5AA0:01BFBAD8] Subject: [Diffserv] Incompatibility between Diffserv and PPP based tunneling protocols Sender: diffserv-admin@ietf.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_01BFBAD8.04458852 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Folks, There seems to be an incompatibility between tunneling protocols that encapsulate PPP (like L2TP and PPTP) and Diffserv PHBs.=20 Let's assume that there are two micro-flows of traffic within a single L2TP tunnel, marked for different PHBs. The DSCP mark has to be propagated from the original packet to the tunneled header at tunnel ingress (as per section 2.5 of EF PHB). The restrictions on packet re-order apply only to a packets belonging to a micro flow within a particular PHB class. So, it is possible for packets belonging to different PHBs to get re-ordered by DS aware nodes en-route to tunnel egress.=20 This re-ordering breaks PPTP and L2TP. PPTP is required to discard re-ordered packets in order to maintain the ordering semantics of PPP. L2TP allows for the receiver to restore the original sequence of re-ordered packets, but doing this negates the benefits of the PHB, since the packet will potentially remain in the receiver's tunnel buffer for a long time.=20 One way of solving this problem is to create multiple L2TP or PPTP sessions and by dedicating one PHB for each session. Since both L2TP and PPTP allow re-ordering across sessions, the packet re-order problem is not as nasty. Any suggestions on how this incompatibility can be addressed ? Thanks, Rajesh. ------_=_NextPart_001_01BFBAD8.04458852 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Incompatibility between Diffserv and PPP based tunneling = protocols

Folks,

There seems to be an incompatibility = between tunneling protocols that encapsulate PPP (like L2TP and PPTP) = and Diffserv PHBs.

Let's assume that there are two = micro-flows of traffic within a single L2TP tunnel, marked for different = PHBs. The DSCP mark has to be propagated from the original packet to the = tunneled header at tunnel ingress (as per section 2.5 of EF PHB). The = restrictions on packet re-order apply only to a packets belonging to a = micro flow within a particular PHB class. So, it is possible for packets = belonging to different PHBs to get re-ordered by DS aware nodes en-route = to tunnel egress.

This re-ordering breaks PPTP and = L2TP. PPTP is required to discard re-ordered packets in order to = maintain the ordering semantics of PPP. L2TP allows for the receiver to = restore the original sequence of re-ordered packets, but doing this = negates the benefits of the PHB, since the packet will potentially = remain in the receiver's tunnel buffer for a long time.

One way of solving this problem is to = create multiple L2TP or PPTP sessions and by dedicating one PHB for each = session. Since both L2TP and PPTP allow re-ordering across sessions, the = packet re-order problem is not as nasty.

Any suggestions on how this = incompatibility can be addressed ?

Thanks,
Rajesh.

------_=_NextPart_001_01BFBAD8.04458852-- _______________________________________________ diffserv mailing list diffserv@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 May 10 21:15: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 VAA05773 for ; Wed, 10 May 2000 21:15: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 VAA12073; Wed, 10 May 2000 21:02: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 VAA12042 for ; Wed, 10 May 2000 21:02:02 -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 VAA05654 for ; Wed, 10 May 2000 21:02:00 -0400 (EDT) Received: from zubin.dnrc.bell-labs.com ([135.180.130.56]) by crufty; Wed May 10 21:01:56 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 VAA10331; Wed, 10 May 2000 21:01:52 -0400 (EDT) Message-ID: <391A0754.FA3C92B2@dnrc.bell-labs.com> Date: Wed, 10 May 2000 18:05:24 -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: Rajesh Sundaram CC: diffserv@ietf.org, l2tp@ipsec.org Subject: Re: [Diffserv] Incompatibility between Diffserv and PPP based tunneling protocols References: <19398D273324D3118A2B0008C7E9A5690681E0CB@SIT.platinum.corp.microsoft.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 It isn't always the case that the outer DSCP (carried in the tunneling IP header) has to be copied from the DSCP of the IP packet being tunneled. In this case, when reordering of the tunnel's contents is a bad thing, the tunneling header ought to be given some relatively fixed DSCP (one that ensures 'appropriate' QoS across the tunnel's length). This would ensure that the aggregate of all traffic going through the tunnel is treated as a single non-reorderable 'flow' by the DS routers along the tunnel's path. cheers, gja > Rajesh Sundaram wrote: > > Folks, > > There seems to be an incompatibility between tunneling protocols that > encapsulate PPP (like L2TP and PPTP) and Diffserv PHBs. > > Let's assume that there are two micro-flows of traffic within a single L2TP > tunnel, marked for different PHBs. The DSCP mark has to be propagated from the > original packet to the tunneled header at tunnel ingress (as per section 2.5 > of EF PHB). The restrictions on packet re-order apply only to a packets > belonging to a micro flow within a particular PHB class. So, it is possible > for packets belonging to different PHBs to get re-ordered by DS aware nodes > en-route to tunnel egress. > > This re-ordering breaks PPTP and L2TP. PPTP is required to discard re-ordered > packets in order to maintain the ordering semantics of PPP. L2TP allows for > the receiver to restore the original sequence of re-ordered packets, but doing > this negates the benefits of the PHB, since the packet will potentially remain > in the receiver's tunnel buffer for a long time. > > One way of solving this problem is to create multiple L2TP or PPTP sessions > and by dedicating one PHB for each session. Since both L2TP and PPTP allow > re-ordering across sessions, the packet re-order problem is not as nasty. > > Any suggestions on how this incompatibility can be addressed ? > > Thanks, > Rajesh. -- ________________________________________________________________________ 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 May 10 21:33:59 2000 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA05941 for ; Wed, 10 May 2000 21:33: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 VAA12223; Wed, 10 May 2000 21:13: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 VAA12192 for ; Wed, 10 May 2000 21:13:16 -0400 (EDT) Received: from fcs-nt1.futsoft.com (fcs-nt1.futsoft.com [38.242.189.2]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA05742 for ; Wed, 10 May 2000 21:13:13 -0400 (EDT) Received: from sanjose.futsoft.com (unverified) by fcs-nt1.futsoft.com (Content Technologies SMTPRS 2.0.15) with SMTP id ; Wed, 10 May 2000 18:02:11 -0700 Received: from rajeshs ([38.242.189.59]) by sanjose.futsoft.com (8.9.3/8.8.7) with SMTP id RAA27983; Wed, 10 May 2000 17:07:47 -0700 Received: by localhost with Microsoft MAPI; Wed, 10 May 2000 18:25:15 -0700 Message-Id: <01BFBAAD.163F02C0.rajeshs@futsoft.com> From: Rajesh Kumar Reply-To: "rajeshs@futsoft.com" To: "'Rajesh Sundaram'" , "diffserv@ietf.org" , "l2tp@ipsec.org" Date: Wed, 10 May 2000 18:25:14 -0700 Organization: Future Communications Software X-Mailer: Microsoft Internet E-mail/MAPI - 8.0.0.4211 MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Subject: [Diffserv] RE: Incompatibility between Diffserv and PPP based tunneling protocols Sender: diffserv-admin@ietf.org Errors-To: diffserv-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Diffserv Discussion List X-BeenThere: diffserv@ietf.org Content-Transfer-Encoding: 7bit If you turn off reordering and sequencing (as these are optional in l2tp) and let tcp handle these issues, l2tp should work seamlessly. tcp would handle the reliability issues for each microflow. (I don't know much about pptp). But this works only for tcp. How about others - like udp? - that's unreliable service anyway, so why try to introduce reliability at the link layer? Does that sound workable? -----Original Message----- From: Rajesh Sundaram [SMTP:rajeshsu@Exchange.Microsoft.com] Sent: Wednesday, May 10, 2000 4:33 PM To: diffserv@ietf.org; l2tp@ipsec.org Subject: Incompatibility between Diffserv and PPP based tunneling protocols Folks, There seems to be an incompatibility between tunneling protocols that encapsulate PPP (like L2TP and PPTP) and Diffserv PHBs. Let's assume that there are two micro-flows of traffic within a single L2TP tunnel, marked for different PHBs. The DSCP mark has to be propagated from the original packet to the tunneled header at tunnel ingress (as per section 2.5 of EF PHB). The restrictions on packet re-order apply only to a packets belonging to a micro flow within a particular PHB class. So, it is possible for packets belonging to different PHBs to get re-ordered by DS aware nodes en-route to tunnel egress. This re-ordering breaks PPTP and L2TP. PPTP is required to discard re-ordered packets in order to maintain the ordering semantics of PPP. L2TP allows for the receiver to restore the original sequence of re-ordered packets, but doing this negates the benefits of the PHB, since the packet will potentially remain in the receiver's tunnel buffer for a long time. One way of solving this problem is to create multiple L2TP or PPTP sessions and by dedicating one PHB for each session. Since both L2TP and PPTP allow re-ordering across sessions, the packet re-order problem is not as nasty. Any suggestions on how this incompatibility can be addressed ? Thanks, Rajesh. << File: ATT00002.htm >> _______________________________________________ diffserv mailing list diffserv@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 May 10 22:27:51 2000 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA07175 for ; Wed, 10 May 2000 22:27:51 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id WAA12904; Wed, 10 May 2000 22:06: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 WAA12874 for ; Wed, 10 May 2000 22:06:51 -0400 (EDT) Received: from sales-finance.vpnet.com (mail.vpnet.com [209.1.117.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA07098 for ; Wed, 10 May 2000 22:06:48 -0400 (EDT) Received: by mail.vpnet.com with Internet Mail Service (5.0.1461.28) id ; Wed, 10 May 2000 19:07:23 -0700 Message-ID: From: Mahalingam Mani To: Grenville Armitage Cc: diffserv@ietf.org, l2tp@ipsec.org Subject: RE: [Diffserv] Incompatibility between Diffserv and PPP based tun neling protocols Date: Wed, 10 May 2000 19:07:21 -0700 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.0.1461.28) Content-Type: text/plain; charset="windows-1252" Sender: diffserv-admin@ietf.org Errors-To: diffserv-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Diffserv Discussion List X-BeenThere: diffserv@ietf.org What if the desired PHB is as required on a per-microflow basis - even over the tunnel? Especially the case with IKE tunnels where one may encounter multiple DS router hops in the tunnel? This is an issue with IPSec (IKE tunnels) - on similar lines. More so because if reordering is more than a certain (RFC-)suggested (which is a window of 32 packets - or more, as implemented) number then it is flagged as a replay attack. The suggestion to split the two microflows into 2 different tunnels will work, however with thousands of tunnels to manage in an enterprise/carrier-class VPN setup this will become an administrative nightmare. -mani > -----Original Message----- > From: Grenville Armitage [mailto:gja@dnrc.bell-labs.com] > Sent: Wednesday, May 10, 2000 6:05 PM > To: Rajesh Sundaram > Cc: diffserv@ietf.org; l2tp@ipsec.org > Subject: Re: [Diffserv] Incompatibility between Diffserv and PPP based > tunneling protocols > > > > It isn't always the case that the outer DSCP (carried in the tunneling > IP header) has to be copied from the DSCP of the IP packet being > tunneled. In this case, when reordering of the tunnel's contents is > a bad thing, the tunneling header ought to be given some relatively > fixed DSCP (one that ensures 'appropriate' QoS across the tunnel's > length). This would ensure that the aggregate of all traffic > going through the tunnel is treated as a single non-reorderable 'flow' > by the DS routers along the tunnel's path. > > cheers, > gja > > > Rajesh Sundaram wrote: > > > > Folks, > > > > There seems to be an incompatibility between tunneling > protocols that > > encapsulate PPP (like L2TP and PPTP) and Diffserv PHBs. > > > > Let's assume that there are two micro-flows of traffic > within a single L2TP > > tunnel, marked for different PHBs. The DSCP mark has to be > propagated from the > > original packet to the tunneled header at tunnel ingress > (as per section 2.5 > > of EF PHB). The restrictions on packet re-order apply only > to a packets > > belonging to a micro flow within a particular PHB class. > So, it is possible > > for packets belonging to different PHBs to get re-ordered > by DS aware nodes > > en-route to tunnel egress. > > > > This re-ordering breaks PPTP and L2TP. PPTP is required to > discard re-ordered > > packets in order to maintain the ordering semantics of PPP. > L2TP allows for > > the receiver to restore the original sequence of re-ordered > packets, but doing > > this negates the benefits of the PHB, since the packet will > potentially remain > > in the receiver's tunnel buffer for a long time. > > > > One way of solving this problem is to create multiple L2TP > or PPTP sessions > > and by dedicating one PHB for each session. Since both L2TP > and PPTP allow > > re-ordering across sessions, the packet re-order problem is > not as nasty. > > > > Any suggestions on how this incompatibility can be addressed ? > > > > Thanks, > > Rajesh. > > -- > ______________________________________________________________ > __________ > 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 May 11 04:27: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 EAA22571 for ; Thu, 11 May 2000 04:27: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 DAA20966; Thu, 11 May 2000 03:55: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 DAA20935 for ; Thu, 11 May 2000 03:55:46 -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 DAA22350 for ; Thu, 11 May 2000 03:55:44 -0400 (EDT) Received: [from mothost.mot.com (mothost.mot.com [129.188.137.101]) by ftpbox.mot.com (ftpbox 2.1) with ESMTP id AAA20980; Thu, 11 May 2000 00:55:42 -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 AAA16694; Thu, 11 May 2000 00:55:35 -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 NAA27482; Thu, 11 May 2000 13:30:02 +0530 (IST) Received: by xmail.miel.mot.com with Internet Mail Service (5.5.2650.21) id ; Thu, 11 May 2000 13:16:16 +0530 Message-ID: <2C202C0F886DD3119B1200A0C9A85FF405DC59@xmail.miel.mot.com> From: Radhakrishna To: "'rajeshs@futsoft.com'" , "'Rajesh Sundaram'" , diffserv@ietf.org, l2tp@ipsec.org Subject: RE: [Diffserv] RE: Incompatibility between Diffserv and PPP based tunneling protocols Date: Thu, 11 May 2000 13:16:13 +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 Same issue is there with GRE tunneling also. Turning off sequencing and reordering is definetly one solution. But if sequencing is really required, the reordering can be done based on DSCPs and hence multiple tunnels are not required. Regards, .....RK > -----Original Message----- > From: Rajesh Kumar [SMTP:rajeshs@futsoft.com] > Sent: Thursday, May 11, 2000 6:55 AM > To: 'Rajesh Sundaram'; diffserv@ietf.org; l2tp@ipsec.org > Subject: [Diffserv] RE: Incompatibility between Diffserv and PPP > based tunneling protocols > > If you turn off reordering and sequencing (as these are optional > in l2tp) and let tcp handle these issues, l2tp should work > seamlessly. tcp would handle the reliability issues for each > microflow. (I don't know much about pptp). > But this works only for tcp. How about others - like udp? - that's > unreliable service anyway, so why try to introduce reliability > at the link layer? > > Does that sound workable? > > -----Original Message----- > From: Rajesh Sundaram [SMTP:rajeshsu@Exchange.Microsoft.com] > Sent: Wednesday, May 10, 2000 4:33 PM > To: diffserv@ietf.org; l2tp@ipsec.org > Subject: Incompatibility between Diffserv and PPP based tunneling > protocols > > Folks, > > There seems to be an incompatibility between tunneling protocols that > encapsulate PPP (like L2TP and PPTP) and Diffserv PHBs. > > Let's assume that there are two micro-flows of traffic within a single > L2TP tunnel, marked for different PHBs. The DSCP mark has to be > propagated from the original packet to the tunneled header at tunnel > ingress (as per section 2.5 of EF PHB). The restrictions on packet > re-order apply only to a packets belonging to a micro flow within a > particular PHB class. So, it is possible for packets belonging to > different PHBs to get re-ordered by DS aware nodes en-route to tunnel > egress. > > This re-ordering breaks PPTP and L2TP. PPTP is required to discard > re-ordered packets in order to maintain the ordering semantics of PPP. > L2TP allows for the receiver to restore the original sequence of > re-ordered packets, but doing this negates the benefits of the PHB, > since the packet will potentially remain in the receiver's tunnel buffer > for a long time. > > One way of solving this problem is to create multiple L2TP or PPTP > sessions and by dedicating one PHB for each session. Since both L2TP and > PPTP allow re-ordering across sessions, the packet re-order problem is > not as nasty. > > Any suggestions on how this incompatibility can be addressed ? > > Thanks, > Rajesh. > << File: ATT00002.htm >> > > _______________________________________________ > 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 May 11 04:34: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 EAA22693 for ; Thu, 11 May 2000 04:34: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 EAA21229; Thu, 11 May 2000 04:10:06 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id EAA21198 for ; Thu, 11 May 2000 04: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 EAA22481 for ; Thu, 11 May 2000 04:10:00 -0400 (EDT) Received: from zubin.dnrc.bell-labs.com ([135.180.130.56]) by dirty; Thu May 11 04:09:00 EDT 2000 Received: from dnrc.bell-labs.com (ex-vpn69.pa.bell-labs.com [135.250.1.69]) by zubin.dnrc.bell-labs.com (8.9.3/8.9.3) with ESMTP id EAA12073; Thu, 11 May 2000 04:08:56 -0400 (EDT) Message-ID: <391A6B6E.AD568A04@dnrc.bell-labs.com> Date: Thu, 11 May 2000 01:12:30 -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: Mahalingam Mani CC: diffserv@ietf.org, l2tp@ipsec.org Subject: Re: [Diffserv] Incompatibility between Diffserv and PPP based tunneling protocols 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 Mahalingam Mani wrote: > > What if the desired PHB is as required on a per-microflow basis - even over > the > tunnel? Especially the case with IKE tunnels where one may encounter > multiple > DS router hops in the tunnel? I'm not really sure how to parse your question. In general tunnels provide isolation - conventionally just topological isolation, but increasingly we're having to consider temporal isolation (aka QoS). So consider the tunnel as becoming more like a link substitute in that one provisions the tunnel's temporal characteristics (QoS) to, in the aggregate, support the mix of traffic flowing through it. In the same way that we might mix EF and AF traffic on a single T1 line, so we might mix all sorts of traffic onto a tunnel having a fixed DSCP of its own. The tunnel's QoS is determined by the outer DSCP (and the provisioning of the DS routers along the path followed by the tunnel). 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 May 11 09:43: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 JAA27880 for ; Thu, 11 May 2000 09:43: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 JAA23988; Thu, 11 May 2000 09:04: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 JAA23957 for ; Thu, 11 May 2000 09:04:34 -0400 (EDT) Received: from phoenix.ficon-tech.com (phoenix.ficon-tech.com [209.125.90.2]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA26746 for ; Thu, 11 May 2000 09:04:33 -0400 (EDT) Received: from globespan.net (192.168.137.202) by phoenix.ficon-tech.com (Worldmail 1.3.167); 11 May 2000 09:14:44 -0400 Message-ID: <391AAFC5.3610EA8D@globespan.net> Date: Thu, 11 May 2000 09:04:05 -0400 From: Rohit Chhapolia Organization: Globespan, Inc. X-Mailer: Mozilla 4.72 [en] (WinNT; U) X-Accept-Language: en MIME-Version: 1.0 To: Grenville Armitage CC: Mahalingam Mani , diffserv@ietf.org, l2tp@ipsec.org Subject: Re: [Diffserv] Incompatibility between Diffserv and PPP based tunneling protocols References: <391A6B6E.AD568A04@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 Armitage wrote: > > Mahalingam Mani wrote: > > > > What if the desired PHB is as required on a per-microflow basis - even over > > the > > tunnel? Especially the case with IKE tunnels where one may encounter > > multiple > > DS router hops in the tunnel? > > I'm not really sure how to parse your question. In general > tunnels provide isolation - conventionally just topological > isolation, but increasingly we're having to consider temporal > isolation (aka QoS). So consider the tunnel as becoming more > like a link substitute in that one provisions the tunnel's > temporal characteristics (QoS) to, in the aggregate, support > the mix of traffic flowing through it. In the same way that > we might mix EF and AF traffic on a single T1 line, so we > might mix all sorts of traffic onto a tunnel having a fixed > DSCP of its own. The tunnel's QoS is determined by the outer > DSCP (and the provisioning of the DS routers along the path > followed by the tunnel). What criteria should be used at the tunnel's ingress node to decide the traffic that can go through this tunnel? If the tunnel's DSCP is AF, can one send both EF and AF traffic through it? It may lead to degradation of service for the EF class. Rohit -- Rohit Chhapolia Globespan, Inc. mailto:rohit@globespan.net http://www.globespan.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 May 11 12:40: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 MAA02424 for ; Thu, 11 May 2000 12:40: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 MAA25880; Thu, 11 May 2000 12: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 MAA25849 for ; Thu, 11 May 2000 12:12: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 MAA01649 for ; Thu, 11 May 2000 12:11:58 -0400 (EDT) Received: from zubin.dnrc.bell-labs.com ([135.180.130.56]) by dirty; Thu May 11 12:11:02 EDT 2000 Received: from dnrc.bell-labs.com (ex-vpn64.pa.bell-labs.com [135.250.1.64]) by zubin.dnrc.bell-labs.com (8.9.3/8.9.3) with ESMTP id MAA15421; Thu, 11 May 2000 12:10:55 -0400 (EDT) Message-ID: <391ADC66.90872B8E@dnrc.bell-labs.com> Date: Thu, 11 May 2000 09:14:30 -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: Rohit Chhapolia CC: diffserv@ietf.org, l2tp@ipsec.org Subject: Re: [Diffserv] Incompatibility between Diffserv and PPP based tunneling protocols References: <391A6B6E.AD568A04@dnrc.bell-labs.com> <391AAFC5.3610EA8D@globespan.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 Rohit Chhapolia wrote: [..] > What criteria should be used at the tunnel's ingress node to > decide the traffic that can go through this tunnel? If the > tunnel's DSCP is AF, can one send both EF and AF traffic > through it? It may lead to degradation of service for the EF class. In general the answer is more like 'it depends'. Since the tunnel becomes more like a link, we need to understand its ingress->egress QoS characteristics before we can decide how well it would support any given mix of tunneled traffic. Unfortunately knowledge of the tunnel's PHB alone doesn't tell us all there is to know - it will depend on network topology and router provisioning along the tunnel's path. This is the nature of Diffserv (to date, although people are working on defining e2e behaviors built from per hop behaviors) 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 May 11 15:41: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 PAA06799 for ; Thu, 11 May 2000 15:41: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 PAA28770; Thu, 11 May 2000 15:25: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 PAA28739 for ; Thu, 11 May 2000 15: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 PAA06452 for ; Thu, 11 May 2000 15:25:28 -0400 (EDT) Received: from sp3at21.hursley.ibm.com (sp3at21.hursley.ibm.com [9.20.45.21]) by mail-gw.hursley.ibm.com (AIX4.3/UCB 8.8.8/8.8.8) with ESMTP id UAA54880 for ; Thu, 11 May 2000 20:24:57 +0100 Received: from hursley.ibm.com (gsine03.us.sine.ibm.com [9.14.6.43]) by sp3at21.hursley.ibm.com (AIX4.2/UCB 8.7/8.7.3) with ESMTP id UAA14236 for ; Thu, 11 May 2000 20:24:56 +0100 (BST) Message-ID: <391B069E.BA48CF84@hursley.ibm.com> Date: Thu, 11 May 2000 14:14: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: Diff Serv References: <39102AD6.735CEB2F@hursley.ibm.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Subject: [Diffserv] Re: WG poll on choice of terminology Sender: diffserv-admin@ietf.org Errors-To: diffserv-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 poll ended yesterday. After removing one or two duplicates, the result was 23 people who preferred Per-Domain Behavior versus 16 who preferred Intra-Domain Service. This is a fairly rough consensus, but clear enough for a terminology choice. So Per-Domain Behavior it is, and the next version of the ""BA"" draft will reflect this. Brian + Kathie Brian E Carpenter wrote: > > Diffservers, > > The use of the term "behavior aggregate" to recurse to > cover an entire DS domain has been a matter of controversy > at the Adelaide IETF and on the mailing list. Sifting > through public and private emails on this, we've found that > the intent of draft-ietf-diffserv-ba-def-01.txt is nicely covered > by either of two terms. We'd like to see what the WG consensus choice > is so that we can use this in the next document revision. > > The proposed terms are: > > 1) per-domain behavior (PDB) > or > 2) intra-domain service (IDS) > > These are intended to be defined upon a specific DS domain (as > defined in RFCs 2474 & 2475), though of course, any particular > definition may impose further constraints on the topology or > technology of DS domain for which it is useful. > > Please indicate your choice of terminology in a one line > reply with one choice - PDB or IDS - to brian@icair.org > (not to the whole list please!!!) by May 10 at the latest. > We'll total the results and declare a winner. > > If you want to discuss/debate further please do this on the > list with a different subject header. > > Thanks > > Brian + Kathie > diffserv co-chairs _______________________________________________ diffserv mailing list diffserv@ietf.org http://www1.ietf.org/mailman/listinfo/diffserv Archive: http://www-nrg.ee.lbl.gov/diff-serv-arch/ From diffserv-admin@ietf.org Thu May 11 16:31:48 2000 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA07680 for ; Thu, 11 May 2000 16:31:48 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id QAA29444; Thu, 11 May 2000 16:10: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 QAA29413 for ; Thu, 11 May 2000 16:10:31 -0400 (EDT) Received: from mail-gw.hursley.ibm.com (mail-gw.hursley.ibm.com [194.196.110.15]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA07223 for ; Thu, 11 May 2000 16:10: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 VAA50066; Thu, 11 May 2000 21:09:12 +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 VAA16378; Thu, 11 May 2000 21:09:09 +0100 (BST) Message-ID: <391B135A.4A221D8A@hursley.ibm.com> Date: Thu, 11 May 2000 15:08:58 -0500 From: Brian E Carpenter Organization: IBM X-Mailer: Mozilla 4.61 [en] (Win98; I) X-Accept-Language: en,fr MIME-Version: 1.0 To: Grenville Armitage CC: Rohit Chhapolia , diffserv@ietf.org, l2tp@ipsec.org, David Black Subject: Re: [Diffserv] Incompatibility between Diffserv and PPP based tunneling protocols References: <391A6B6E.AD568A04@dnrc.bell-labs.com> <391AAFC5.3610EA8D@globespan.net> <391ADC66.90872B8E@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 Three comments (on the whole thread): 1. The correct place to write up the conclusion of this, when we reach one, is in draft-ietf-diffserv-tunnels-00.txt as revised. 2. Remember that the diffserv rule that microflows must not be reordered is met by not reordering the whole BA, and is also met by not reordering the whole tunnel. It is completely conformant with diffserv to perform no reordering whatever. Viewed that way there is no problem, just an implementation constraint. 3. We might need to add some words to RFC 2598 section 2.5, but I see no problem in enclosing an EF flow and other flows such as BE or AF within an EF tunnel, as long as the tunnel has adequate bandwidth and admission control. That's why we call it virtual wire. Brian Grenville Armitage wrote: > > Rohit Chhapolia wrote: > [..] > > What criteria should be used at the tunnel's ingress node to > > decide the traffic that can go through this tunnel? If the > > tunnel's DSCP is AF, can one send both EF and AF traffic > > through it? It may lead to degradation of service for the EF class. > > In general the answer is more like 'it depends'. Since the > tunnel becomes more like a link, we need to understand its > ingress->egress QoS characteristics before we can decide > how well it would support any given mix of tunneled traffic. > Unfortunately knowledge of the tunnel's PHB alone doesn't > tell us all there is to know - it will depend on network > topology and router provisioning along the tunnel's path. > This is the nature of Diffserv (to date, although people are > working on defining e2e behaviors built from per hop behaviors) > > 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 May 11 16:56: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 QAA08076 for ; Thu, 11 May 2000 16:56: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 QAA29816; Thu, 11 May 2000 16:38: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 QAA29785 for ; Thu, 11 May 2000 16:38: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 QAA07808 for ; Thu, 11 May 2000 16:38: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 NAA21178 for ; Thu, 11 May 2000 13:38:01 -0700 (PDT) Received: by nt-exchange1.pmc-sierra.bc.ca with Internet Mail Service (5.5.2650.21) id ; Thu, 11 May 2000 13:38:02 -0700 Message-ID: <336ECDAFDF7DD311B9E30090277AEE4101B40558@nt-exchange-bby.pmc-sierra.bc.ca> From: Shahram Davari To: diffserv@ietf.org Subject: RE: [Diffserv] Incompatibility between Diffserv and PPP based tun neling protocols Date: Thu, 11 May 2000 13:35: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 Hi, In the tunneling draft there are two types of tunnels: 1) Uniform 2) Pipe In the Uniform case, the tunnel supports the same PHB as the tunneled flow. In this case it seems logical to use multiple parallel tunnels to support all tunneled PHBs. This is analogous to using multiple L-LSP tunnels. In case of Pipe model, the tunnel may support a different PHB from the tunneled flow. In this case, it may be possible to support all tunneled PHBs with only one tunnel PHB. As Brian pointed out, an example is to choose EF for the tunnel, then you could support almost all other PHBs. -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 Thu May 11 19:20:51 2000 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA10727 for ; Thu, 11 May 2000 19:20:51 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id SAA01189; Thu, 11 May 2000 18:50:19 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id SAA01148 for ; Thu, 11 May 2000 18:50:14 -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 SAA09929 for ; Thu, 11 May 2000 18:50:11 -0400 (EDT) From: Black_David@emc.com Received: by mxbh4.isus.emc.com with Internet Mail Service (5.5.2448.0) id ; Thu, 11 May 2000 18:49:43 -0400 Message-ID: <0F31E5C394DAD311B60C00E029101A070148F8AF@CORPMX9> To: rajeshsu@exchange.microsoft.com, diffserv@ietf.org, l2tp@ipsec.org Cc: Black_David@emc.com Subject: RE: [Diffserv] Incompatibility between Diffserv and PPP based tun neling protocols Date: Thu, 11 May 2000 18:49:42 -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 Back to the original problem scenario: > Let's assume that there are two micro-flows of traffic within a single L2TP tunnel, marked for different PHBs. > The DSCP mark has to be propagated from the original packet to the tunneled header at tunnel ingress > (as per section 2.5 of EF PHB). The restrictions on packet re-order apply only to a packets belonging to > a micro flow within a particular PHB class. So, it is possible for packets belonging to different PHBs to get > re-ordered by DS aware nodes en-route to tunnel egress. > > This re-ordering breaks PPTP and L2TP. This seems to be a classic "Doctor it hurts when I do *this*. -- Don't do that." scenario. The easiest solution is to mark EF on all the outer headers. Beyond that, upon reflection, the "must" in Section 2.5 of the EF RFC appears to be overstated - it probably ought to be a "should", perhaps accompanied by language like that in Section 5 of the AF RFC. There are circumstances under which EF can be run through a non-EF tunnel without damage (e.g., overprovisioned AF), but it is necessary to understand what one is doing. This leads to a solution with AF or a non-zero class selector in the outer header of the tunneled packets. > One way of solving this problem is to create multiple L2TP or PPTP sessions and by > dedicating one PHB for each session. Since both L2TP and PPTP allow re-ordering > across sessions, the packet re-order problem is not as nasty. This looks like the right solution - in essence to run multiple BAs among which reordering is desired through a tunneling protocol that cannot tolerate reordering, one needs to use multiple tunnels (e.g., one per BA). For the examples being discussed, this should "just work", as each L2TP or PPTP session will appear to be a single microflow to the diffserv-aware nodes and hence be governed by the diffserv injunctions against reordering packets in a microflow -- this seems like something that could be productively clarified in the next version of the tunnels draft, as it's not immediately obvious from the existing documents. A couple of other notes on points raised in the discussion: > The suggestion to split the two microflows into 2 different tunnels will work, > however with thousands of tunnels to manage in an enterprise/carrier-class VPN > setup this will become an administrative nightmare. If the tunnels are per-BA rather than per-microflow, the resulting administrative consequences should be manageable. If not, there's always the option of choosing not to make diffserv forwarding distinctions within the tunnel - there's an instance of the "no free lunch" principle here. > What criteria should be used at the tunnel's ingress node to > decide the traffic that can go through this tunnel? If the > tunnel's DSCP is AF, can one send both EF and AF traffic > through it? It may lead to degradation of service for the EF class. While it may seem like hair-splitting, this is really a traffic and network engineering problem. Diffserv can say that "degradation of service for the EF class" is wrong, but leaves it to network and equipment designers/implementers to figure out how to make sure it doesn't happen. Diffserv is not a substitute for competent network/traffic design/engineering. I think Grenville's already made basically this point. As Brian noted, this is a great opportunity to figure out what else ought to be in the tunnels draft - as the author of that draft, I'm open to any and all suggestions that will help avoid future confusion. 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 May 12 16:23:43 2000 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA13750 for ; Fri, 12 May 2000 16:23: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 PAA18456; Fri, 12 May 2000 15:51: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 PAA18425 for ; Fri, 12 May 2000 15:51:09 -0400 (EDT) Received: from sj-msg-core-1.cisco.com (sj-msg-core-1.cisco.com [171.71.163.11]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA12554 for ; Fri, 12 May 2000 15:51:08 -0400 (EDT) Received: from airborne.cisco.com (airborne.cisco.com [171.71.154.32]) by sj-msg-core-1.cisco.com (8.9.3/8.9.1) with ESMTP id MAA27080; Fri, 12 May 2000 12:50:15 -0700 (PDT) Received: from cisco.com (sjck-dial-gw5-151.cisco.com [10.19.238.152]) by airborne.cisco.com (Mirapoint) with ESMTP id AAO14384; Fri, 12 May 2000 12:50:06 -0700 (PDT) Message-ID: <391C364E.FD4D839F@cisco.com> Date: Fri, 12 May 2000 09:50:22 -0700 From: Scott Brim X-Mailer: Mozilla 4.72 [en] (WinNT; I) X-Accept-Language: en MIME-Version: 1.0 To: Mahalingam Mani CC: Grenville Armitage , diffserv@ietf.org, l2tp@ipsec.org Subject: Re: [Diffserv] Incompatibility between Diffserv and PPP based tunneling protocols References: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: diffserv-admin@ietf.org Errors-To: diffserv-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Diffserv Discussion List X-BeenThere: diffserv@ietf.org Content-Transfer-Encoding: 7bit If you want different treatment you should use different tunnels (until we figure out something better). Mahalingam Mani wrote: > What if the desired PHB is as required on a per-microflow basis - even over > the > tunnel? Especially the case with IKE tunnels where one may encounter > multiple > DS router hops in the tunnel? _______________________________________________ diffserv mailing list diffserv@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 May 12 18: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 SAA16986 for ; Fri, 12 May 2000 18: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 RAA19737; Fri, 12 May 2000 17:47: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 RAA19706 for ; Fri, 12 May 2000 17:47:15 -0400 (EDT) Received: from dfssl.exchange.microsoft.com ([131.107.88.59]) by ietf.org (8.9.1a/8.9.1a) with SMTP id RAA16783 for ; Fri, 12 May 2000 17:47:13 -0400 (EDT) Received: from 172.30.236.11 by dfssl.exchange.microsoft.com (InterScan E-Mail VirusWall NT); Fri, 12 May 2000 14:33:40 -0700 (Pacific Daylight Time) Received: from SIT.platinum.corp.microsoft.com ([172.30.236.233]) by yuri.dns.microsoft.com with Microsoft SMTPSVC(5.0.2195.2023); Fri, 12 May 2000 14:40:50 -0700 content-class: urn:content-classes:message Subject: RE: [Diffserv] Incompatibility between Diffserv and PPP based tunneling protocols MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01BFBC59.E2EDA6C0" Date: Fri, 12 May 2000 14:34:43 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.0.4366.0 Message-ID: <19398D273324D3118A2B0008C7E9A5690681E0DB@SIT.platinum.corp.microsoft.com> Thread-Topic: [Diffserv] Incompatibility between Diffserv and PPP based tunneling protocols Thread-Index: Ab+7hlgdiQdbZLGOQZSL7VpK8iMeQwAvEZGA From: "Rajesh Sundaram" To: "Brian E Carpenter" , "Grenville Armitage" , "David Black" Cc: , X-OriginalArrivalTime: 12 May 2000 21:40:50.0242 (UTC) FILETIME=[BD860A20:01BFBC5A] Sender: diffserv-admin@ietf.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_01BFBC59.E2EDA6C0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable So far, there are two proposed solutions to this problem.=20 a) Mark the outer header packets of all tunneled packets with a uniform codepoint.=20 As Brian pointed out, this treats the tunnel like a virtual wire and works well as long as there is sufficient bandwidth. But, there could be a problem if EF bandwidth was limited. By multiplexing data and EF onto an EF tunnel, we are increasing the probability of getting policed at a DS boundary, and thereby breaking the guarantees of inner EF traffic. b) Create a (small) set of multiple tunnels, each tunnel getting a fixed codepoint, that is distinct from other tunnels. All packets on a particular tunnel carry the same uniform codepoint. Before tunnel encapsulation, inspect the inner codepoint of the packet and route the packet to the appropriate tunnel. I had not necessarily suggested creating a different tunnel for each PHB (or for each micro-flow). By creating a smaller set of tunnels, we are reducing the management overhead. This approach would need a mapping of inner DSCPs --> outer DSCPs, which is probably controlled by the local tunnel administrator. The first approach seems to be a special case of the second one (where there all inner DSCPs map to a uniform outer DSCP). Also, the second one is more flexible. I'd appreciate comments that help us make a decision on this.=20 Thanks, Rajesh -----Original Message----- From: Brian E Carpenter [mailto:brian@hursley.ibm.com] Sent: Thursday, May 11, 2000 1:09 PM To: Grenville Armitage Cc: Rohit Chhapolia; diffserv@ietf.org; l2tp@ipsec.org; David Black Subject: Re: [Diffserv] Incompatibility between Diffserv and PPP based tunneling protocols Three comments (on the whole thread): 1. The correct place to write up the conclusion of this, when we reach one, is in draft-ietf-diffserv-tunnels-00.txt as revised. 2. Remember that the diffserv rule that microflows must not be reordered is met by not reordering the whole BA, and is also met by not reordering the whole tunnel. It is completely conformant with diffserv to perform no reordering whatever. Viewed that way there is no problem, just an implementation constraint. 3. We might need to add some words to RFC 2598 section 2.5, but I see no problem in enclosing an EF flow and other flows such as BE or AF within an EF tunnel, as long as the tunnel has adequate bandwidth and admission control. That's why we call it virtual wire. Brian Grenville Armitage wrote: >=20 > Rohit Chhapolia wrote: > [..] > > What criteria should be used at the tunnel's ingress node to > > decide the traffic that can go through this tunnel? If the > > tunnel's DSCP is AF, can one send both EF and AF traffic > > through it? It may lead to degradation of service for the EF class. >=20 > In general the answer is more like 'it depends'. Since the > tunnel becomes more like a link, we need to understand its > ingress->egress QoS characteristics before we can decide > how well it would support any given mix of tunneled traffic. > Unfortunately knowledge of the tunnel's PHB alone doesn't > tell us all there is to know - it will depend on network > topology and router provisioning along the tunnel's path. > This is the nature of Diffserv (to date, although people are > working on defining e2e behaviors built from per hop behaviors) >=20 > cheers, > gja > ________________________________________________________________________ > Grenville Armitage 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/ _______________________________________________ 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_01BFBC59.E2EDA6C0 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable RE: [Diffserv] Incompatibility between Diffserv and PPP based = tunneling protocols

So far, there are two proposed solutions to this = problem.

a) Mark the outer header packets of all tunneled = packets with a uniform codepoint.

As Brian pointed out, this treats the tunnel like a = virtual wire and works well as long as there is sufficient bandwidth. = But, there could be a problem if EF bandwidth was limited. By = multiplexing data and EF onto an EF tunnel, we are increasing the = probability of getting policed at a DS boundary, and thereby breaking = the guarantees of inner EF traffic.

b) Create a (small) set of multiple tunnels, each = tunnel getting a fixed codepoint, that is distinct from other tunnels. = All packets on a particular tunnel carry the same uniform codepoint. = Before tunnel encapsulation, inspect the inner codepoint of the packet = and route the packet to the appropriate tunnel.

I had not necessarily suggested creating a different = tunnel for each PHB (or for each micro-flow). By creating a smaller set = of tunnels, we are reducing the management overhead. This approach would = need a mapping of inner DSCPs --> outer DSCPs, which is probably = controlled by the local tunnel administrator.

The first approach seems to be a special case of the = second one (where there all inner DSCPs map to a uniform outer DSCP). = Also, the second one is more flexible. I'd appreciate comments that help = us make a decision on this.

Thanks,
Rajesh

-----Original Message-----
From: Brian E Carpenter [mailto:brian@hursley.ibm.com]
Sent: Thursday, May 11, 2000 1:09 PM
To: Grenville Armitage
Cc: Rohit Chhapolia; diffserv@ietf.org; = l2tp@ipsec.org; David Black
Subject: Re: [Diffserv] Incompatibility between = Diffserv and PPP based
tunneling protocols


Three comments (on the whole thread):

1. The correct place to write up the conclusion of = this, when we
reach one, is in draft-ietf-diffserv-tunnels-00.txt = as revised.

2. Remember that the diffserv rule that microflows = must not
be reordered is met by not reordering the whole BA, = and is
also met by not reordering the whole tunnel. It is = completely
conformant with diffserv to perform no reordering = whatever.
Viewed that way there is no problem, just an = implementation
constraint.

3. We might need to add some words to RFC 2598 section = 2.5,
but I see no problem in enclosing an EF flow and = other flows
such as BE or AF within an EF tunnel, as long as the = tunnel
has adequate bandwidth and admission control. That's = why we
call it virtual wire.

   Brian

Grenville Armitage wrote:
>
> Rohit Chhapolia wrote:
>         = [..]
> > What criteria should be used at the = tunnel's ingress node to
> > decide the traffic that can go through this = tunnel? If the
> > tunnel's DSCP is AF, can one send both EF = and AF traffic
> > through it? It may lead to degradation of = service for the EF class.
>
> In general the answer is more like 'it depends'. = Since the
> tunnel becomes more like a link, we need to = understand its
> ingress->egress QoS characteristics before we = can decide
> how well it would support any given mix of = tunneled traffic.
> Unfortunately knowledge of the tunnel's PHB = alone doesn't
> tell us all there is to know - it will depend on = network
> topology and router provisioning along the = tunnel's path.
> This is the nature of Diffserv (to date, = although people are
> working on defining e2e behaviors built from per = hop behaviors)
>
> cheers,
> gja
> = ________________________________________________________________________<= /FONT>
> 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/

_______________________________________________
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_01BFBC59.E2EDA6C0-- _______________________________________________ diffserv mailing list diffserv@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 May 12 19:53: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 TAA18280 for ; Fri, 12 May 2000 19:53: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 TAA20779; Fri, 12 May 2000 19:32: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 TAA20748 for ; Fri, 12 May 2000 19:32:03 -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 TAA17966 for ; Fri, 12 May 2000 19:31:59 -0400 (EDT) Received: from zubin.dnrc.bell-labs.com ([135.180.130.56]) by dirty; Fri May 12 19:30:30 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 TAA00758; Fri, 12 May 2000 19:30:26 -0400 (EDT) Message-ID: <391C94E5.EF560BF0@dnrc.bell-labs.com> Date: Fri, 12 May 2000 16:33:57 -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: Rajesh Sundaram CC: diffserv@ietf.org, l2tp@ipsec.org Subject: Re: [Diffserv] Incompatibility between Diffserv and PPP based tunneling protocols References: <19398D273324D3118A2B0008C7E9A5690681E0DB@SIT.platinum.corp.microsoft.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 > Rajesh Sundaram wrote: [..] > The first approach seems to be a special case of the second one (where there > all inner DSCPs map to a uniform outer DSCP). Also, the second one is more > flexible. Naturally - by construction, since the "use a single tunnel like a wire" is going to be a subset of any other scheme that involves more than one tunnel. Certainly when I suggested simply using a fixed DSCP for each L2TP tunnel I did not intend that to be interpreted as "you can only have one tunnel". > I'd appreciate comments that help us make a decision on this. Implement something that allows flexible mapping rules. Perhaps it would be easier to codify rules if we keep in mind that the DSCP for the outer (tunneling) IP header is really only providing service to the PPP session being tunneled. The PPP session(s) are then (in the abstract at least) providing the 'wire' for the (many) IP flows being mapped onto each PPP session. Now, as I understand it, the premise of this thread is that you dont want reordering of PPP frames within a single session. Simple conclusion - when an L2TP tunnel supports a distinct PPP session, that tunnel's outer IP header ought to have a fixed DSCP (or at least a DSCP from a PHB Group that enforces non-reordering). Beyond that, how you choose to map particular classes of tunneled IP traffic onto particular PPP sessions is another discussion entirely.... cheers, gja ________________________________________________________________________ Grenville Armitage http://members.home.net/garmitage/ Bell Labs Research Silicon Valley _______________________________________________ diffserv mailing list diffserv@ietf.org http://www1.ietf.org/mailman/listinfo/diffserv Archive: http://www-nrg.ee.lbl.gov/diff-serv-arch/ From diffserv-admin@ietf.org Fri May 12 19: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 TAA18398 for ; Fri, 12 May 2000 19: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 TAA20965; Fri, 12 May 2000 19:43: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 TAA20858 for ; Fri, 12 May 2000 19:42:10 -0400 (EDT) Received: from amberex01.ambernetworks.com (outgate01.ambernetworks.com [207.20.187.199]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA18045 for ; Fri, 12 May 2000 19:42:07 -0400 (EDT) Received: by amberex01.ambernetworks.com with Internet Mail Service (5.5.2448.0) id ; Fri, 12 May 2000 16:43:11 -0700 Message-ID: <405CAE450410D311B26C0050047326DC6B7A51@amberex01.ambernetworks.com> From: Andy Koscinski To: Rajesh Sundaram , Brian E Carpenter , Grenville Armitage , David Black Cc: diffserv@ietf.org, l2tp@ipsec.org Subject: RE: [Diffserv] Incompatibility between Diffserv and PPP based tun neling protocols Date: Fri, 12 May 2000 16:43:10 -0700 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2448.0) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01BFBC6B.D4B4CD20" Sender: diffserv-admin@ietf.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_01BFBC6B.D4B4CD20 Content-Type: text/plain; charset="windows-1252" -----Original Message----- From: Rajesh Sundaram [mailto:rajeshsu@Exchange.Microsoft.com] Sent: Friday, May 12, 2000 2:35 PM To: Brian E Carpenter; Grenville Armitage; David Black Cc: diffserv@ietf.org; l2tp@ipsec.org Subject: RE: [Diffserv] Incompatibility between Diffserv and PPP based tunneling protocols So far, there are two proposed solutions to this problem. a) Mark the outer header packets of all tunneled packets with a uniform codepoint. As Brian pointed out, this treats the tunnel like a virtual wire and works well as long as there is sufficient bandwidth. But, there could be a problem if EF bandwidth was limited. By multiplexing data and EF onto an EF tunnel, we are increasing the probability of getting policed at a DS boundary, and thereby breaking the guarantees of inner EF traffic. b) Create a (small) andyk> yes, but why small? should cover all required DSCP's. > set of multiple tunnels, each tunnel getting a fixed codepoint, that is distinct from other tunnels. All packets on a particular tunnel carry the same uniform codepoint. Before tunnel encapsulation, inspect the inner codepoint of the packet and route the packet to the appropriate tunnel. andyk> I would replace the word "tunnel" by a "l2tp session" in the above sentence. There is a "l2tp-DS-draft-extension" which suggests a negotiable outer DSCP per session, not per tunnel. Each microflow with an unique DSCP requirement maps into one l2tp session with and individual outer DSCP, which migt be different from the outer tunnel DSCP and also might be different from the inner DSCP (or TOS) of the microflow at tunnel ingress. The packet sequence in every session (microflow) is preserved, if packet sequencing is enabled. In addition the micro flow might have a packet sequencing of it's own, on the higher layer protocol. I think the outer DSCP per l2tp session should be unidirectional, and might be diferent for the l2tp payload flowing in two different directions. thx andy I had not necessarily suggested creating a different tunnel for each PHB (or for each micro-flow). By creating a smaller set of tunnels, we are reducing the management overhead. This approach would need a mapping of inner DSCPs --> outer DSCPs, which is probably controlled by the local tunnel administrator. The first approach seems to be a special case of the second one (where there all inner DSCPs map to a uniform outer DSCP). Also, the second one is more flexible. I'd appreciate comments that help us make a decision on this. Thanks, Rajesh -----Original Message----- From: Brian E Carpenter [ mailto:brian@hursley.ibm.com ] Sent: Thursday, May 11, 2000 1:09 PM To: Grenville Armitage Cc: Rohit Chhapolia; diffserv@ietf.org; l2tp@ipsec.org; David Black Subject: Re: [Diffserv] Incompatibility between Diffserv and PPP based tunneling protocols Three comments (on the whole thread): 1. The correct place to write up the conclusion of this, when we reach one, is in draft-ietf-diffserv-tunnels-00.txt as revised. 2. Remember that the diffserv rule that microflows must not be reordered is met by not reordering the whole BA, and is also met by not reordering the whole tunnel. It is completely conformant with diffserv to perform no reordering whatever. Viewed that way there is no problem, just an implementation constraint. 3. We might need to add some words to RFC 2598 section 2.5, but I see no problem in enclosing an EF flow and other flows such as BE or AF within an EF tunnel, as long as the tunnel has adequate bandwidth and admission control. That's why we call it virtual wire. Brian Grenville Armitage wrote: > > Rohit Chhapolia wrote: > [..] > > What criteria should be used at the tunnel's ingress node to > > decide the traffic that can go through this tunnel? If the > > tunnel's DSCP is AF, can one send both EF and AF traffic > > through it? It may lead to degradation of service for the EF class. > > In general the answer is more like 'it depends'. Since the > tunnel becomes more like a link, we need to understand its > ingress->egress QoS characteristics before we can decide > how well it would support any given mix of tunneled traffic. > Unfortunately knowledge of the tunnel's PHB alone doesn't > tell us all there is to know - it will depend on network > topology and router provisioning along the tunnel's path. > This is the nature of Diffserv (to date, although people are > working on defining e2e behaviors built from per hop behaviors) > > 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/ ------_=_NextPart_001_01BFBC6B.D4B4CD20 Content-Type: text/html; charset="windows-1252" RE: [Diffserv] Incompatibility between Diffserv and PPP based tunneling protocols
 
 
-----Original Message-----
From: Rajesh Sundaram [mailto:rajeshsu@Exchange.Microsoft.com]
Sent: Friday, May 12, 2000 2:35 PM
To: Brian E Carpenter; Grenville Armitage; David Black
Cc: diffserv@ietf.org; l2tp@ipsec.org
Subject: RE: [Diffserv] Incompatibility between Diffserv and PPP based tunneling protocols

So far, there are two proposed solutions to this problem.

a) Mark the outer header packets of all tunneled packets with a uniform codepoint.

As Brian pointed out, this treats the tunnel like a virtual wire and works well as long as there is sufficient bandwidth. But, there could be a problem if EF bandwidth was limited. By multiplexing data and EF onto an EF tunnel, we are increasing the probability of getting policed at a DS boundary, and thereby breaking the guarantees of inner EF traffic.

  b) Create a (small)  

andyk> yes, but why small? should cover all required DSCP's.

> set of multiple tunnels,  

 each tunnel getting a fixed codepoint, that is distinct from other tunnels. All packets on a particular tunnel carry the same uniform codepoint. Before tunnel encapsulation, inspect the inner codepoint of the packet and route the packet to the appropriate tunnel. 

andyk> I would replace the word "tunnel" by a "l2tp session" in the above sentence. There is a "l2tp-DS-draft-extension" which suggests a negotiable outer DSCP per session,

not per tunnel. Each microflow with an unique DSCP requirement maps into one l2tp session with and individual outer DSCP, which migt be different from the outer tunnel DSCP

and also might be different from the inner DSCP (or TOS) of the microflow at tunnel ingress.

The packet sequence in every session (microflow) is preserved, if packet sequencing is enabled. In addition the micro flow

might have a packet sequencing of it's own, on the higher layer protocol.

 

 I think the outer DSCP per l2tp session should be unidirectional,

and might be diferent for the l2tp payload flowing in two different directions.

thx

andy 

 

 I had not necessarily suggested creating a different tunnel for each PHB (or for each micro-flow). By creating a smaller set of tunnels, we are reducing the management overhead. This approach would need a mapping of inner DSCPs --> outer DSCPs, which is probably controlled by the local tunnel administrator.

The first approach seems to be a special case of the second one (where there all inner DSCPs map to a uniform outer DSCP). Also, the second one is more flexible. I'd appreciate comments that help us make a decision on this.

Thanks,
Rajesh

-----Original Message-----
From: Brian E Carpenter [mailto:brian@hursley.ibm.com]
Sent: Thursday, May 11, 2000 1:09 PM
To: Grenville Armitage
Cc: Rohit Chhapolia; diffserv@ietf.org; l2tp@ipsec.org; David Black
Subject: Re: [Diffserv] Incompatibility between Diffserv and PPP based
tunneling protocols


Three comments (on the whole thread):

1. The correct place to write up the conclusion of this, when we
reach one, is in draft-ietf-diffserv-tunnels-00.txt as revised.

2. Remember that the diffserv rule that microflows must not
be reordered is met by not reordering the whole BA, and is
also met by not reordering the whole tunnel. It is completely
conformant with diffserv to perform no reordering whatever.
Viewed that way there is no problem, just an implementation
constraint.

3. We might need to add some words to RFC 2598 section 2.5,
but I see no problem in enclosing an EF flow and other flows
such as BE or AF within an EF tunnel, as long as the tunnel
has adequate bandwidth and admission control. That's why we
call it virtual wire.

   Brian

Grenville Armitage wrote:
>
> Rohit Chhapolia wrote:
>         [..]
> > What criteria should be used at the tunnel's ingress node to
> > decide the traffic that can go through this tunnel? If the
> > tunnel's DSCP is AF, can one send both EF and AF traffic
> > through it? It may lead to degradation of service for the EF class.
>
> In general the answer is more like 'it depends'. Since the
> tunnel becomes more like a link, we need to understand its
> ingress->egress QoS characteristics before we can decide
> how well it would support any given mix of tunneled traffic.
> Unfortunately knowledge of the tunnel's PHB alone doesn't
> tell us all there is to know - it will depend on network
> topology and router provisioning along the tunnel's path.
> This is the nature of Diffserv (to date, although people are
> working on defining e2e behaviors built from per hop behaviors)
>
> 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/

------_=_NextPart_001_01BFBC6B.D4B4CD20-- _______________________________________________ diffserv mailing list diffserv@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 May 12 20:07:17 2000 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA18673 for ; Fri, 12 May 2000 20:07:17 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id TAA21125; Fri, 12 May 2000 19:54: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 TAA21092 for ; Fri, 12 May 2000 19:54:30 -0400 (EDT) Received: from mailsrv.acc.com (mailsrv.acc.com [129.192.64.128]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA18325 for ; Fri, 12 May 2000 19:54:28 -0400 (EDT) Received: from ericsson.com (unk105122.acc.com [129.192.105.122]) by mailsrv.acc.com (8.9.3/8.9.1) with ESMTP id QAA06169; Fri, 12 May 2000 16:57:23 -0700 (PDT) Message-ID: <391C9A79.1DF83255@ericsson.com> Date: Fri, 12 May 2000 16:57:45 -0700 From: Evan Caves X-Mailer: Mozilla 4.61 [en] (WinNT; U) X-Accept-Language: en MIME-Version: 1.0 To: Rajesh Sundaram CC: diffserv@ietf.org, l2tp@ipsec.org Subject: Re: [Diffserv] Incompatibility between Diffserv and PPP based tunneling protocols References: <19398D273324D3118A2B0008C7E9A5690681E0DB@SIT.platinum.corp.microsoft.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 > Rajesh Sundaram wrote: > > So far, there are two proposed solutions to this problem. > > a) Mark the outer header packets of all tunneled packets with a > uniform codepoint. > > As Brian pointed out, this treats the tunnel like a virtual wire and > works well as long as there is sufficient bandwidth. But, there could > be a problem if EF bandwidth was limited. By multiplexing data and EF > onto an EF tunnel, we are increasing the probability of getting > policed at a DS boundary, and thereby breaking the guarantees of inner > EF traffic. For L2 tunneling protocols this seems to be the only option. For example an L2TP session would be created within a tunnel that provides the per hop behavior for a particular dialin user based on some pre-defined policy. There may be multiple tunnels between the same two endpoints, each providing a different service level. However there could be microflows within the session which themselves are marked differently but are given the outer mark PHB. The microflows within the session cannot be 're-routed' down a different tunnel that maps to the appropriate PHB. As an aside L2TP implementations (at least at the LAC ingress to the tunnel) may 'snoop' the PPP control frames in order to manage payload sequencing but usually do not goes as far as 'snooping' the IP header. evan - > > b) Create a (small) set of multiple tunnels, each tunnel getting a > fixed codepoint, that is distinct from other tunnels. All packets on a > particular tunnel carry the same uniform codepoint. Before tunnel > encapsulation, inspect the inner codepoint of the packet and route the > packet to the appropriate tunnel. > > I had not necessarily suggested creating a different tunnel for each > PHB (or for each micro-flow). By creating a smaller set of tunnels, we > are reducing the management overhead. This approach would need a > mapping of inner DSCPs --> outer DSCPs, which is probably controlled > by the local tunnel administrator. > > The first approach seems to be a special case of the second one (where > there all inner DSCPs map to a uniform outer DSCP). Also, the second > one is more flexible. I'd appreciate comments that help us make a > decision on this. > > Thanks, > Rajesh > > -----Original Message----- > From: Brian E Carpenter [mailto:brian@hursley.ibm.com] > Sent: Thursday, May 11, 2000 1:09 PM > To: Grenville Armitage > Cc: Rohit Chhapolia; diffserv@ietf.org; l2tp@ipsec.org; David Black > Subject: Re: [Diffserv] Incompatibility between Diffserv and PPP based > > tunneling protocols > > Three comments (on the whole thread): > > 1. The correct place to write up the conclusion of this, when we > reach one, is in draft-ietf-diffserv-tunnels-00.txt as revised. > > 2. Remember that the diffserv rule that microflows must not > be reordered is met by not reordering the whole BA, and is > also met by not reordering the whole tunnel. It is completely > conformant with diffserv to perform no reordering whatever. > Viewed that way there is no problem, just an implementation > constraint. > > 3. We might need to add some words to RFC 2598 section 2.5, > but I see no problem in enclosing an EF flow and other flows > such as BE or AF within an EF tunnel, as long as the tunnel > has adequate bandwidth and admission control. That's why we > call it virtual wire. > > Brian > > Grenville Armitage wrote: > > > > Rohit Chhapolia wrote: > > [..] > > > What criteria should be used at the tunnel's ingress node to > > > decide the traffic that can go through this tunnel? If the > > > tunnel's DSCP is AF, can one send both EF and AF traffic > > > through it? It may lead to degradation of service for the EF > class. > > > > In general the answer is more like 'it depends'. Since the > > tunnel becomes more like a link, we need to understand its > > ingress->egress QoS characteristics before we can decide > > how well it would support any given mix of tunneled traffic. > > Unfortunately knowledge of the tunnel's PHB alone doesn't > > tell us all there is to know - it will depend on network > > topology and router provisioning along the tunnel's path. > > This is the nature of Diffserv (to date, although people are > > working on defining e2e behaviors built from per hop behaviors) > > > > 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 May 12 20:49: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 UAA19386 for ; Fri, 12 May 2000 20:49: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 UAA21809; Fri, 12 May 2000 20:34: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 UAA21778 for ; Fri, 12 May 2000 20:34:39 -0400 (EDT) Received: from sj-msg-core-1.cisco.com (sj-msg-core-1.cisco.com [171.71.163.11]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA19222 for ; Fri, 12 May 2000 20:34:37 -0400 (EDT) Received: from airborne.cisco.com (airborne.cisco.com [171.71.154.32]) by sj-msg-core-1.cisco.com (8.9.3/8.9.1) with ESMTP id RAA24639; Fri, 12 May 2000 17:33:44 -0700 (PDT) Received: from sbrim-nt.cisco.com (sjck-dial-gw5-174.cisco.com [10.19.238.175]) by airborne.cisco.com (Mirapoint) with ESMTP id AAQ03033; Fri, 12 May 2000 17:33:18 -0700 (PDT) Message-Id: <4.3.2.3.2.20000512163340.00b44290@airborne.cisco.com> X-Sender: sbrim@airborne.cisco.com X-Mailer: QUALCOMM Windows Eudora Version 4.3.2.3 (Beta) Date: Fri, 12 May 2000 17:32:46 -0700 To: "Rajesh Sundaram" From: Scott W Brim Subject: RE: [Diffserv] Incompatibility between Diffserv and PPP based tunneling protocols Cc: , In-Reply-To: <19398D273324D3118A2B0008C7E9A5690681E0DB@SIT.platinum.corp .microsoft.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 14:34 05/12/2000 -0700, Rajesh Sundaram wrote: >I had not necessarily suggested creating a different tunnel for each PHB >(or for each micro-flow). By creating a smaller set of tunnels, we are >reducing the management overhead. This approach would need a mapping of >inner DSCPs --> outer DSCPs, which is probably controlled by the local >tunnel administrator. If you're just distinguishing according to diff-serv, you want at most a tunnel per per-hop scheduling class (not PHB). There are other multipliers which might come into play, though. For example, if you have VPNs you might need to a way to distinguish them (e.g. by using different tunnels) in order to do fair sharing for your customers. The complexity of what you need to do depends directly on the complexity of the service differentiation you want to deliver. _______________________________________________ diffserv mailing list diffserv@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 May 12 21:42: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 VAA19824 for ; Fri, 12 May 2000 21:42: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 VAA22228; Fri, 12 May 2000 21: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 VAA22198 for ; Fri, 12 May 2000 21:25:57 -0400 (EDT) Received: from drawbridge.ascend.com (drawbridge.ascend.com [198.4.92.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA19622 for ; Fri, 12 May 2000 21:25:53 -0400 (EDT) Received: from fw-ext.ascend.com (fw-ext [198.4.92.5]) by drawbridge.ascend.com (8.9.1a/8.9.1) with SMTP id SAA19384; Fri, 12 May 2000 18:19:00 -0700 (PDT) Received: from russet.ascend.com by fw-ext.ascend.com via smtpd (for drawbridge.ascend.com [198.4.92.1]) with SMTP; 13 May 2000 01:25:53 UT Received: from wopr.eng.ascend.com (wopr.eng.ascend.com [206.65.212.178]) by russet.ascend.com (8.9.1a/8.9.1) with ESMTP id SAA28523; Fri, 12 May 2000 18:25:52 -0700 (PDT) Received: from scamp.eng.ascend.com (scamp.eng.ascend.com [135.140.53.42]) by wopr.eng.ascend.com (8.9.1/8.9.1) with ESMTP id SAA11141; Fri, 12 May 2000 18:25:53 -0700 (PDT) Received: from igoyret-pc.eng.ascend.com by scamp.eng.ascend.com (8.8.8+Sun/SMI-SVR4) id SAA00322; Fri, 12 May 2000 18:25:51 -0700 (PDT) Message-Id: <3.0.5.32.20000512182622.00b079a0@scamp.eng.ascend.com> X-Sender: igoyret@scamp.eng.ascend.com X-Mailer: QUALCOMM Windows Eudora Pro Version 3.0.5 (32) Date: Fri, 12 May 2000 18:26:22 -0700 To: Evan Caves From: Ignacio Goyret Subject: Re: [Diffserv] Incompatibility between Diffserv and PPP based tunneling protocols Cc: Rajesh Sundaram , diffserv@ietf.org, l2tp@ipsec.org In-Reply-To: <391C9A79.1DF83255@ericsson.com> References: <19398D273324D3118A2B0008C7E9A5690681E0DB@SIT.platinum.corp.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 At 04:57 PM 5/12/00 -0700, Evan Caves wrote: >As an aside L2TP implementations (at least at the LAC ingress to the >tunnel) may 'snoop' the PPP control frames in order to manage payload >sequencing but usually do not goes as far as 'snooping' the IP header. And even if they attempted to, they will fail miserably sooner or later because of things like PPP compression, encryption, and MP (you may be looking at just one link out of many and you only look at one fragment of the whole PPP packet). -Ignacio ----------------------------------------------------------------------- Ignacio Goyret, Sr. Software Engineer Voice: (510) 747-2823 Lucent Technologies FAX: (510) 747-2859 1701 Harbor Bay Parkway, Alameda, CA 94502 _______________________________________________ diffserv mailing list diffserv@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 May 16 17:14: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 RAA12670 for ; Tue, 16 May 2000 17:14: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 QAA26995; Tue, 16 May 2000 16:44: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 QAA26964 for ; Tue, 16 May 2000 16:44: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 QAA12281 for ; Tue, 16 May 2000 16:44:06 -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 VAA71606 for ; Tue, 16 May 2000 21:43:34 +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 VAA29176 for ; Tue, 16 May 2000 21:43:33 +0100 (BST) Message-ID: <3921B2CF.301592B0@hursley.ibm.com> Date: Tue, 16 May 2000 15:42:55 -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 References: <38EA58D8.1093335D@hursley.ibm.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Subject: [Diffserv] Re: Behavior Aggregates - where next? Sender: diffserv-admin@ietf.org Errors-To: diffserv-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Diffserv Discussion List X-BeenThere: diffserv@ietf.org Content-Transfer-Encoding: 7bit Obviously, now we've decided to use the phrase Per-Domain Behavior instead of BA (across domains), the attached is slightly out of date- the definition of BA in RFC 2475 does not need to be updated. The rest is still valid if you replace BA by PDB. Brian Brian E Carpenter wrote: > > Following the diffserv discussion in Adelaide, we would like to > clarify the motivation and direction for the work on BAs. > > Firstly, to clear out a terminology issue, the formal definition of > a BA in RFC 2475 is slightly too restrictive and will require updating. > > Secondly, the plan is to continue the bottom-up approach adopted > from the start of the diffserv work. Having defined a set of PHBs, > the next step is to identify and quantify the characteristics > that packets belonging to a behavior aggregate will experience as > they cross a DS domain. This can result in an edge-to-edge quality > of service definition. Enterprise network managers, and many ISPs, > need a range of such definitions with numeric parameters, as an aid > to deploying diffserv in a useful way. The diffserv WG charter was > recently updated in response to this need. > > Thirdly, the intention now is to clarify > draft-ietf-diffserv-ba-def-01.txt in view of the discussion. > Also draft-ietf-diffserv-ba-vw-00.txt is a first draft of > a "worked example" of a BA and it will undergo more revision. > > Finally, other BA drafts related to the various standard PHBs, > including the Class Selectors, are solicited. > > Brian and Kathie > diffserv co-chairs -- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - 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 May 17 03:27: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 DAA00825 for ; Wed, 17 May 2000 03:27: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 DAA07490; Wed, 17 May 2000 03:09: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 DAA07459 for ; Wed, 17 May 2000 03:08:59 -0400 (EDT) Received: from hd2.dot.net.in (hd2.vsnl.net.in [202.54.30.2]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA00698 for ; Wed, 17 May 2000 03:08:57 -0400 (EDT) Received: from hyd.chiplogic.com ([203.197.20.108]) by hd2.dot.net.in (8.8.8/8.8.8) with ESMTP id MAA31058 for ; Wed, 17 May 2000 12:36:56 +0530 (IST) Received: from snaidu ([192.168.2.96]) by hyd.chiplogic.com (8.8.7/8.8.7) with SMTP id MAA23175 for ; Wed, 17 May 2000 12:27:25 +0530 From: "snaidu" To: Date: Wed, 17 May 2000 12:40:28 +0530 Message-ID: <01bfbfce$fb1c3040$6002a8c0@snaidu> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0018_01BFBFFD.14D46C40" X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 4.71.1712.3 X-MimeOLE: Produced By Microsoft MimeOLE V4.71.1712.3 Subject: [Diffserv] (no subject) Sender: diffserv-admin@ietf.org Errors-To: diffserv-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Diffserv Discussion List X-BeenThere: diffserv@ietf.org This is a multi-part message in MIME format. ------=_NextPart_000_0018_01BFBFFD.14D46C40 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Hi What is the Object Id of diffserv mib? bye ------=_NextPart_000_0018_01BFBFFD.14D46C40 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
 
 
           =20 Hi
 
           =20 What is the Object Id of diffserv mib?
 
           =20 bye
------=_NextPart_000_0018_01BFBFFD.14D46C40-- _______________________________________________ diffserv mailing list diffserv@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 May 17 09:25:35 2000 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA04773 for ; Wed, 17 May 2000 09:25: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 JAA10568; Wed, 17 May 2000 09:09: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 JAA10537 for ; Wed, 17 May 2000 09:09:39 -0400 (EDT) Received: from hd2.dot.net.in (hd2.vsnl.net.in [202.54.30.2]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA04556 for ; Wed, 17 May 2000 09:09:11 -0400 (EDT) Received: from hyd.chiplogic.com ([203.197.20.108]) by hd2.dot.net.in (8.8.8/8.8.8) with ESMTP id SAA14725 for ; Wed, 17 May 2000 18:37:10 +0530 (IST) Received: from snaidu ([192.168.2.96]) by hyd.chiplogic.com (8.8.7/8.8.7) with SMTP id RAA27626 for ; Wed, 17 May 2000 17:39:06 +0530 From: "snaidu" To: Date: Wed, 17 May 2000 17:52:04 +0530 Message-ID: <01bfbffa$82e2e3e0$6002a8c0@snaidu> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_000B_01BFC028.9C9B1FE0" X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 4.71.1712.3 X-MimeOLE: Produced By Microsoft MimeOLE V4.71.1712.3 Subject: [Diffserv] (no subject) Sender: diffserv-admin@ietf.org Errors-To: diffserv-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Diffserv Discussion List X-BeenThere: diffserv@ietf.org This is a multi-part message in MIME format. ------=_NextPart_000_000B_01BFC028.9C9B1FE0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Hi All the diffserv mib variables comes under ip mib or it = can be seperate mib? bye ------=_NextPart_000_000B_01BFC028.9C9B1FE0 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
 
 
           =20 Hi
 
                All=20 the diffserv mib variables comes under  ip = mib or it can be seperate = mib?
 
           =20 bye
------=_NextPart_000_000B_01BFC028.9C9B1FE0-- _______________________________________________ diffserv mailing list diffserv@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 May 18 10: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 KAA08074 for ; Thu, 18 May 2000 10:47: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 KAA28286; Thu, 18 May 2000 10:10: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 KAA28260 for ; Thu, 18 May 2000 10:10:17 -0400 (EDT) Received: from sol4.rmc.ca (sol4.rmc.ca [137.94.1.134]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA07088 for ; Thu, 18 May 2000 10:10:16 -0400 (EDT) Received: from dullaert1 ([137.94.252.28]) by sol4.rmc.ca (Netscape Messaging Server 4.1) with SMTP id FURE0V00.D4J for ; Thu, 18 May 2000 10:10:07 -0400 Message-Id: <3.0.32.20000518101120.006a0f78@post.rmc.ca> X-Sender: dullaert@post.rmc.ca X-Mailer: Windows Eudora Pro Version 3.0 (32) Date: Thu, 18 May 2000 10:11:23 -0400 To: diffserv@ietf.org From: "John Dullaert" Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Subject: [Diffserv] RFC 2597 Sender: diffserv-admin@ietf.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 am a Masters student commencing a thesis in the end-to-end IP QoS realm, focusing on Diffserv. I am currently in the literature search stage, trying to narrow my focus to a realistic problem definition. The point of this e-mail is that I am looking for clarification to better my understanding of subject RFC, which defines the AF PHB. The recommended codepoints follow the direction laid out in RFC 2474, in that the requirement for improved service for increasing Class Selector Codepoints (bit values of the first three bits) is met. On the other hand, and this is where I am seeking the clarification, it appears that service decreases (more packets are dropped) the higher the bit value for the drop precedence level (last three bits). At first glance, this appears counter-intuitive. At second glance, it makes sense if the definition was done from a perspective of drop probability and matching the higher value to the higher probability, which is unfortunately not consistent with the perspective used for the first three bits. Hence, my need for clarification. Thank you for your time, John C. Dullaert Captain Royal Military College of Canada ECE Grad Student 548-8053 fax 548-8408 _______________________________________________ diffserv mailing list diffserv@ietf.org http://www1.ietf.org/mailman/listinfo/diffserv Archive: http://www-nrg.ee.lbl.gov/diff-serv-arch/ From diffserv-admin@ietf.org Fri May 19 10:25:07 2000 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA05546 for ; Fri, 19 May 2000 10:25:07 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id KAA16212; Fri, 19 May 2000 10:02: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 KAA16181 for ; Fri, 19 May 2000 10:02: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 KAA05292 for ; Fri, 19 May 2000 10:02:40 -0400 (EDT) Received: from sp3at21.hursley.ibm.com (sp3at21.hursley.ibm.com [9.20.45.21]) by mail-gw.hursley.ibm.com (AIX4.3/UCB 8.8.8/8.8.8) with ESMTP id PAA45496; Fri, 19 May 2000 15:02:09 +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 PAA21526; Fri, 19 May 2000 15:02:08 +0100 (BST) Message-ID: <39254932.9D867605@hursley.ibm.com> Date: Fri, 19 May 2000 09:01: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: John Dullaert CC: diffserv@ietf.org Subject: Re: [Diffserv] RFC 2597 References: <3.0.32.20000518101120.006a0f78@post.rmc.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 John, First of all, the four AF PHBs are identically defined - they are not, repeat not, in any type of priority order. This is different from the class selectors, which are tightly defined to be backwards compatible with IP Precedence. Second, you are correct that the three code points for each AF PHB happen to be defined such that a numerically larger value in three particular bits corresponds to a higher probability of the packet being dropped. However, this an arbitrary choice with no particular significance. The point is that *all* the recommended diffserv code points are just arbitrary bit patterns; we could have chosen them at random except for the desire to be backwards compatible with IP Precedence. Also as described in RFC 2474, implementations must allow for an arbitrary mapping of any code point to any PHB; the standard code points are only recommendations. Brian Carpenter John Dullaert wrote: > > Hello, I am a Masters student commencing a thesis in the end-to-end IP QoS > realm, focusing on Diffserv. I am currently in the literature search > stage, trying to narrow my focus to a realistic problem definition. > > The point of this e-mail is that I am looking for clarification to better > my understanding of subject RFC, which defines the AF PHB. The recommended > codepoints follow the direction laid out in RFC 2474, in that the > requirement for improved service for increasing Class Selector Codepoints > (bit values of the first three bits) is met. On the other hand, and this > is where I am seeking the clarification, it appears that service decreases > (more packets are dropped) the higher the bit value for the drop precedence > level (last three bits). At first glance, this appears counter-intuitive. > At second glance, it makes sense if the definition was done from a > perspective of drop probability and matching the higher value to the higher > probability, which is unfortunately not consistent with the perspective > used for the first three bits. Hence, my need for clarification. > > Thank you for your time, > > John C. Dullaert > Captain > Royal Military College of Canada > ECE Grad Student > 548-8053 > fax 548-8408 > > _______________________________________________ > diffserv mailing list > diffserv@ietf.org > http://www1.ietf.org/mailman/listinfo/diffserv > Archive: http://www-nrg.ee.lbl.gov/diff-serv-arch/ _______________________________________________ diffserv mailing list diffserv@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 May 19 19:02: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 TAA11756 for ; Fri, 19 May 2000 19:02: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 SAA20832; Fri, 19 May 2000 18:39: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 SAA20803 for ; Fri, 19 May 2000 18:39:02 -0400 (EDT) Received: from sol.extremenetworks.com (sol.extremenetworks.com [216.52.8.2]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA11561 for ; Fri, 19 May 2000 18:39:00 -0400 (EDT) Received: by SOL with Internet Mail Service (5.5.2650.21) id ; Fri, 19 May 2000 15:35:35 -0700 Message-ID: <808F64DDB492D3119D3C00508B5D8D733EC8CD@SOL> From: Andrew Smith To: "Diffserv (E-mail)" Date: Fri, 19 May 2000 15:35:30 -0700 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: text/plain; charset="iso-8859-1" Subject: [Diffserv] Diffserv conceptual model - updated 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 just submitted an update of this draft - please watch out for draft-ietf-diffserv-model-03.txt coming soon to a draft-repository near you. Thanks, Andrew **************************************************************** Andrew Smith tel: +1 (408) 579-2821 Extreme Networks fax: +1 (408) 579-3000 3585 Monroe St. http://www.extremenetworks.com Santa Clara CA 95051-1450 em: andrew@extremenetworks.com **************************************************************** _______________________________________________ diffserv mailing list diffserv@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 May 19 19:04:23 2000 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA11772 for ; Fri, 19 May 2000 19:04:23 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id SAA20908; Fri, 19 May 2000 18:42: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 SAA20879 for ; Fri, 19 May 2000 18:42:04 -0400 (EDT) Received: from sol.extremenetworks.com (sol.extremenetworks.com [216.52.8.2]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA11581 for ; Fri, 19 May 2000 18:42:01 -0400 (EDT) Received: by SOL with Internet Mail Service (5.5.2650.21) id ; Fri, 19 May 2000 15:38:36 -0700 Message-ID: <808F64DDB492D3119D3C00508B5D8D733EC8CE@SOL> From: Andrew Smith To: "Diffserv (E-mail)" Date: Fri, 19 May 2000 15:38:33 -0700 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: text/plain; charset="iso-8859-1" Subject: [Diffserv] Diffserv MIB - updated draft and open issues Sender: diffserv-admin@ietf.org Errors-To: diffserv-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Diffserv Discussion List X-BeenThere: diffserv@ietf.org Somewhat later than was promised in Adelaide, I have just submitted an update of the MIB draft - please watch out for draft-ietf-diffserv-mib-03.txt coming soon to a draft-repository near you. Here's a head-start on the open issues list from that draft (there's a list of the now-closed issues in the draft itself) - these all need to be resolved by the WG as soon as possible. You'll note that I've assumed solutions to most of these and so your silence will be taken to indicate assent on these proposals. Issue 22 is especially important. Please comment on these issues with messages that indicate which issue you're addressing in the subject line. Thanks, Andrew ============================================ 3.2. Still Open Issues (16) How should the creation of counter actions be under the control of manager or agent: should a diffServActionEntry and diffServCountActEntry appear by magic (the device surely knows what counters it can and cannot maintain on a given interface)? (assume no) If not, should diffServCountActEntry appear magically when a diffServAction element is created which points at the diffServCountActTable (then would be no need for diffServCountActStatus)? (assume no) (18) Should manager be allowed to create Queue elements or should agent be in control of this? (the former) (19) Should manager be allowed to create Scheduler elements or should agent be in control of this? (the former) (20) Related to (17) above, do we also need a "level" index for elements other than classifiers? (no) (21) Do we need diffServAlgDropType of both "headDrop" and "tailDrop" or should we just represent the tail dropper by placing a dropper after the queue instead of before the queue, as linked by the diffServQNext and diffServAlgDropNext RowPointers? (the former). (22) Do we need to support RED algorithms for algorithm parameter configuration and monitoring? If so, what variables are needed? _______________________________________________ diffserv mailing list diffserv@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 May 22 10:14: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 KAA02872 for ; Mon, 22 May 2000 10:14: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 JAA02350; Mon, 22 May 2000 09: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 JAA02322 for ; Mon, 22 May 2000 09:22:46 -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 JAA01804 for ; Mon, 22 May 2000 09:22:44 -0400 (EDT) Received: from sp3at21.hursley.ibm.com (sp3at21.hursley.ibm.com [9.20.45.21]) by mail-gw.hursley.ibm.com (AIX4.3/UCB 8.8.8/8.8.8) with ESMTP id OAA36642; Mon, 22 May 2000 14:22:04 +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 OAA25154; Mon, 22 May 2000 14:21:57 +0100 (BST) Message-ID: <3929345F.FAFC38AC@hursley.ibm.com> Date: Mon, 22 May 2000 08:21:35 -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: Andrew Smith , Kathleen Nichols Subject: Re: [Diffserv] Diffserv MIB - updated draft and open issues References: <808F64DDB492D3119D3C00508B5D8D733EC8CE@SOL> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: diffserv-admin@ietf.org Errors-To: diffserv-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Diffserv Discussion List X-BeenThere: diffserv@ietf.org Content-Transfer-Encoding: 7bit First, I want to thank Andrew in particular, and the rest of the authors of the model and the MIB, for all the back room work that has led to these drafts. Second, we need to reach closure on them as soon as possible. So I would like to propose that we try to reach consensus on the open issues in the MIB over the next 2 weeks at most, so that we can conduct a WG last call on both documents in early June. Brian Carpenter diffserv co-chair Andrew Smith wrote: > > Somewhat later than was promised in Adelaide, I have just submitted an > update of the MIB draft - please watch out for > draft-ietf-diffserv-mib-03.txt coming soon to a draft-repository near you. > > Here's a head-start on the open issues list from that draft (there's a list > of the now-closed issues in the draft itself) - these all need to be > resolved by the WG as soon as possible. You'll note that I've assumed > solutions to most of these and so your silence will be taken to indicate > assent on these proposals. Issue 22 is especially important. Please comment > on these issues with messages that indicate which issue you're addressing in > the subject line. > > Thanks, > > Andrew > > ============================================ > > 3.2. Still Open Issues > > (16) How should the creation of counter actions be under the control of > manager or agent: should a diffServActionEntry and > diffServCountActEntry appear by magic (the device surely knows what > counters it can and cannot maintain on a given interface)? (assume > no) If not, should diffServCountActEntry appear magically when a > diffServAction element is created which points at the > diffServCountActTable (then would be no need for > diffServCountActStatus)? (assume no) > > (18) Should manager be allowed to create Queue elements or should agent > be in control of this? (the former) > > (19) Should manager be allowed to create Scheduler elements or should > agent be in control of this? (the former) > > (20) Related to (17) above, do we also need a "level" index for elements > other than classifiers? (no) > > (21) Do we need diffServAlgDropType of both "headDrop" and "tailDrop" or > should we just represent the tail dropper by placing a dropper > after the queue instead of before the queue, as linked by the > diffServQNext and diffServAlgDropNext RowPointers? (the former). > > (22) Do we need to support RED algorithms for algorithm parameter > configuration and monitoring? If so, what variables are needed? > > _______________________________________________ > diffserv mailing list > diffserv@ietf.org > http://www1.ietf.org/mailman/listinfo/diffserv > Archive: http://www-nrg.ee.lbl.gov/diff-serv-arch/ -- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - Brian E Carpenter Program Director, Internet Standards & Technology, IBM On assignment for IBM at http://www.iCAIR.org Attend INET 2000: http://www.isoc.org/inet2000 Non-IBM email: brian@icair.org _______________________________________________ diffserv mailing list diffserv@ietf.org http://www1.ietf.org/mailman/listinfo/diffserv Archive: http://www-nrg.ee.lbl.gov/diff-serv-arch/ From diffserv-admin@ietf.org Mon May 22 13:19: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 NAA05806 for ; Mon, 22 May 2000 13:19: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 MAA04678; Mon, 22 May 2000 12:42: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 MAA04651 for ; Mon, 22 May 2000 12:41:52 -0400 (EDT) Received: from angelo.kcl.ac.uk (angelo.kcl.ac.uk [137.73.66.5]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA04839 for ; Mon, 22 May 2000 12:41:49 -0400 (EDT) Received: from somewherekovk4 (EE105.eee.kcl.ac.uk [137.73.11.105]) by angelo.kcl.ac.uk with SMTP id RAA11363 for ; Mon, 22 May 2000 17:41:49 +0100 (BST) Message-ID: <00d801bfc40c$e8f33d90$690b4989@somewherekovk4> From: "Piyush Khengar" To: Date: Mon, 22 May 2000 17:43:51 +0100 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_00D5_01BFC415.4AA248D0" X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.00.2919.6700 X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2919.6700 Subject: [Diffserv] Indian Drought Appeal Sender: diffserv-admin@ietf.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_00D5_01BFC415.4AA248D0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Dear All, "Send H20: Parched earth, sweltering heat, nothing to eat, no water to quench the = thirst, loss of cattle and thus means of income is a typical scene in = the famine stricken areas of Rajasthan and Gujrat. This colourful land = is the next victim of nature's fury after Orissa. Most of the areas in = this region today are absolutely dry where the basic source of = sustenance, water, has become a mere mirage for the millions of faceless = villagers. The sordid tale of these villagers is one of parching human = throats and singeing human souls and psyches. As a result thousands of = people are forced to leave their home in search of a few drops of water = for survival." The above is from www.hssworld.com Just visit the following page: http://www.hssworld.com/peoplenet/working@hss/sendh20.htm and every time = you press the "refresh" button (if you're using Internet Explorer), HSS = World will donate 1 rupee in aid to the drought victims. Every click = counts... Piyush Khengar PS. Please tell your friends. ------=_NextPart_000_00D5_01BFC415.4AA248D0 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
Dear All,

"Send H20:
Parched = earth,=20 sweltering heat, nothing to eat, no water to quench the thirst, loss of = cattle=20 and thus means of income is a typical scene in the famine stricken areas = of=20 Rajasthan and Gujrat. This colourful land is the next victim of nature's = fury=20 after Orissa. Most of the areas in this region today are absolutely dry = where=20 the basic source of sustenance, water, has become a mere mirage for the = millions=20 of faceless villagers. The sordid tale of these villagers is one of = parching=20 human throats and singeing human souls and psyches. As a result = thousands of=20 people are forced to leave their home in search of a few drops of water = for=20 survival."

The above is from www.hssworld.com
Just visit the = following=20 page:
http:/= /www.hssworld.com/peoplenet/working@hss/sendh20.htm=20 and every time you press the "refresh" button (if you're using Internet=20 Explorer), HSS World will donate 1 rupee in aid to the drought victims. = Every=20 click counts...

Piyush Khengar

PS. Please tell your=20 friends.


------=_NextPart_000_00D5_01BFC415.4AA248D0-- _______________________________________________ diffserv mailing list diffserv@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 May 23 07:01:23 2000 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA29841 for ; Tue, 23 May 2000 07:01:23 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id GAA23756; Tue, 23 May 2000 06:34: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 GAA23724 for ; Tue, 23 May 2000 06:34:38 -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 GAA29212; Tue, 23 May 2000 06:34:38 -0400 (EDT) Message-Id: <200005231034.GAA29212@ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce: ; Cc: diffserv@ietf.org From: Internet-Drafts@ietf.org Reply-to: Internet-Drafts@ietf.org Date: Tue, 23 May 2000 06:34:38 -0400 Subject: [Diffserv] I-D ACTION:draft-ietf-diffserv-model-03.txt Sender: diffserv-admin@ietf.org Errors-To: diffserv-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Diffserv Discussion List X-BeenThere: diffserv@ietf.org --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Differentiated Services Working Group of the IETF. Title : A Conceptual Model for Diffserv Routers Author(s) : Y. Bernet, A. Smith, S. Blake, D. Grossman Filename : draft-ietf-diffserv-model-03.txt Pages : 46 Date : 22-May-00 This draft proposes a conceptual model of Differentiated Services (Diffserv) routers for use in their management and configuration. This model defines the general functional datapath elements (classifiers, meters, markers, droppers, monitors, multiplexors, queues), their possible configuration parameters, and how they might be interconnected to realize the range of classification, traffic conditioning, and per- hop behavior (PHB) functionalities described in [DSARCH]. 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. 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]) and more detailed models (e.g. [QOSDEVMOD]): these should all be based upon and consistent with this model. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-diffserv-model-03.txt Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-diffserv-model-03.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-diffserv-model-03.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <20000522111208.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-diffserv-model-03.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-diffserv-model-03.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <20000522111208.I-D@ietf.org> --OtherAccess-- --NextPart-- _______________________________________________ diffserv mailing list diffserv@ietf.org http://www1.ietf.org/mailman/listinfo/diffserv Archive: http://www-nrg.ee.lbl.gov/diff-serv-arch/ From diffserv-admin@ietf.org Tue May 23 07:16: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 HAA00099 for ; Tue, 23 May 2000 07:16: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 GAA23789; Tue, 23 May 2000 06:34: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 GAA23758 for ; Tue, 23 May 2000 06:34:44 -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 GAA29226; Tue, 23 May 2000 06:34:44 -0400 (EDT) Message-Id: <200005231034.GAA29226@ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce: ; Cc: diffserv@ietf.org From: Internet-Drafts@ietf.org Reply-to: Internet-Drafts@ietf.org Date: Tue, 23 May 2000 06:34:44 -0400 Subject: [Diffserv] I-D ACTION:draft-ietf-diffserv-mib-03.txt Sender: diffserv-admin@ietf.org Errors-To: diffserv-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Diffserv Discussion List X-BeenThere: diffserv@ietf.org --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Differentiated Services Working Group of the IETF. Title : Management Information Base for the Differentiated Services Architecture Author(s) : F. Baker, K. Chan, A. Smith Filename : draft-ietf-diffserv-mib-03.txt Pages : 67 Date : 22-May-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-03.txt Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-diffserv-mib-03.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-diffserv-mib-03.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <20000522111231.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-diffserv-mib-03.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-diffserv-mib-03.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <20000522111231.I-D@ietf.org> --OtherAccess-- --NextPart-- _______________________________________________ diffserv mailing list diffserv@ietf.org http://www1.ietf.org/mailman/listinfo/diffserv Archive: http://www-nrg.ee.lbl.gov/diff-serv-arch/ From diffserv-admin@ietf.org Tue May 23 19:05: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 TAA12931 for ; Tue, 23 May 2000 19:05: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 SAA00788; Tue, 23 May 2000 18:32: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 SAA00756 for ; Tue, 23 May 2000 18:31:59 -0400 (EDT) Received: from boreas.isi.edu (boreas.isi.edu [128.9.160.161]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA11867; Tue, 23 May 2000 18:31:58 -0400 (EDT) Received: from ISI.EDU (jet.isi.edu [128.9.160.87]) by boreas.isi.edu (8.8.7/8.8.6) with ESMTP id PAA18749; Tue, 23 May 2000 15:31:59 -0700 (PDT) Message-Id: <200005232231.PAA18749@boreas.isi.edu> To: IETF-Announce: ; Cc: rfc-ed@ISI.EDU, diffserv@ietf.org Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary=NextPart Date: Tue, 23 May 2000 15:31:58 -0700 From: RFC Editor Subject: [Diffserv] RFC 2836 on Per Hop Behavior Identification Codes Sender: diffserv-admin@ietf.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 Request for Comments is now available in online RFC libraries. RFC 2836 Title: Per Hop Behavior Identification Codes Author(s): S. Brim, B. Carpenter, F. Le Faucheur Status: Standards Track Date: May 2000 Mailbox: sbrim@cisco.com, brian@icair.org, flefauch@cisco.com Pages: 7 Characters: 13399 Updates/Obsoletes/SeeAlso: None I-D Tag: draft-ietf-diffserv-phbid-00.txt URL: ftp://ftp.isi.edu/in-notes/rfc2836.txt This document defines a binary encoding to uniquely identify PHBs and/or sets of PHBs in protocol messages. This encoding MUST be used when such identification is required. This document is a product of the Differentiated Services Working Group of the IETF. 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. This announcement is sent to the IETF list and the RFC-DIST list. Requests to be added to or deleted from the IETF distribution list should be sent to IETF-REQUEST@IETF.ORG. Requests to be added to or deleted from the RFC-DIST distribution list should be sent to RFC-DIST-REQUEST@RFC-EDITOR.ORG. Details on obtaining RFCs via FTP or EMAIL may be obtained by sending an EMAIL message to rfc-info@RFC-EDITOR.ORG with the message body help: ways_to_get_rfcs. For example: To: rfc-info@RFC-EDITOR.ORG Subject: getting rfcs help: ways_to_get_rfcs Requests for special distribution should be addressed to either the author of the RFC in question, or to RFC-Manager@RFC-EDITOR.ORG. Unless specifically noted otherwise on the RFC itself, all RFCs are for unlimited distribution.echo Submissions for Requests for Comments should be sent to RFC-EDITOR@RFC-EDITOR.ORG. Please consult RFC 2223, Instructions to RFC Authors, for further information. Joyce K. Reynolds and Sandy Ginoza USC/Information Sciences Institute ... Below is the data which will enable a MIME compliant Mail Reader implementation to automatically retrieve the ASCII version of the RFCs. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="RFC-INFO@RFC-EDITOR.ORG" Content-Type: text/plain Content-ID: <000523152926.RFC@RFC-EDITOR.ORG> RETRIEVE: rfc DOC-ID: rfc2836 --OtherAccess Content-Type: Message/External-body; name="rfc2836.txt"; site="ftp.isi.edu"; access-type="anon-ftp"; directory="in-notes" Content-Type: text/plain Content-ID: <000523152926.RFC@RFC-EDITOR.ORG> --OtherAccess-- --NextPart-- _______________________________________________ diffserv mailing list diffserv@ietf.org http://www1.ietf.org/mailman/listinfo/diffserv Archive: http://www-nrg.ee.lbl.gov/diff-serv-arch/ From diffserv-admin@ietf.org Wed May 24 18:52: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 SAA13821 for ; Wed, 24 May 2000 18:52: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 SAA18657; Wed, 24 May 2000 18:16: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 SAA18624 for ; Wed, 24 May 2000 18:16:10 -0400 (EDT) Received: from stl-smtpout-01.boeing.com (stl-smtpout-01.boeing.com [12.13.247.21]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA13534 for ; Wed, 24 May 2000 18:16:08 -0400 (EDT) Received: from stl-av-01.boeing.com ([192.76.190.6]) by stl-smtpout-01.boeing.com (8.9.2/8.8.5-M2) with ESMTP id RAA28170 for ; Wed, 24 May 2000 17:16:10 -0500 (CDT) Received: from stl-hub-01.boeing.com (localhost [127.0.0.1]) by stl-av-01.boeing.com (8.9.2/8.9.2) with ESMTP id RAA15857 for ; Wed, 24 May 2000 17:16:08 -0500 (CDT) Received: from xch-phlbh-01.he.boeing.com by stl-hub-01.boeing.com with ESMTP for diffserv@ietf.org; Wed, 24 May 2000 17:15:59 -0500 Received: by xch-phlbh-01.he.boeing.com with Internet Mail Service (5.5.2650.21) id ; Wed, 24 May 2000 18:15:59 -0400 Message-Id: <4102273CEB77D211869200805FE6F5939EBBC5@xch-phl-01.he.boeing.com> From: "Manfredi, Albert E" To: "'diffserv@ietf.org'" Date: Wed, 24 May 2000 18:15:52 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: text/plain; charset="iso-8859-1" Subject: [Diffserv] RFC 2836, PHB ID Codes Sender: diffserv-admin@ietf.org Errors-To: diffserv-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Diffserv Discussion List X-BeenThere: diffserv@ietf.org A couple of comments on the subject RFC, sent out yesterday: 1. I guess the obsoleted term "BA" is still here. 2. It's not clear to me how this PHB ID might be tabulated to a DSCP for a given domain. My expectation would be something that isn't discussed. That is, I would have expected a diffserv user to query the ingress of a new diffserv domain with a PHB ID, and the ingress node to respond with the DSCP that meets this behavior in this particular domain. This "user" could be, for instance, the egress node of another diffserv domain. Is this implicit in what RFC 2836 states? I guess I was expecting to see a 16-bit field defining a PHB ID and then a 16-bit field providing the recommended DSCP (which might be what's shown as Case 1)? 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 May 24 20:31: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 UAA14707 for ; Wed, 24 May 2000 20:31: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 UAA19617; Wed, 24 May 2000 20:04: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 UAA19585 for ; Wed, 24 May 2000 20:04:50 -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 UAA14449 for ; Wed, 24 May 2000 20:04:48 -0400 (EDT) Received: from jschnizl1-pc (dhcp-sjc9-171-70-52-56.cisco.com [171.70.52.56]) by diablo.cisco.com (8.8.6 (PHNE_14041)/CISCO.SERVER.1.2) with SMTP id RAA00782 for ; Wed, 24 May 2000 17:04:12 -0700 (PDT) Message-Id: <4.1.20000524184818.009cf5f0@diablo.cisco.com> X-Sender: jschnizl@diablo.cisco.com X-Mailer: QUALCOMM Windows Eudora Pro Version 4.1 Date: Wed, 24 May 2000 20:03:32 -0400 To: Diff Serv From: John Schnizlein In-Reply-To: <3929345F.FAFC38AC@hursley.ibm.com> References: <808F64DDB492D3119D3C00508B5D8D733EC8CE@SOL> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Subject: [Diffserv] diffserv-model-03 Sender: diffserv-admin@ietf.org Errors-To: diffserv-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Diffserv Discussion List X-BeenThere: diffserv@ietf.org Is the type of Masked-DSCP consistent with the prohibition against treating DSCP values as structured rather than as arbitrary values? Section 4.1.2 of the model seems to encourage something other than MUST match against the entire 6-bit field requirement in RFC 2474. excerpts from both documents follow: diffserv-model-03: 4.1.2. Overlapping Filters Note that it is easy to define sets of overlapping filters in a classifier. For example: Filter5: Type: Masked-DSCP Value: 111000 Mask: 111000 RFC 2474 Differentiated Services Field: Implementors should note that the DSCP field is six bits wide. DS- compliant nodes MUST select PHBs by matching against the entire 6-bit DSCP field, e.g., by treating the value of the field as a table index which is used to select a particular packet handling mechanism which has been implemented in that device. The value of the CU field MUST be ignored by PHB selection. The DSCP field is defined as an unstructured field to facilitate the definition of future per-hop behaviors. _______________________________________________ diffserv mailing list diffserv@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 May 25 03:10: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 DAA01560 for ; Thu, 25 May 2000 03:10: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 CAA27734; Thu, 25 May 2000 02:23: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 CAA27704 for ; Thu, 25 May 2000 02:23:33 -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 CAA01237 for ; Thu, 25 May 2000 02:23:32 -0400 (EDT) Received: from wooly-booly.cisco.com (wooly-booly.cisco.com [171.69.167.33]) by sj-msg-core-1.cisco.com (8.9.3/8.9.1) with ESMTP id XAA21802 for ; Wed, 24 May 2000 23:23:10 -0700 (PDT) Received: from p7020-img-nt.cisco.com (fred-hm-dhcp1.cisco.com [171.69.128.116]) by wooly-booly.cisco.com (8.8.8-Cisco List Logging/CISCO.WS.1.2) with ESMTP id BAA01079; Thu, 25 May 2000 01:23:01 -0500 (CDT) Message-Id: <4.3.1.2.20000524194255.00af2f00@flipper.cisco.com> X-Sender: fred@flipper.cisco.com X-Mailer: QUALCOMM Windows Eudora Version 4.3.1 Date: Wed, 24 May 2000 23:00:54 -0700 To: "Diffserv (E-mail)" From: Fred Baker Subject: Re: [Diffserv] Diffserv MIB - droppers Cc: "Diffserv (E-mail)" In-Reply-To: <808F64DDB492D3119D3C00508B5D8D733EC8CE@SOL> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: diffserv-admin@ietf.org Errors-To: diffserv-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Diffserv Discussion List X-BeenThere: diffserv@ietf.org At 03:38 PM 5/19/00 -0700, Andrew Smith wrote: >(21) Do we need diffServAlgDropType of both "headDrop" and "tailDrop" or > should we just represent the tail dropper by placing a dropper > after the queue instead of before the queue, as linked by the > diffServQNext and diffServAlgDropNext RowPointers? (the former). > >(22) Do we need to support RED algorithms for algorithm parameter > configuration and monitoring? If so, what variables are needed? My humble opinion on these: On kinds of droppers: I see great utility in describing a tail dropper, as there are a great number of implementations that use tail drop. I see great utility in describing a rudimentary RED dropper, as the IETF recommends the deployment of RED to improve handling of TCP traffic, and because we have an instance of a PHB that uses that kind of dropper. More in a moment. I see very limited utility in describing a head dropper, as I am not aware of a commercially deployed head dropper. I have seen some research concerning the things in a French paper, which suggests that it may be useful on extremely asymmetric links (ADSL), but I have no customers asking me for one and I don't know of a commercial implementation regardless of vendor. Obviously, I'm willing to be corrected there. On random droppers: The authors had a rollicking discussion of random droppers. It is fair to say that one of us can live without them, one of us wants a random dropper with a number of parameters, and one of us (me) thinks that a simple start is best. The working group has discussed other dropper implementations than RED, which have various characteristics. The simplest random drop algorithm I am aware of is RED Light, which Kathy posted a note to the working group about some time ago, and is documented in ftp://ftp-eng.cisco.com/ftp/kmn-group/docs/red_light.9.30.pdf; I have to say that in my experimentation it seems to be quite effective. My druthers tend towards describing the simplest thing in the public MIB and adding additional knobs as needed in each vendor's private MIB until it becomes apparent that there is sufficient commonality in vendor MIBs to justify standardizing a variable. It seems to me that the simplest implementation we can have that is a subset of each of the implementations I am aware of consists of three objects, which have been described in these words: At 03:39 PM 3/22/00 -0800, Kathleen Nichols wrote: >Okay, then I'd say that the parameters that REDlight has in common >with 93RED are: > > a threshold for the filtered or averaged queue size below which no > packet dropping takes place (in 93RED, min_thresh) > > a parameter for that filter or average (a filter gain or a "queue > weight") that controls the history of the filtering or averaging > > an upper bound to the "controlled range", that is a value of the > filtered or averaged queue above which 100% of packets are dropped Some quick observations: The min-threshold could be characterized as the target mean queue depth. My observations of RED in deployment tests is that the effect of the algorithm is to make the mean queue depth hover close to that value. If we describe it in those terms, it probably generalizes a little better to the algorithms that Walter has described. The max-threshold, the so-called "upper bound", is something that Van has argued and I think I have heard Kathy agree is non-essential. It may be that we could agree to drop it as a control. I would additionally suggest a counter for the packets dropped as a result of the filter (so we know what it is doing), and that these be indexed per interface per action using the queue, which is roughly equivalent to being per interface per queue per DSCP (which the model might more suggest). I was surprised that we the authors could not come to a consensus similar to this among ourselves, and I hope that the working group will do so. It seems to me a bit daft for us to define a public MIB which doesn't adequately describe the PHBs that we have defined for general deployment. _______________________________________________ diffserv mailing list diffserv@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 May 25 09:38: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 JAA07973 for ; Thu, 25 May 2000 09:38: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 IAA01317; Thu, 25 May 2000 08:51: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 IAA01288 for ; Thu, 25 May 2000 08:51:45 -0400 (EDT) Received: from procyon.pmc-sierra.bc.ca (procyon.pmc-sierra.bc.ca [134.87.115.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA02456 for ; Thu, 25 May 2000 08:51:45 -0400 (EDT) Received: from nt-exchange1.pmc-sierra.bc.ca (nt-exchange1.pmc-sierra.bc.ca [134.87.116.183]) by procyon.pmc-sierra.bc.ca (6.6.6/6.6.6) with ESMTP id FAA25284; Thu, 25 May 2000 05:50:40 -0700 (PDT) Received: by nt-exchange1.pmc-sierra.bc.ca with Internet Mail Service (5.5.2650.21) id ; Thu, 25 May 2000 05:50:40 -0700 Message-ID: <336ECDAFDF7DD311B9E30090277AEE4101B4058C@nt-exchange-bby.pmc-sierra.bc.ca> From: Shahram Davari To: "'Manfredi, Albert E'" , "'diffserv@ietf.org'" Subject: RE: [Diffserv] RFC 2836, PHB ID Codes Date: Thu, 25 May 2000 05:47:50 -0700 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: text/plain; charset="iso-8859-1" Sender: diffserv-admin@ietf.org Errors-To: diffserv-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Diffserv Discussion List X-BeenThere: diffserv@ietf.org Hi Albert, >-----Original Message----- >From: Manfredi, Albert E [mailto:Albert.Manfredi@PHL.Boeing.com] >Sent: Wednesday, May 24, 2000 6:16 PM >To: 'diffserv@ietf.org' >Subject: [Diffserv] RFC 2836, PHB ID Codes > > >A couple of comments on the subject RFC, sent out yesterday: > >1. I guess the obsoleted term "BA" is still here. BA is not obsolete. The new definition of BA is obsolete. > >2. It's not clear to me how this PHB ID might be tabulated to >a DSCP for a >given domain. My expectation would be something that isn't >discussed. That >is, I would have expected a diffserv user to query the ingress of a new >diffserv domain with a PHB ID, and the ingress node to respond >with the DSCP >that meets this behavior in this particular domain. This >"user" could be, >for instance, the egress node of another diffserv domain. > >Is this implicit in what RFC 2836 states? I guess I was >expecting to see a >16-bit field defining a PHB ID and then a 16-bit field providing the >recommended DSCP (which might be what's shown as Case 1)? > A DCLASS object is designed specifically for the purpose of signaling the DSCP: http://www.ietf.org/internet-drafts/draft-ietf-issll-dclass-01.txt Regards, -Shahram >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 Thu May 25 11:42: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 LAA11675 for ; Thu, 25 May 2000 11:42: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 KAA02747; Thu, 25 May 2000 10:57: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 KAA02716 for ; Thu, 25 May 2000 10:57: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 KAA10461 for ; Thu, 25 May 2000 10:57:39 -0400 (EDT) Received: [from pobox2.mot.com (pobox2.mot.com [136.182.15.8]) by ftpbox.mot.com (ftpbox 2.1) with ESMTP id HAA19513; Thu, 25 May 2000 07:57:32 -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 HAA22210; Thu, 25 May 2000 07:57:32 -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 KAA14327; Thu, 25 May 2000 10:57:31 -0400 (EDT) Message-Id: <200005251457.KAA14327@noah.dma.isg.mot.com> X-Mailer: exmh version 1.6.7 5/3/96 To: Fred Baker cc: "Diffserv (E-mail)" Subject: Re: [Diffserv] Diffserv MIB - droppers In-reply-to: Your message of "Wed, 24 May 2000 23:00:54 EDT." <4.3.1.2.20000524194255.00af2f00@flipper.cisco.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Thu, 25 May 2000 10:57:30 -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 > At 03:38 PM 5/19/00 -0700, Andrew Smith wrote: > >(21) Do we need diffServAlgDropType of both "headDrop" and "tailDrop" or > > should we just represent the tail dropper by placing a dropper > > after the queue instead of before the queue, as linked by the > > diffServQNext and diffServAlgDropNext RowPointers? (the former). > > > >(22) Do we need to support RED algorithms for algorithm parameter > > configuration and monitoring? If so, what variables are needed? > > My humble opinion on these: > > On kinds of droppers: > > I see great utility in describing a tail dropper, as there are a great > number of implementations that use tail drop. The way the model works, a tail dropper is an algorithmic dropper which is placed before the FIFO in the data flow and for which the algorithm is: get_next_packet; if (qdepth >= threshold) then return_packet_to_free_buffer_pool; else enqueue (packet, FIFO); > > I see great utility in describing a rudimentary RED dropper, as the IETF > recommends the deployment of RED to improve handling of TCP traffic, and > because we have an instance of a PHB that uses that kind of dropper. More in > a moment. > > I see very limited utility in describing a head dropper, as I am not aware > of a commercially deployed head dropper. I have seen some research > concerning the things in a French paper, which suggests that it may be > useful on extremely asymmetric links (ADSL), but I have no customers asking > me for one and I don't know of a commercial implementation regardless of > vendor. Obviously, I'm willing to be corrected there. There are advantages to head droppers, especially for real-time flows. There have been some very good papers which used a wine/milk metaphor, and a personal butler maintaining newspaper clippings for a travelling boss metaphor to illustrate why it is better to get rid of stale packets for real time traffic, but also better to advance the TCP window for non-real time traffic. I have also seen suggestions (perhaps what you're referring to) that in the case of highly asymetric links, it's best to get rid of stale TCP ACKs to avoid unnecessarily getting into congestion avoidance due to ACK starvation. I believe this is mentioned in one of the PILC drafts. In any event, a head dropper is an algorithmic dropper which is placed _after_ the FIFO in the data flow and for which the algorithm is: await_FIFO_full_trigger; dequeue (packet, FIFO); return_packet_to_free_buffer_pool; > > On random droppers: > > The authors had a rollicking discussion of random droppers. It is fair to > say that one of us can live without them, one of us wants a random dropper > with a number of parameters, and one of us (me) thinks that a simple start > is best. The working group has discussed other dropper implementations than > RED, which have various characteristics. The simplest random drop algorithm > I am aware of is RED Light, which Kathy posted a note to the working group > about some time ago, and is documented in > ftp://ftp-eng.cisco.com/ftp/kmn-group/docs/red_light.9.30.pdf; I have to say > that in my experimentation it seems to be quite effective. My druthers tend > towards describing the simplest thing in the public MIB and adding > additional knobs as needed in each vendor's private MIB until it becomes > apparent that there is sufficient commonality in vendor MIBs to justify > standardizing a variable. > I think I'm ok with this approach. But how to represent the multiple thresholds implied in AF? 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 Thu May 25 13:59: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 NAA16282 for ; Thu, 25 May 2000 13:59: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 NAA04331; Thu, 25 May 2000 13:27: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 NAA04299 for ; Thu, 25 May 2000 13:27:01 -0400 (EDT) Received: from mail-gw.hursley.ibm.com (mail-gw.hursley.ibm.com [194.196.110.15]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA14868 for ; Thu, 25 May 2000 13:26:54 -0400 (EDT) Received: from sp3at21.hursley.ibm.com (sp3at21.hursley.ibm.com [9.20.45.21]) by mail-gw.hursley.ibm.com (AIX4.3/UCB 8.8.8/8.8.8) with ESMTP id SAA20742; Thu, 25 May 2000 18:26:23 +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 SAA21750; Thu, 25 May 2000 18:26:21 +0100 (BST) Message-ID: <392D6207.B84E10E4@hursley.ibm.com> Date: Thu, 25 May 2000 12:25:27 -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: "Manfredi, Albert E" CC: "'diffserv@ietf.org'" Subject: Re: [Diffserv] RFC 2836, PHB ID Codes References: <4102273CEB77D211869200805FE6F5939EBBC5@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 I believe it uses BA in its original sense which has not been changed. How you use PHBIDs was left for those who choose to use them. BC "Manfredi, Albert E" wrote: > > A couple of comments on the subject RFC, sent out yesterday: > > 1. I guess the obsoleted term "BA" is still here. > > 2. It's not clear to me how this PHB ID might be tabulated to a DSCP for a > given domain. My expectation would be something that isn't discussed. That > is, I would have expected a diffserv user to query the ingress of a new > diffserv domain with a PHB ID, and the ingress node to respond with the DSCP > that meets this behavior in this particular domain. This "user" could be, > for instance, the egress node of another diffserv domain. > > Is this implicit in what RFC 2836 states? I guess I was expecting to see a > 16-bit field defining a PHB ID and then a 16-bit field providing the > recommended DSCP (which might be what's shown as Case 1)? > > 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 Thu May 25 14:33: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 OAA17387 for ; Thu, 25 May 2000 14:33: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 OAA05010; Thu, 25 May 2000 14: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 OAA04981 for ; Thu, 25 May 2000 14:07:02 -0400 (EDT) Received: from mc-qout4.whowhere.com (mc-qout4.whowhere.com [209.185.123.18]) by ietf.org (8.9.1a/8.9.1a) with SMTP id OAA16538 for ; Thu, 25 May 2000 14:06:59 -0400 (EDT) Received: from Unknown/Local ([?.?.?.?]) by angelfire.com; Thu May 25 11:06:11 2000 To: diffserv@ietf.org Date: Thu, 25 May 2000 11:06:11 -0700 From: "Xavier Lopez-Murtra" Message-ID: Mime-Version: 1.0 X-Sent-Mail: off Reply-To: xavi@angelfire.com X-Mailer: MailCity Service X-Sender-Ip: 195.77.69.22 Organization: Angelfire (http://email.angelfire.mailcity.lycos.com:80) Content-Type: text/plain; charset=us-ascii Content-Language: en Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Subject: [Diffserv] (No Subject) Sender: diffserv-admin@ietf.org Errors-To: diffserv-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Diffserv Discussion List X-BeenThere: diffserv@ietf.org Content-Transfer-Encoding: 7bit I would like to know in which drafts or RFC's can I find information about the utilization of COPS protocol in DS domains. Thank you very much. Angelfire for your free web-based e-mail. http://www.angelfire.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 May 25 15:30: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 PAA18638 for ; Thu, 25 May 2000 15:30:55 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id PAA05692; Thu, 25 May 2000 15:00: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 PAA05633 for ; Thu, 25 May 2000 15:00: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 PAA17938 for ; Thu, 25 May 2000 15:00: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 TAA85978; Thu, 25 May 2000 19:59: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 TAA18344; Thu, 25 May 2000 19:59:11 +0100 (BST) Message-ID: <392D77DB.26C7E0E7@hursley.ibm.com> Date: Thu, 25 May 2000 13:58:35 -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: xavi@angelfire.com CC: diffserv@ietf.org Subject: Re: [Diffserv] (No Subject) 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 draft-ietf-diffserv-pib-00.txt is the only related document in diffserv. draft-ietf-rap-cops-ds is also relevant (not sure of the latest version number). Brian Xavier Lopez-Murtra wrote: > > I would like to know in which drafts or RFC's > can I find information about the utilization > of COPS protocol in DS domains. Thank you very > much. > > Angelfire for your free web-based e-mail. http://www.angelfire.com > > _______________________________________________ > diffserv mailing list > diffserv@ietf.org > http://www1.ietf.org/mailman/listinfo/diffserv > Archive: http://www-nrg.ee.lbl.gov/diff-serv-arch/ _______________________________________________ diffserv mailing list diffserv@ietf.org http://www1.ietf.org/mailman/listinfo/diffserv Archive: http://www-nrg.ee.lbl.gov/diff-serv-arch/ From diffserv-admin@ietf.org Thu May 25 15:57:50 2000 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA19297 for ; Thu, 25 May 2000 15:57:50 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id PAA06219; Thu, 25 May 2000 15:39: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 PAA06181 for ; Thu, 25 May 2000 15:38: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 PAA18906 for ; Thu, 25 May 2000 15:38:58 -0400 (EDT) Received: from wooly-booly.cisco.com (wooly-booly.cisco.com [171.69.167.33]) by sj-msg-core-1.cisco.com (8.9.3/8.9.1) with ESMTP id MAA24965; Thu, 25 May 2000 12:38:31 -0700 (PDT) Received: from p7020-img-nt.cisco.com (fred-hm-dhcp1.cisco.com [171.69.128.116]) by wooly-booly.cisco.com (8.8.8-Cisco List Logging/CISCO.WS.1.2) with ESMTP id OAA02200; Thu, 25 May 2000 14:38:21 -0500 (CDT) Message-Id: <4.3.2.7.2.20000525123338.028e2b90@flipper.cisco.com> X-Sender: fred@flipper.cisco.com X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Thu, 25 May 2000 12:35:28 -0700 To: Dan Grossman From: Fred Baker Subject: Re: [Diffserv] Diffserv MIB - droppers Cc: "Diffserv (E-mail)" In-Reply-To: <200005251457.KAA14327@noah.dma.isg.mot.com> References: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: diffserv-admin@ietf.org Errors-To: diffserv-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Diffserv Discussion List X-BeenThere: diffserv@ietf.org At 10:57 AM 5/25/00 -0400, Dan Grossman wrote: >In any event, a head dropper is an algorithmic dropper which is placed >_after_ >the FIFO in the data flow and for which the algorithm is: > await_FIFO_full_trigger; > dequeue (packet, FIFO); > return_packet_to_free_buffer_pool; I know *what* a head dropper is. I'm saying I don't know of anyone who is asking for that in deployed product, and therefore needs one *managed*. Again, willing to be convinced/corrected, but if our MIB supports features that are bright gleams in some random researchers eye and doesn't support deployed and recommended product, we are doing something that is blatantly stupid. _______________________________________________ diffserv mailing list diffserv@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 May 25 16:01: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 QAA19405 for ; Thu, 25 May 2000 16:01: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 PAA06241; Thu, 25 May 2000 15:39: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 PAA06186 for ; Thu, 25 May 2000 15:38: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 PAA18908 for ; Thu, 25 May 2000 15:38:58 -0400 (EDT) Received: from wooly-booly.cisco.com (wooly-booly.cisco.com [171.69.167.33]) by sj-msg-core-1.cisco.com (8.9.3/8.9.1) with ESMTP id MAA24973; Thu, 25 May 2000 12:38:32 -0700 (PDT) Received: from p7020-img-nt.cisco.com (fred-hm-dhcp1.cisco.com [171.69.128.116]) by wooly-booly.cisco.com (8.8.8-Cisco List Logging/CISCO.WS.1.2) with ESMTP id OAA02203; Thu, 25 May 2000 14:38:23 -0500 (CDT) Message-Id: <4.3.2.7.2.20000525123541.027d9c60@flipper.cisco.com> X-Sender: fred@flipper.cisco.com X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Thu, 25 May 2000 12:38:14 -0700 To: Dan Grossman From: Fred Baker Subject: Re: [Diffserv] Diffserv MIB - droppers Cc: "Diffserv (E-mail)" In-Reply-To: <200005251457.KAA14327@noah.dma.isg.mot.com> References: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: diffserv-admin@ietf.org Errors-To: diffserv-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Diffserv Discussion List X-BeenThere: diffserv@ietf.org At 10:57 AM 5/25/00 -0400, Dan Grossman wrote: > > The authors had a rollicking discussion of random droppers. It is fair to > > say that one of us can live without them, one of us wants a random dropper > > with a number of parameters, and one of us (me) thinks that a simple start > > is best. The working group has discussed other dropper implementations than > > RED, which have various characteristics. The simplest random drop algorithm > > I am aware of is RED Light, which Kathy posted a note to the working group > > about some time ago, and is documented in > > ftp://ftp-eng.cisco.com/ftp/kmn-group/docs/red_light.9.30.pdf; I have > to say > > that in my experimentation it seems to be quite effective. My druthers tend > > towards describing the simplest thing in the public MIB and adding > > additional knobs as needed in each vendor's private MIB until it becomes > > apparent that there is sufficient commonality in vendor MIBs to justify > > standardizing a variable. > > >I think I'm ok with this approach. But how to represent the multiple >thresholds implied in AF? simple. They have different target queue depths, indexed by which action the traffic gets applied to it. We first try to control to AFx3's queue depth by dropping AFx3 traffic; if that doesn't work out, the drop rate for that approaches 100% because the queue depth is increasing, and we start trying to control to AFx2's target depth by dropping AFx2 traffic. If that doesn't work, we start trying to control to AFx1's depth by dropping AFx1 traffic. _______________________________________________ diffserv mailing list diffserv@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 May 25 17:13: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 RAA20809 for ; Thu, 25 May 2000 17:13: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 QAA07126; Thu, 25 May 2000 16:45: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 QAA07095 for ; Thu, 25 May 2000 16:45:39 -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 QAA20469 for ; Thu, 25 May 2000 16:45:38 -0400 (EDT) Received: [from mothost.mot.com (mothost.mot.com [129.188.137.101]) by ftpbox.mot.com (ftpbox 2.1) with ESMTP id NAA23423; Thu, 25 May 2000 13:45:35 -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 NAA22372; Thu, 25 May 2000 13:45:34 -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 QAA26592; Thu, 25 May 2000 16:45:33 -0400 (EDT) Message-Id: <200005252045.QAA26592@noah.dma.isg.mot.com> X-Mailer: exmh version 1.6.7 5/3/96 To: Fred Baker cc: "Diffserv (E-mail)" Subject: Re: [Diffserv] Diffserv MIB - droppers In-reply-to: Your message of "Thu, 25 May 2000 12:35:28 EDT." <4.3.2.7.2.20000525123338.028e2b90@flipper.cisco.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Thu, 25 May 2000 16:45:33 -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 > At 10:57 AM 5/25/00 -0400, Dan Grossman wrote: > >In any event, a head dropper is an algorithmic dropper which is placed > >_after_ > >the FIFO in the data flow and for which the algorithm is: > > await_FIFO_full_trigger; > > dequeue (packet, FIFO); > > return_packet_to_free_buffer_pool; > > I know *what* a head dropper is. I'm saying I don't know of anyone who is > asking for that in deployed product, and therefore needs one *managed*. I have heard tell of such a thing in one implementation (but would rather its implementor speak for themselves). I also cannot speak to implementations that I might involved in. However, speaking for myself, I think that head dropping is a good thing for some scenarios, albeit a bit more difficult to implement. > Again, willing to be convinced/corrected, but if our MIB supports features > that are bright gleams in some random researchers eye and doesn't support > deployed and recommended product, we are doing something that is blatantly > stupid. I think we can agree to disagree *respectfully*. 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 Thu May 25 22:30: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 WAA25803 for ; Thu, 25 May 2000 22:30: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 VAA09798; Thu, 25 May 2000 21:53: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 VAA09767 for ; Thu, 25 May 2000 21:53:14 -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 VAA25312 for ; Thu, 25 May 2000 21:53:14 -0400 (EDT) Message-Id: <200005260153.VAA25312@ietf.org> Received: from zcard00n.ca.nortel.com (actually zcard00n) by ertpg14e1.nortelnetworks.com; Thu, 25 May 2000 21:51:57 -0400 Received: from zcard00f.ca.nortel.com ([47.129.30.8]) by zcard00n.ca.nortel.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2650.21) id L40WXG95; Thu, 25 May 2000 21:51:57 -0400 Received: from zcarh014 (zcarh014.ca.nortel.com [47.23.81.6]) by zcard00f.ca.nortel.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2650.21) id LAJBPZZZ; Thu, 25 May 2000 21:51:55 -0400 Date: Thu, 25 May 2000 21:51:48 -0400 (EDT) X-Sybari-Space: 00000000 00000000 00000000 From: "Nabil Seddigh" Reply-To: "Nabil Seddigh" Subject: Re: [Diffserv] Diffserv MIB - droppers To: Fred Baker cc: "Diffserv (E-mail)" X-Mailer: Rosa 3.0 X-Rosa-Trace: nseddigh@zcarh014 <47.23.81.6> MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-ID: Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by optimus.ietf.org id VAA09768 Sender: diffserv-admin@ietf.org Errors-To: 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 have 3 main thoughts (see square brackets) in response to Andrew's request for comments on the need for RED parameters in the MIB. My comments are interspersed with what Fred wrote below: > >I see great utility in describing a rudimentary RED dropper, >as the IETF recommends the deployment of RED to improve > handling of TCP traffic, and because we have an instance >of a PHB that uses that kind of dropper. More in >a moment. > I tend to agree with this. Given that the AF PHB requires AQM and given that we have an IETF RFC recommending RED for wide-spread deployment, I would think that the DS MIB should contain the necessary parameters to support RED and MRED (Multi-Level RED) - see below. >Some quick observations: > >The min-threshold could be characterized as the target >mean queue depth. My observations of RED in deployment >tests is that the effect of the algorithm is to make the mean >queue depth hover close to that value. If we describe it >in those terms, it probably generalizes a little better to the >algorithms that Walter has described. > >The max-threshold, the so-called "upper bound", is >something that Van has argued and I think I have heard >Kathy agree is non-essential. It may be that >we could agree to drop it as a control. > There has been a lot of work by different folks in the area of RED-variants and RED parameter setting recently. Until these different endeavours gather sufficient momentum in academia and industry, I would suggest that we focus the MIB efforts on specifying parameters for RED-93. I would suggest that the MIB contain at least the 3 key parameters traditionally associated with configuring RED-93 (minth, maxth and maxp). It would also be good if the MIB contained the weight (wq) since it seems to be a key parameter in governing RED's performance. [1] I use the term MRED (Multi-Level RED) as the generic term to describe Multiple-levels of RED - this is one possible way of achieving AF. Various MRED algorithms have been proposed and are being used - all the algorithms require a set of RED parameters per drop precedence level or AF DSCP. So I would suggest that the MIB should provide support for this. Instead of 1 set of RED parameters per physical queue, we would have 3 sets of parameters for queues used for the AF classes - I thought the MIB already supported this but I haven't looked at the recent versions. [2] The MRED algorithms differ in the number of queue average calculations that they base their drop decision on. Some algorithms use a single queue average to make drop decisions for all packets of an AF class while other algorithms track and use multiple queue averages to make their drop decisions. Given, that we don't want to force vendors AF implementations to a specific algorithm, I would suggest that the MIB allows a configurable number of Qaverages to be calculated and returned for monitoring purposes. This leaves it to the vendor to decide which type of MRED algorithm to use to achieve AF. [3] Best, Nabil Seddigh nseddigh@nortelnetworks.com _______________________________________________ diffserv mailing list diffserv@ietf.org http://www1.ietf.org/mailman/listinfo/diffserv Archive: http://www-nrg.ee.lbl.gov/diff-serv-arch/ From diffserv-admin@ietf.org Fri May 26 14:47: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 OAA22844 for ; Fri, 26 May 2000 14:47: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 OAA23497; Fri, 26 May 2000 14:17: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 OAA23467 for ; Fri, 26 May 2000 14:17:24 -0400 (EDT) Received: from sol.extremenetworks.com (sol.extremenetworks.com [216.52.8.2]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA22163 for ; Fri, 26 May 2000 14:17:22 -0400 (EDT) Received: by SOL with Internet Mail Service (5.5.2650.21) id ; Fri, 26 May 2000 11:13:43 -0700 Message-ID: <808F64DDB492D3119D3C00508B5D8D7302905AEE@SOL> From: Andrew Smith To: John Schnizlein , Diff Serv Subject: RE: [Diffserv] diffserv-model-03 Date: Fri, 26 May 2000 11:13:39 -0700 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: text/plain Sender: diffserv-admin@ietf.org Errors-To: diffserv-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Diffserv Discussion List X-BeenThere: diffserv@ietf.org It's only an example. But I guess we shouldn't encourage people if it is something that is frowned on - should I replace it with a "legacy IP Precedence" example perhaps? (only slightly kidding). Andrew > -----Original Message----- > From: John Schnizlein [SMTP:jschnizl@cisco.com] > Sent: Wednesday, May 24, 2000 5:04 PM > To: Diff Serv > Subject: [Diffserv] diffserv-model-03 > > Is the type of Masked-DSCP consistent with the prohibition against > treating DSCP values as structured rather than as arbitrary values? > Section 4.1.2 of the model seems to encourage something other than > MUST match against the entire 6-bit field requirement in RFC 2474. > > excerpts from both documents follow: > > diffserv-model-03: > 4.1.2. Overlapping Filters > > Note that it is easy to define sets of overlapping filters in a > classifier. For example: > > Filter5: > Type: Masked-DSCP > Value: 111000 > Mask: 111000 > > RFC 2474 Differentiated Services Field: > Implementors should note that the DSCP field is six bits wide. DS- > compliant nodes MUST select PHBs by matching against the entire 6-bit > DSCP field, e.g., by treating the value of the field as a table index > which is used to select a particular packet handling mechanism which > has been implemented in that device. The value of the CU field MUST > be ignored by PHB selection. The DSCP field is defined as an > unstructured field to facilitate the definition of future per-hop > behaviors. > > > _______________________________________________ > 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 May 26 15:42: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 PAA23781 for ; Fri, 26 May 2000 15:42: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 OAA24110; Fri, 26 May 2000 14:49: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 OAA24079 for ; Fri, 26 May 2000 14:49:11 -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 OAA22872 for ; Fri, 26 May 2000 14:49:10 -0400 (EDT) Received: from jschnizl1-pc (dhcp-2sjc13-85-100.cisco.com [171.70.85.100]) by diablo.cisco.com (8.8.6 (PHNE_14041)/CISCO.SERVER.1.2) with SMTP id LAA27458; Fri, 26 May 2000 11:48:36 -0700 (PDT) Message-Id: <4.1.20000526144104.00a72c30@diablo.cisco.com> X-Sender: jschnizl@diablo.cisco.com X-Mailer: QUALCOMM Windows Eudora Pro Version 4.1 Date: Fri, 26 May 2000 14:45:10 -0400 To: Andrew Smith , Diff Serv From: John Schnizlein Subject: RE: [Diffserv] diffserv-model-03 In-Reply-To: <808F64DDB492D3119D3C00508B5D8D7302905AEE@SOL> 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 Yes, an example of how to transition from TOS precedence into Class Selectors would be much better, and would avoid the implication that masking (or any other numerical operation) on DS code points is acceptable. John At 11:13 AM 05/26/2000 -0700, Andrew Smith wrote: >It's only an example. But I guess we shouldn't encourage people if >it is something that is frowned on - should I replace it with a >"legacy IP Precedence" example perhaps? (only slightly kidding). > >> From: John Schnizlein [SMTP:jschnizl@cisco.com] >> Is the type of Masked-DSCP consistent with the prohibition against >> treating DSCP values as structured rather than as arbitrary values? >> Section 4.1.2 of the model seems to encourage something other than >> MUST match against the entire 6-bit field requirement in RFC 2474. _______________________________________________ diffserv mailing list diffserv@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 May 26 17:03: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 RAA25836 for ; Fri, 26 May 2000 17:03: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 QAA25347; Fri, 26 May 2000 16:35: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 QAA25319 for ; Fri, 26 May 2000 16:35:32 -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 QAA25092 for ; Fri, 26 May 2000 16:35:31 -0400 (EDT) Received: from wooly-booly.cisco.com (wooly-booly.cisco.com [171.69.167.33]) by sj-msg-core-2.cisco.com (8.9.3/8.9.1) with ESMTP id NAA18262; Fri, 26 May 2000 13:35:09 -0700 (PDT) Received: from p7020-img-nt.cisco.com (fred-hm-dhcp1.cisco.com [171.69.128.116]) by wooly-booly.cisco.com (8.8.8-Cisco List Logging/CISCO.WS.1.2) with ESMTP id PAA03287; Fri, 26 May 2000 15:34:59 -0500 (CDT) Message-Id: <4.3.2.7.2.20000526113526.029436a0@flipper.cisco.com> X-Sender: fred@flipper.cisco.com X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Fri, 26 May 2000 12:43:30 -0700 To: "Nabil Seddigh" From: Fred Baker Subject: Re: [Diffserv] Diffserv MIB - droppers Cc: "Diffserv (E-mail)" In-Reply-To: <200005260153.VAA25312@ietf.org> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: diffserv-admin@ietf.org Errors-To: diffserv-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Diffserv Discussion List X-BeenThere: diffserv@ietf.org At 09:51 PM 5/25/00 -0400, Nabil Seddigh wrote: >I would suggest that the MIB contain at least the >3 key parameters traditionally associated with configuring >RED-93 (minth, maxth and maxp). It would also be good if the >MIB contained the weight (wq) since it seems to be >a key parameter in governing RED's performance. [1] I'll buy that >Instead of 1 set of RED parameters >per physical queue, we would have 3 sets of parameters >for queues used for the AF classes This needs to be generalized, as AF defines but is not limited to 3 classes. We need it to be indexed in such a way that it is clear what parameters apply to which class of traffic. > - I thought the MIB already supported this but I haven't looked at the > recent versions. [2] The most recent version of the MIB leaves this as an open issue. >I would suggest that the MIB allows a configurable number of Qaverages to >be calculated and returned for monitoring purposes. This leaves it to the >vendor to decide which type >of MRED algorithm to use to achieve AF. [3] not sure what you mean by that. If you mean we should externalize the various means, I'll argue that the information is ephemeral, and we have been removing ephemeral information from public MIBs over the past few years (and as a design guideline have generally not included it in the first place) as its utility was suspect. If you mean that we should allow separate averages to be maintained, I don't see anything in having a configuration block per DSCP per queue, or equivalently per action that applies to a queue, to negate that. Unfortunately, though, the way you *use* them could be very different. For example, Cisco's WRED (one of the MRED's you mention) uses a single average, and it is the mean depth of the queue. we start dropping from a DSCP when its target queue depth (minth) is less than or equal to the mean queue depth associated with it. The effect of usual configurations is to drop most to all of AFx3 if we have to drop any of AFx2, and and most or all of AFx2 if we have to drop any of AFx1. RIO is another algorithm, and keeps a separate mean depth for each DSCP - the number of packets of that DSCP in the queue. Depending on how that is configured, it could keep some of each DSCP in the queue, or might similarly exhaust one before dropping from the next. So you would wind up configuring the thresholds quite differently. SO now the next question might be whether there are implementations which use a different number - If you have N DSCPs in the same queue, do you have one mean, N means, or some other number? If you have some other number, then I submit that the problem gets even more interesting - how do you correlate thresholds with averages? Do you want to configure that as well? If such exist, that would very much need to reshape our thinking. But if it doesn't, then the only question is "do you have one average or N", and a vendor could provide instructions for the configuration of his equipment. So I think I am arguing toward min-threshold and max-threshold, as Kathy suggested, an exponent to manage the exponential averaging (minp), and if you like an upper bound on the drop rate (the weight), and a counter per action so that we can measure the effect of the configuration. I am arguing to not externalize the current mean depth, as it is ephemeral, and if we did, I would argue that we want one mean (an attribute of the queue) or N (an attribute of the action, in the same table entry with the min-threshold is gets compared to). Is that acceptable to you? Does that represent a list consensus? _______________________________________________ diffserv mailing list diffserv@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 May 26 17:06: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 RAA25904 for ; Fri, 26 May 2000 17:06: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 QAA25390; Fri, 26 May 2000 16:37: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 QAA25359 for ; Fri, 26 May 2000 16:36:56 -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 QAA25118 for ; Fri, 26 May 2000 16:36:55 -0400 (EDT) Received: from wooly-booly.cisco.com (wooly-booly.cisco.com [171.69.167.33]) by sj-msg-core-1.cisco.com (8.9.3/8.9.1) with ESMTP id NAA28267; Fri, 26 May 2000 13:35:16 -0700 (PDT) Received: from p7020-img-nt.cisco.com (fred-hm-dhcp1.cisco.com [171.69.128.116]) by wooly-booly.cisco.com (8.8.8-Cisco List Logging/CISCO.WS.1.2) with ESMTP id PAA03293; Fri, 26 May 2000 15:35:05 -0500 (CDT) Message-Id: <4.3.2.7.2.20000526124513.02306f00@flipper.cisco.com> X-Sender: fred@flipper.cisco.com X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Fri, 26 May 2000 12:47:44 -0700 To: Dan Grossman From: Fred Baker Subject: Re: [Diffserv] Diffserv MIB - droppers Cc: "Diffserv (E-mail)" In-Reply-To: <200005252045.QAA26592@noah.dma.isg.mot.com> References: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: diffserv-admin@ietf.org Errors-To: diffserv-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Diffserv Discussion List X-BeenThere: diffserv@ietf.org At 04:45 PM 5/25/00 -0400, Dan Grossman wrote: >I have heard tell of such a thing in one implementation (but would rather its >implementor speak for themselves). I also cannot speak to implementations >that >I might involved in. Sounds like more than one. OK, I won't argue too hard against it if it is real as opposed to research. My point has to do with the disparity between the fact that this version of the MIB supports this, which I needed someone to tell me is actually in use by someone, and the fact that it doesn't support something which diff-serv standardizes and the IETF strongly recommends that people implement. The latter makes no sense to me. _______________________________________________ diffserv mailing list diffserv@ietf.org http://www1.ietf.org/mailman/listinfo/diffserv Archive: http://www-nrg.ee.lbl.gov/diff-serv-arch/ From diffserv-admin@ietf.org Fri May 26 20: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 UAA28280 for ; Fri, 26 May 2000 20: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 TAA27118; Fri, 26 May 2000 19:43: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 TAA27089 for ; Fri, 26 May 2000 19:43:19 -0400 (EDT) Received: from sol.extremenetworks.com (sol.extremenetworks.com [216.52.8.2]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA28031 for ; Fri, 26 May 2000 19:43:18 -0400 (EDT) Received: by SOL with Internet Mail Service (5.5.2650.21) id ; Fri, 26 May 2000 16:36:30 -0700 Message-ID: <808F64DDB492D3119D3C00508B5D8D733EC8DB@SOL> From: Andrew Smith To: xavi@angelfire.com Cc: diffserv@ietf.org Subject: RE: [Diffserv] (No Subject) Date: Fri, 26 May 2000 16:36: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 Actually, the relevant drafts from the RAP working group are: http://www.ietf.org/internet-drafts/draft-ietf-rap-pr-02.txt http://www.ietf.org/internet-drafts/draft-ietf-rap-sppi-00.txt http://www.ietf.org/internet-drafts/draft-ietf-rap-frameworkpib-00.txt For some tutorial paterial you might also look at the IETF proceedings, starting from http://www.ietf.org/proceedings/directory.html. You will find several slide presentations about COPS-PR under the RAP WG there. Thanks, Andrew Smith RAP WG co-chair > -----Original Message----- > From: Brian E Carpenter [mailto:brian@hursley.ibm.com] > Sent: Thursday, May 25, 2000 11:59 AM > To: xavi@angelfire.com > Cc: diffserv@ietf.org > Subject: Re: [Diffserv] (No Subject) > > > draft-ietf-diffserv-pib-00.txt is the only related document > in diffserv. > > draft-ietf-rap-cops-ds is also relevant (not sure of the > latest version number). > > Brian > > Xavier Lopez-Murtra wrote: > > > > I would like to know in which drafts or RFC's > > can I find information about the utilization > > of COPS protocol in DS domains. Thank you very > > much. > > > > Angelfire for your free web-based e-mail. http://www.angelfire.com > > > > _______________________________________________ > > diffserv mailing list > > diffserv@ietf.org > > http://www1.ietf.org/mailman/listinfo/diffserv > > Archive: http://www-nrg.ee.lbl.gov/diff-serv-arch/ > > _______________________________________________ > diffserv mailing list > diffserv@ietf.org > http://www1.ietf.org/mailman/listinfo/diffserv > Archive: http://www-nrg.ee.lbl.gov/diff-serv-arch/ > _______________________________________________ diffserv mailing list diffserv@ietf.org http://www1.ietf.org/mailman/listinfo/diffserv Archive: http://www-nrg.ee.lbl.gov/diff-serv-arch/ From diffserv-admin@ietf.org Sat May 27 22:30: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 WAA24074 for ; Sat, 27 May 2000 22:30: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 WAA13045; Sat, 27 May 2000 22:00: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 WAA13014 for ; Sat, 27 May 2000 22:00:27 -0400 (EDT) Received: from cyberus.ca (mail.cyberus.ca [209.195.95.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA23636 for ; Sat, 27 May 2000 22:00:25 -0400 (EDT) Received: from shell.cyberus.ca (shell [209.195.95.7]) by cyberus.ca (8.9.3/8.9.3/Cyberus Online Inc.) with ESMTP id WAA23726 for ; Sat, 27 May 2000 22:00:27 -0400 (EDT) Received: from localhost (hadi@localhost) by shell.cyberus.ca (8.9.1b+Sun/8.9.3) with ESMTP id WAA02276 for ; Sat, 27 May 2000 22:00:25 -0400 (EDT) Date: Sat, 27 May 2000 22:00:25 -0400 (EDT) From: jamal To: diffserv@ietf.org Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Subject: [Diffserv] Comment on model draft-03 Sender: diffserv-admin@ietf.org Errors-To: diffserv-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Diffserv Discussion List X-BeenThere: diffserv@ietf.org My general opinion (havent followed up on this since version 00) And i havent been subscribed to the list for a long time, so must have missed a lot of fun discussions. please cc responses to me. This version seems to have sunk into more "implementation specifics" [..] draft> draft> conserving servicess a packet, if one is available, at every draft> transmission opportunity." The quotes above seem to be a typo. [..] draft>3.1. Elements of a Diffserv Router draft> draft> o Traffic Conditioning (TC) actions of Marking, Absolute Dropping, draft> Counting and Multiplexing. draft> I might have asked this earlier; but why are the actions limited to the above? draft>Bernet et al. Expires November 2000 [Page 8] draft> draft>Internet Draft Diffserv Conceptual Model May 2000 draft> draft> [..] draft>be implemented on the ingress component, with the packet passed through draft>the routing core with in-band control information to allow for egress draft>queue selection. draft> draft>>From a device-configuration and management perspective, the following The extra ">" seems to be a typo. draft>We use the following diagram to illustrate a classifier, where the draft>outputs connect to succeeding functional elements: draft> draft> unclassified classified draft> traffic traffic draft> +------------+ draft> | |--> match Filter1 --> OutputA draft> ------->| classifier |--> match Filter2 --> OutputB draft> | |--> no match --> OutputC draft> +------------+ draft> draft> Figure 3. An Example Classifier draft> draft>Note that we allow a multiplexor (see Section 6.5) before the classifier draft>to allow input from multiple traffic streams. For example, if multiple draft>ingress sub-interfaces feed through a single classifier then the draft>interface number can be considered by the classifier as a packet draft>attribute and be included in the packet's classification key. This draft>optimization may be important for scalability in the management plane. draft>Another example of a packet attribute could be an integer representing draft>the BGP community string associated with the packet's best-matching draft>route. This whole classifier being 1:N element is becoming confusing. What you need to do is define the meaning of "output stream", literally. [One could argue that infact a classifier is a N:1 element. You have N different type of packet headers coming in and one "class identifier" or queue selector or whatever you wanna call it as an output.] Could a BA classifier be defined to be a special case of the six tuple classifier (with the 5 tuples other than the DSCP being wildcards?) draft> [..] draft>6. Action Elements draft> draft>The classifiers and meters described up to this point are fan-out draft>elements which are generally used to determine the appropriate action to draft>apply to a packet. The set of possible actions include: draft> draft>- Marking draft> draft>- Absolute Dropping draft> draft>- Multiplexing draft> draft>- Counting Is Counting really an action element? I would have thought it is explicitly part of statistics maintanance; regardless, what has it really got to do with defining a diffserv router model? I have scanned the document and observed a spot where it is defined to be used as a way "to tell the customer" it is time to upgrade the SLS or something along those lines. IMO, that is not a good enough reason. It would be good to put it under "other". This way we also leave that portion open for future additions. draft>6.3. Multiplexer draft> draft>It is occasionally necessary to multiplex traffic streams into a 1:1 or draft>1:N action element or classifier. A M:1 (fan-in) multiplexer is a draft>simple logical device for merging traffic streams. It is parameterized draft>by its number of incoming ports. draft> draft> Mux1: draft> Type: Multiplexer draft> Output: Queue2 draft> I am really trying to understand the use of this multiplexer box. Is it just a mechanism to logically explain the joining of two output classifier streams? Would the following not have sufficed? ----|-------> | -->-| Seems like the juncture point has become a box now. Either that or you need to have a lot more supporting text to justify the Mux (which is not there right now). draft> draft>7.1.1. FIFO draft> [...] draft> draft>In an implementation, packets are presumably stored in one or more draft>buffers. Buffers are allocated from one or more free buffer pools. If draft>there are multiple instances of a FIFO, their packet buffers may or may draft>not be allocated out of the same free buffer pool. Free buffer pools may draft>also have one or more threshold associated with them, which may affect draft>discarding and/or scheduling. Other than this, buffering mechanisms are draft>implementation specific and not part of this model. draft> Implementation details ? draft>7.1.3. Algorithmic Dropper draft> draft>An Algorithmic Dropper is an element which selectively discards packets draft>that arrive at its input, based on a discarding algorithm. It has one draft>data input and one output. In this model (but not necessarily in a real draft>implementation), a packet enters the dropper at its input and either its draft>buffer is returned to a free buffer pool or the packet exits the dropper draft>at the output. draft> draft>Alternatively, an Algorithmic Dropper may invoke operations on a FIFO draft>which selectively removes a packet, then return its buffer to the free draft>buffer pool, based on a discarding algorithm. In this case, the draft>operation is modelled as a side-effect on the FIFO upon which it draft>operates, rather than as having a discrete input and output. These two draft>treatments are equivalent and we choose the former here. draft> draft>The Algorithmic Dropper is modelled as having a single input. However, draft>it is likely that packets which were classified differently by a draft>Classifier in this TCB will end up passing through the same dropper. The draft>dropper's algorithm may need to apply different calculations based on draft>characteristics of the incoming packet e.g. its DSCP. So there is a draft>need, in implementations of this model, to be able to relate information draft>about which classifier element was matched by a packet from a Classifier draft>to an Algorithmic Dropper. This is modelled here as a reverse pointer draft>from one of the drop probability calculation algorithms inside the draft>dropper to the classifier element that selects this algorithm. draft> draft>There are many formulations of a model that could represent this draft>linkage, other than the one described above: one way would have been to draft>have multiple "inputs" fed from the preceding elements, leading draft>eventually to the classifier elements that matched the packet. Another draft>formulation might have been for the Classifier to (logically) include draft>some sort of "classification identifier" along with the packet along its draft>path, for use by any subsequent element. Yet another could have been to draft>include a classifier inside the dropper, in order for it to pick out the draft> draft> Lotsa more implementation specifics. With the algorithmic dropper,since you use the RED-like algorithm as an example, where does ECN marking fit? (note your usage of "dropper"). draft>The dropping algorithm makes a decision on whether to forward or to draft>discard a packet. It takes as its parameters some set of dynamic draft>parameters (e.g. averaged or instantaneous FIFO depth) and some set of draft>static parameters (e.g. thresholds) and possibly parameters associated draft> draft> +------------------+ +-----------+ draft> | +-------+ | n |smoothing | draft> | |trigger|<----------/---|function(s)| draft> | |calc. | | |(optional) | draft> | +-------+ | +-----------+ draft> | | | ^ draft> | v | |Depth draft> Input | +-------+ no | ------------+ to Scheduler draft> ---------->|discard|--------------> |x|x|x|x|-------> draft> | | ? | | ------------+ draft> | +-------+ | FIFO draft> | |yes | draft> | | | | | draft> | | v | count + | draft> | +---+ bit-bucket| draft> +------------------+ draft> Algorithmic draft> Dropper draft> draft> Figure 5. Algorithmic Dropper + Queue draft> draft> Another rat hole. Out of band smoothing function versus in-data-path smoothing function. draft>with the packet (e.g. its PHB, as determined by a classifier, which will draft>determine on which of the droppers inputs trhe packet arrives). It may "trhe" is a typo. draft>8.1. An Example TCB draft> draft>A SLS is presumed to have been negotiated between the customer and the draft>provider which specifies the handling of the customer's traffic by the draft>provider's network. The agreement might be of the following form: draft> draft> DSCP PHB Profile Treatment draft> ---- --- ------- ---------------------- draft> 001001 EF Profile4 Discard non-conforming. draft> 001100 AF11 Profile5 Shape to profile, tail-drop when full. draft> 001101 AF21 Profile3 Re-mark non-conforming to DSCP 001000, draft> tail-drop when full. draft> other BE none Apply RED-like dropping. draft> draft>This SLS specifies that the customer may submit packets marked for DSCP draft>001001 which will get EF treatment so long as they remain conforming to draft>Profile1 and will be discarded if they exceed this profile. The Do you really foresee an SLS looking like the above example ;->? [..] draft>The Queueing stage is realised as follows, shown in figure 6. The draft>conforming 001001 packets are passed directly to Queue1: there is no You mean figure 7? cheers, jamal _______________________________________________ diffserv mailing list diffserv@ietf.org http://www1.ietf.org/mailman/listinfo/diffserv Archive: http://www-nrg.ee.lbl.gov/diff-serv-arch/ From diffserv-admin@ietf.org Sat May 27 22:36: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 WAA24865 for ; Sat, 27 May 2000 22:36: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 WAA13182; Sat, 27 May 2000 22:16: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 WAA13153 for ; Sat, 27 May 2000 22:16:44 -0400 (EDT) Received: from cyberus.ca (mail.cyberus.ca [209.195.95.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA23758 for ; Sat, 27 May 2000 22:16:43 -0400 (EDT) Received: from shell.cyberus.ca (shell [209.195.95.7]) by cyberus.ca (8.9.3/8.9.3/Cyberus Online Inc.) with ESMTP id WAA26494; Sat, 27 May 2000 22:16:41 -0400 (EDT) Received: from localhost (hadi@localhost) by shell.cyberus.ca (8.9.1b+Sun/8.9.3) with ESMTP id WAA02288; Sat, 27 May 2000 22:16:40 -0400 (EDT) Date: Sat, 27 May 2000 22:16:40 -0400 (EDT) From: jamal To: diffserv@ietf.org cc: fred@cisco.com, nseddigh@nortelnetworks.com, khchan@nortelnetworks.com Subject: Re: [Diffserv] Diffserv MIB - droppers Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: diffserv-admin@ietf.org Errors-To: diffserv-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Diffserv Discussion List X-BeenThere: diffserv@ietf.org The Linux implementation, publicly available, implements several Multi-level "RED-like" algorithms fit for AF PHB. We have WRED, Generalized coupled Multi-level RIO as well as a decoupled one. RED configuration was a small headache we had to worry about; the draft "Differentiated Services on Linux" found at: ftp://lrcftp.epfl.ch/pub/linux/diffserv/misc/dsid-01.txt although slightly dated (eg it doesnt show the ingress components) will explain how we configure the different variants. look at section 4.3 "sch_gred" Sorry, dont have the time to go over the draft. cheers, jamal _______________________________________________ diffserv mailing list diffserv@ietf.org http://www1.ietf.org/mailman/listinfo/diffserv Archive: http://www-nrg.ee.lbl.gov/diff-serv-arch/ From diffserv-admin@ietf.org Sat May 27 22:36: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 WAA24876 for ; Sat, 27 May 2000 22:36: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 WAA13293; Sat, 27 May 2000 22:23: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 WAA13250 for ; Sat, 27 May 2000 22:22:57 -0400 (EDT) Received: from cyberus.ca (mail.cyberus.ca [209.195.95.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA23811 for ; Sat, 27 May 2000 22:22:55 -0400 (EDT) Received: from shell.cyberus.ca (shell [209.195.95.7]) by cyberus.ca (8.9.3/8.9.3/Cyberus Online Inc.) with ESMTP id WAA27525 for ; Sat, 27 May 2000 22:22:57 -0400 (EDT) Received: from localhost (hadi@localhost) by shell.cyberus.ca (8.9.1b+Sun/8.9.3) with ESMTP id WAA02292 for ; Sat, 27 May 2000 22:22:56 -0400 (EDT) Date: Sat, 27 May 2000 22:22:56 -0400 (EDT) From: jamal To: diffserv@ietf.org Subject: Re: [Diffserv] Diffserv MIB - droppers 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 For a quick overview of the architecture we have: http://www.davin.ottawa.on.ca/ols/img9.htm We are fully conformant to the model draft except for some implementation specifics. cheers, jamal _______________________________________________ diffserv mailing list diffserv@ietf.org http://www1.ietf.org/mailman/listinfo/diffserv Archive: http://www-nrg.ee.lbl.gov/diff-serv-arch/ From diffserv-admin@ietf.org Sun May 28 17:18: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 RAA10407 for ; Sun, 28 May 2000 17:18: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 RAA26485; Sun, 28 May 2000 17:06: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 RAA26454 for ; Sun, 28 May 2000 17:06:38 -0400 (EDT) Received: from sol4.rmc.ca (sol4.rmc.ca [137.94.1.134]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA10369 for ; Sun, 28 May 2000 17:06:37 -0400 (EDT) Received: from dullaert1 (dialup39.rmc.ca [137.94.252.39]) by sol4.rmc.ca (Netscape Messaging Server 4.1) with SMTP id FVAFZ100.JH9 for ; Sun, 28 May 2000 17:06:37 -0400 Message-Id: <3.0.32.20000528170649.006a02dc@post.rmc.ca> X-Sender: dullaert@post.rmc.ca X-Mailer: Windows Eudora Pro Version 3.0 (32) Date: Sun, 28 May 2000 17:06:58 -0400 To: diffserv@ietf.org From: "John Dullaert" Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Subject: [Diffserv] diffserv-model-03 Sender: diffserv-admin@ietf.org Errors-To: diffserv-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Diffserv Discussion List X-BeenThere: diffserv@ietf.org Just a few comments/observations. Algorithmic Droppers...recommend "one or more" just to be safe. FIFO description...for consistency with the rest of the element descriptions, I would recommend a single input with allowance for a multiplexer if required. By modelling the dropper with separate inputs for IN and OUT traffic, how do you avoid reordering of flows which have packets in both categories? (I am thinking a simple FCFS methodology) In the threshold dropper, should the trigger have referred to FIFO2 as typed, or FIFO1? Or should the output have been FIFO2? In the example TCB I believe you have used Profile5 and Profile2 interchangeably. Open Issues: 1 - Specifying an Absolute Dropper may be too restrictive when an Algorithmic Dropper could meet the requirement. 2 - Agree John C. Dullaert Captain Royal Military College of Canada ECE Grad Student 548-8053 fax 548-8408 _______________________________________________ diffserv mailing list diffserv@ietf.org http://www1.ietf.org/mailman/listinfo/diffserv Archive: http://www-nrg.ee.lbl.gov/diff-serv-arch/ From diffserv-admin@ietf.org Tue May 30 01:52: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 BAA14562 for ; Tue, 30 May 2000 01:52: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 BAA22125; Tue, 30 May 2000 01:22: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 BAA22094 for ; Tue, 30 May 2000 01:22:26 -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 BAA11355 for ; Tue, 30 May 2000 01:22:22 -0400 (EDT) Received: from zcard00m.ca.nortel.com (actually zcard00m) by ertpg14e1.nortelnetworks.com; Tue, 30 May 2000 01:09:28 -0400 Received: from zcard00f.ca.nortel.com ([47.129.30.8]) by zcard00m.ca.nortel.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2650.21) id L8GTAQ7Z; Tue, 30 May 2000 01:09:24 -0400 Received: from americasm01.nt.com (47.199.34.221 [47.199.34.221]) by zcard00f.ca.nortel.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2650.21) id L5HL7MRJ; Tue, 30 May 2000 01:09:27 -0400 Message-ID: <393352DC.66D0825C@americasm01.nt.com> Date: Tue, 30 May 2000 01:34:20 -0400 From: "Nabil Seddigh" Organization: Nortel Networks X-Mailer: Mozilla 4.61 [en] (X11; U; Linux 2.2.12-20 i686) X-Accept-Language: en MIME-Version: 1.0 To: fred@cisco.com, diffserv@ietf.org CC: "Nabil Seddigh" Subject: Re: [Diffserv] Diffserv MIB - droppers Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: diffserv-admin@ietf.org Errors-To: diffserv-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Diffserv Discussion List X-BeenThere: diffserv@ietf.org Content-Transfer-Encoding: 7bit On May 26, 2000 "Fred Baker" wrote: > >Instead of 1 set of RED parameters > >per physical queue, we would have 3 sets of parameters > >for queues used for the AF classes > > This needs to be generalized, as AF defines but > is not limited to 3 classes. We need it to be > indexed in such a way that it is clear what > parameters apply to which class of traffic. > Agreed. I guess this is also good for backwards compatibility in the case of pre-Diffserv products that used more than 3 thresholds of RED parameters within a single Q. > > not sure what you mean by that. If you mean we should > externalize the various means, I'll argue that the > information is ephemeral, and we have been removing > ephemeral information from public MIBs over the past > few years (and as a design guideline have generally > not included it in the first place) as its utility > was suspect. If you mean that we should allow > separate averages to be maintained, I don't see > anything in having a configuration block per DSCP > per queue, or equivalently per action that > applies to a queue, to negate that. Unfortunately, > though, the way you *use* them could be very different. > Not exactly sure what "externalize the means" refers to. I was arguing that we should allow for multiple averages to be maintained within a single Q - not necessarily per DSCP though. More on this further down. I'm not proposing we allow the admin to configure a device to use single or multiple Q averages. Rather, for monitoring purposes, *if* a device uses multiple Q averages in its calculations, it should allow the multiple averages to be read. BTW, I had a look at the MIB's diffservQEntry fields and didn't find any field that returned the current Q size - did I miss it or is this not included? > For example, Cisco's WRED (one of the MRED's you > mention) uses a single average, and it is the mean > depth of the queue. [.SNIP..] RIO is another algorithm, and > keeps a separate mean depth for each DSCP - the number > of packets of that DSCP in the queue. > RIO and WRED are 2 of the MRED schemes I was thinking of. We have experimented with a decoupled-RIO scheme as well. Our comparison of the 3 algorithms reveals different behaviour depending on the traffic type... but this is probably beyond the scope of the WG or the MIB. > SO now the next question might be whether there are > implementations which use a different number - If you > have N DSCPs in the same queue, do you have > one mean, N means, or some other number? Can I add another twist :) The common case is to have a set of RED thresholds (Qmin, Qmax, Pmax) per DSCP within the AF class queue. However, it is also possible to have N DSCPs in queue and only M levels of drop precedence supported by that device. E.g. upstream nodes mark pkts with AF11, AF12 and AF13 but a downstream router supports only 2 levels of drop precedence. In this case, for the downstream device, though we have N DSCPs, we only need M thresholds where M < N. I suggest that we need to ensure that the MIB design handles this case as well. There are probably a number of ways to handle the above scenario. Currently, the diffservActionEntry allows mapping of DSCPs to a particular Q. This could be extended to allow mapping to a diffservAlgDropEntry. Conceptually, this is similar to the idea of "virtual queues" that has appeared in some recent Diffserv publications. I'm assuming that multiple RED thresholds per Q will be handled by multiple entries of diffservAlgDropEntry. On a side note, is there a particular reason why diffservAlgDropTable points to the QTable instead of the other way around? >If you have > some other number, then I submit that the problem > gets even more interesting - how do you > correlate thresholds with averages? > Do you want to configure that as well? > If such exist, that would very much need to > reshape our thinking. But if it doesn't, then the only > question is "do you have one average or N", and a > vendor could provide instructions for the >configuration of his equipment. > Agreed. I think if we allow either one average or M it would handle majority of the popular MRED algorithms. > So I think I am arguing toward min-threshold and > max-threshold, as Kathy suggested, an exponent to > manage the exponential averaging (minp), and if > you like an upper bound on the drop rate (the weight), > and a counter per action so that we can measure the > effect of the configuration. To use MIB terminology (pg 7) is this: Qmin, Qmax, Pmax and a 4th parameter from which the averaging "weight" can be derived? > I am arguing to not > externalize the current mean depth, as it is ephemeral, > and if we did, I would argue that we want one mean > (an attribute of the queue) or N (an attribute of the > action, in the same table entry with the min-threshold > is gets compared to). > Not sure what you mean by the above. Are you suggesting for the "N"-average case, we hang the fields off the diffservActionEntry? Can't we just have multiple entries of diffservAlgDropEntry with each entry representing a set of threholds. We then add a field to diffservActionEntry that points to the particular diffservAlgDropEntry. This should allow DSCP to drop precedence level mapping. Also not sure re: reference to min-threshold? I thought we would allow the admin to specify all the RED parameters per level of drop precedence supported by the device. BTW, a general comment for the MIB authors. Section 2.5.3 provides a visual view of the MIB Q table. I think that's a great idea! Have you considered similar examples for other MIB tables? Best, ----- Nabil Seddigh nseddigh@nortelnetworks.com _______________________________________________ diffserv mailing list diffserv@ietf.org http://www1.ietf.org/mailman/listinfo/diffserv Archive: http://www-nrg.ee.lbl.gov/diff-serv-arch/ From diffserv-admin@ietf.org Tue May 30 03:56: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 DAA21877 for ; Tue, 30 May 2000 03:56: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 DAA23350; Tue, 30 May 2000 03:03: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 DAA23322 for ; Tue, 30 May 2000 03:03:14 -0400 (EDT) Received: from sj-msg-core-1.cisco.com (sj-msg-core-1.cisco.com [171.71.163.11]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA21586 for ; Tue, 30 May 2000 03:03:12 -0400 (EDT) Received: from wooly-booly.cisco.com (wooly-booly.cisco.com [171.69.167.33]) by sj-msg-core-1.cisco.com (8.9.3/8.9.1) with ESMTP id AAA17728; Tue, 30 May 2000 00:02:51 -0700 (PDT) Received: from p7020-img-nt.cisco.com (fred-hm-dhcp1.cisco.com [171.69.128.116]) by wooly-booly.cisco.com (8.8.8-Cisco List Logging/CISCO.WS.1.2) with ESMTP id CAA04988; Tue, 30 May 2000 02:02:41 -0500 (CDT) Message-Id: <4.3.2.7.2.20000529235111.02ab6d60@flipper.cisco.com> X-Sender: fred@flipper.cisco.com X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Mon, 29 May 2000 23:56:53 -0700 To: "Nabil Seddigh" From: Fred Baker Subject: Re: [Diffserv] Diffserv MIB - droppers Cc: diffserv@ietf.org, Bert Wijnen In-Reply-To: <393352DC.66D0825C@americasm01.nt.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: diffserv-admin@ietf.org Errors-To: diffserv-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Diffserv Discussion List X-BeenThere: diffserv@ietf.org At 01:34 AM 5/30/00 -0400, Nabil Seddigh wrote: >I had a look at the MIB's diffservQEntry fields >and didn't find any field that returned the current Q size - >did I miss it or is this not included? The ifEntry used to contain a variable called ifQDepth, which was the queue depth in packets. This was obsoleted, as some equipment chose to not support it (it can be tricky, when part of a queue is on one card and part is on another, and there is a bus or fabric in between), and it was ephemeral - by the time you read it, the value you're looking at is not current and may not be relevant. Seeing as this was in MIB-I and MIB-II but was removed by the Interface MIB people for a principled reason, it didn't seem to make sense to re-introduce here in the form of "ifMeanQDepth". I'll ask our erstwhile NM AD to comment, though - Bert, do you think we should externalize mean queue depths in a random drop MIB? Why or why not? _______________________________________________ diffserv mailing list diffserv@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 May 30 09:50: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 JAA28748 for ; Tue, 30 May 2000 09:50: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 JAA27012; Tue, 30 May 2000 09:18: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 JAA26981 for ; Tue, 30 May 2000 09:18: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 JAA28150 for ; Tue, 30 May 2000 09:18: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 OAA114594; Tue, 30 May 2000 14:16:22 +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 OAA17636; Tue, 30 May 2000 14:16:18 +0100 (BST) Message-ID: <3933BF09.4E60BB86@hursley.ibm.com> Date: Tue, 30 May 2000 08:15:53 -0500 From: Brian E Carpenter Organization: IBM X-Mailer: Mozilla 4.61 [en] (Win98; I) X-Accept-Language: en,fr MIME-Version: 1.0 To: jamal CC: diffserv@ietf.org, fred@cisco.com, nseddigh@nortelnetworks.com, khchan@nortelnetworks.com Subject: Re: [Diffserv] Diffserv MIB - droppers References: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: diffserv-admin@ietf.org Errors-To: diffserv-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Diffserv Discussion List X-BeenThere: diffserv@ietf.org Content-Transfer-Encoding: 7bit Jamal, So what MIB parameters do you think are necessary for a RED dropper? Brian jamal wrote: > > The Linux implementation, publicly available, implements several > Multi-level "RED-like" algorithms fit for AF PHB. We have WRED, > Generalized coupled Multi-level RIO as well as a decoupled one. > > RED configuration was a small headache we had to worry about; the draft > "Differentiated Services > on Linux" found at: > ftp://lrcftp.epfl.ch/pub/linux/diffserv/misc/dsid-01.txt > although slightly dated (eg it doesnt show the ingress components) > will explain how we configure the different variants. > look at section 4.3 "sch_gred" > > Sorry, dont have the time to go over the draft. > > cheers, > jamal > > _______________________________________________ > diffserv mailing list > diffserv@ietf.org > http://www1.ietf.org/mailman/listinfo/diffserv > Archive: http://www-nrg.ee.lbl.gov/diff-serv-arch/ _______________________________________________ diffserv mailing list diffserv@ietf.org http://www1.ietf.org/mailman/listinfo/diffserv Archive: http://www-nrg.ee.lbl.gov/diff-serv-arch/ From diffserv-admin@ietf.org Tue May 30 10:10: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 KAA29343 for ; Tue, 30 May 2000 10:10: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 JAA27261; Tue, 30 May 2000 09: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 JAA27231 for ; Tue, 30 May 2000 09:30: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 JAA28314 for ; Tue, 30 May 2000 09:30:19 -0400 (EDT) Received: from sp3at21.hursley.ibm.com (sp3at21.hursley.ibm.com [9.20.45.21]) by mail-gw.hursley.ibm.com (AIX4.3/UCB 8.8.8/8.8.8) with ESMTP id OAA36838; Tue, 30 May 2000 14:29:48 +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 OAA17802; Tue, 30 May 2000 14:29:44 +0100 (BST) Message-ID: <3933C22F.4E178F41@hursley.ibm.com> Date: Tue, 30 May 2000 08:29:19 -0500 From: Brian E Carpenter Organization: IBM X-Mailer: Mozilla 4.61 [en] (Win98; I) X-Accept-Language: en,fr MIME-Version: 1.0 To: jamal CC: diffserv@ietf.org Subject: Re: [Diffserv] Comment on model draft-03 References: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: diffserv-admin@ietf.org Errors-To: diffserv-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Diffserv Discussion List X-BeenThere: diffserv@ietf.org Content-Transfer-Encoding: 7bit Jamal, Comments on some of your comments... > This version seems to have sunk into more "implementation specifics" That's not my impression. While we are not describing an implementation, it's impossible to describe a model that has no connection to *potential* implementations. ... > > draft>3.1. Elements of a Diffserv Router > draft> > draft> o Traffic Conditioning (TC) actions of Marking, Absolute Dropping, > draft> Counting and Multiplexing. > draft> > > I might have asked this earlier; but why are the actions limited to the > above? Because that seemed to be the consensus about a necessary & sufficient set. ... > draft>We use the following diagram to illustrate a classifier, where the > draft>outputs connect to succeeding functional elements: > draft> > draft> unclassified classified > draft> traffic traffic > draft> +------------+ > draft> | |--> match Filter1 --> OutputA > draft> ------->| classifier |--> match Filter2 --> OutputB > draft> | |--> no match --> OutputC > draft> +------------+ > draft> > draft> Figure 3. An Example Classifier > draft> > draft>Note that we allow a multiplexor (see Section 6.5) before the classifier > draft>to allow input from multiple traffic streams. For example, if multiple > draft>ingress sub-interfaces feed through a single classifier then the > draft>interface number can be considered by the classifier as a packet > draft>attribute and be included in the packet's classification key. This > draft>optimization may be important for scalability in the management plane. > draft>Another example of a packet attribute could be an integer representing > draft>the BGP community string associated with the packet's best-matching > draft>route. > > This whole classifier being 1:N element is becoming confusing. > What you need to do is define the meaning of "output stream", literally. Don't agree. A classifier is just a kick-sorter and it kicks packets into a number of bins. > > [One could argue that infact a classifier is a N:1 element. You have N > different type of packet headers coming in and one "class identifier" or > queue selector or whatever you wanna call it as an output.] Nah. It has a single input stream of mixed up packets and multiple output streams of classified packets. > > Could a BA classifier be defined to be a special case of the six tuple > classifier (with the 5 tuples other than the DSCP being wildcards?) We chose to differentiate between BA and MF classifiers two years ago. It would be very confusing to change that now. ... > > Is Counting really an action element? I would have thought it is explicitly > part of statistics maintanance; regardless, what has it really got to do > with defining a diffserv router model? In the real world it will be a function of the classifier, and it's needed for the MIB. I think it's fine where it is. ... > > I am really trying to understand the use of this multiplexer box. > Is it just a mechanism to logically explain the joining of two > output classifier streams? Or two input streams, yes. This doesn't seem to be a problem. ... > > With the algorithmic dropper,since you use the RED-like algorithm as > an example, where does ECN marking fit? (note your usage of "dropper"). ECN isn't part of Diffserv, so it doesn't fit in anywhere. > draft>The dropping algorithm makes a decision on whether to forward or to > draft>discard a packet. It takes as its parameters some set of dynamic > draft>parameters (e.g. averaged or instantaneous FIFO depth) and some set of > draft>static parameters (e.g. thresholds) and possibly parameters associated > draft> > draft> +------------------+ +-----------+ > draft> | +-------+ | n |smoothing | > draft> | |trigger|<----------/---|function(s)| > draft> | |calc. | | |(optional) | > draft> | +-------+ | +-----------+ > draft> | | | ^ > draft> | v | |Depth > draft> Input | +-------+ no | ------------+ to Scheduler > draft> ---------->|discard|--------------> |x|x|x|x|-------> > draft> | | ? | | ------------+ > draft> | +-------+ | FIFO > draft> | |yes | > draft> | | | | | > draft> | | v | count + | > draft> | +---+ bit-bucket| > draft> +------------------+ > draft> Algorithmic > draft> Dropper > draft> > draft> Figure 5. Algorithmic Dropper + Queue > draft> > draft> > > Another rat hole. > Out of band smoothing function versus in-data-path smoothing function. Doesn't look out of band to me; there's a feedback loop right there. Brian _______________________________________________ diffserv mailing list diffserv@ietf.org http://www1.ietf.org/mailman/listinfo/diffserv Archive: http://www-nrg.ee.lbl.gov/diff-serv-arch/ From diffserv-admin@ietf.org Tue May 30 13:00: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 NAA04475 for ; Tue, 30 May 2000 13:00: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 MAA29708; Tue, 30 May 2000 12: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 MAA29684 for ; Tue, 30 May 2000 12:37:04 -0400 (EDT) Received: from sol.extremenetworks.com (sol.extremenetworks.com [216.52.8.2]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA03963 for ; Tue, 30 May 2000 12:37:01 -0400 (EDT) Received: by SOL with Internet Mail Service (5.5.2650.21) id ; Tue, 30 May 2000 09:33:21 -0700 Message-ID: <808F64DDB492D3119D3C00508B5D8D7302DF8680@SOL> From: Andrew Smith To: jamal Cc: diffserv@ietf.org Subject: RE: [Diffserv] Comment on model draft-03 Date: Tue, 30 May 2000 09:33:20 -0700 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: text/plain Sender: diffserv-admin@ietf.org Errors-To: diffserv-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Diffserv Discussion List X-BeenThere: diffserv@ietf.org See below. > -----Original Message----- > From: Brian E Carpenter [SMTP:brian@hursley.ibm.com] > Sent: Tuesday, May 30, 2000 6:29 AM > To: jamal > Cc: diffserv@ietf.org > Subject: Re: [Diffserv] Comment on model draft-03 > ... > > Could a BA classifier be defined to be a special case of the six tuple > > classifier (with the 5 tuples other than the DSCP being wildcards?) > > We chose to differentiate between BA and MF classifiers two years ago. > It would be very confusing to change that now. [Andrew] In fact, the proposed Diffserv MIB only defines a 6-tuple table and makes you wildcard the fields you don't want to use - this is for the pragmatic reason that the MIB style-police do not like having 2 objects with overlapping functionality and that fewer objects is better than more objects. The Conceptual Model, however, ought to be "purer" and treat them separately, which it does. 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 Tue May 30 13:03: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 NAA04571 for ; Tue, 30 May 2000 13:03: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 MAA29286; Tue, 30 May 2000 12:15: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 MAA29255 for ; Tue, 30 May 2000 12:15:14 -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 MAA03362 for ; Tue, 30 May 2000 12:15:11 -0400 (EDT) Message-Id: <200005301615.MAA03362@ietf.org> Received: from zcard00m.ca.nortel.com (actually zcard00m) by ertpg14e1.nortelnetworks.com; Tue, 30 May 2000 11:38:43 -0400 Received: from zcard00f.ca.nortel.com ([47.129.30.8]) by zcard00m.ca.nortel.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2650.21) id L8GTBRH7; Tue, 30 May 2000 11:38:34 -0400 Received: from zcarh014 (zcarh014.ca.nortel.com [47.23.81.6]) by zcard00f.ca.nortel.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2650.21) id L5HL7NVJ; Tue, 30 May 2000 11:38:39 -0400 Date: Tue, 30 May 2000 11:38:28 -0400 (EDT) X-Sybari-Space: 00000000 00000000 00000000 From: "Nabil Seddigh" Reply-To: "Nabil Seddigh" Subject: Re: [Diffserv] Diffserv MIB - droppers To: Fred Baker cc: diffserv@ietf.org, Bert Wijnen X-Mailer: Rosa 2.1 HP-UXB.10.20 X-Rosa-Trace: nseddigh@zcarh014 <47.23.81.6> MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-ID: Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by optimus.ietf.org id MAA29256 Sender: diffserv-admin@ietf.org Errors-To: diffserv-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Diffserv Discussion List X-BeenThere: diffserv@ietf.org Content-Transfer-Encoding: 8bit In message "[Diffserv] Diffserv MIB - droppers", Fred Baker writes: >The ifEntry used to contain a variable called ifQDepth, >which was the queue depth in packets. This was obsoleted, >as some equipment chose to not support it (it can be tricky, when >part of a queue is on one card and part is on another, and there >is a bus or fabric in between), and it was ephemeral - by >the time you read it, the value you're looking at is not current >and may not be relevant. If taken in isolation, the transient value of the queue size may not have relevance. However, a periodically sampled queue size value is a useful parameter for offline traffic engineering and network management tools - this is particularly true as we develop Diffserv services. I would suggest that the MIB include not just the N or 1 average queue sizes but also the instantaneous value of the physical queue. Most devices will explicitly track this information so the MIB is not imposing any new "feature" requirements. -- Nabil Seddigh nseddigh@nortelnetworks.com _______________________________________________ diffserv mailing list diffserv@ietf.org http://www1.ietf.org/mailman/listinfo/diffserv Archive: http://www-nrg.ee.lbl.gov/diff-serv-arch/ From diffserv-admin@ietf.org Tue May 30 13:36: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 NAA05152 for ; Tue, 30 May 2000 13:36: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 NAA00157; Tue, 30 May 2000 13:03: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 NAA00126 for ; Tue, 30 May 2000 13:03:21 -0400 (EDT) Received: from sol.extremenetworks.com (sol.extremenetworks.com [216.52.8.2]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA04565 for ; Tue, 30 May 2000 13:03:20 -0400 (EDT) Received: by SOL with Internet Mail Service (5.5.2650.21) id ; Tue, 30 May 2000 09:59:39 -0700 Message-ID: <808F64DDB492D3119D3C00508B5D8D733EC8E1@SOL> From: Andrew Smith To: "'Nabil Seddigh'" Cc: diffserv@ietf.org Subject: RE: [Diffserv] Diffserv MIB - droppers Date: Tue, 30 May 2000 09:59: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 Nabil, > -----Original Message----- > From: Nabil Seddigh [mailto:nseddigh@nortelnetworks.com] > Sent: Tuesday, May 30, 2000 8:38 AM > To: Fred Baker > Cc: diffserv@ietf.org; Bert Wijnen > Subject: Re: [Diffserv] Diffserv MIB - droppers ... > Most devices will explicitly track this information > so the MIB is not imposing any new "feature" > requirements. That's quite a leap - just because a device uses this deep down in the implementation doesn't mean that it is easy to extract and report back, particularly for a silicon implementation. The criteria to use on evaluating a MIB variable for inclusion in a standards'-track MIB must be primarily based on the utility to a SNMP manager for the management of commonly-agreed functionality. If it passes that test, then we can look at whether it is too "expensive" to implement generally. Andrew **************************************************************** Andrew Smith tel: +1 (408) 579-2821 Extreme Networks fax: +1 (408) 579-3000 3585 Monroe St. http://www.extremenetworks.com Santa Clara CA 95051-1450 em: andrew@extremenetworks.com **************************************************************** _______________________________________________ diffserv mailing list diffserv@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 May 30 14:35: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 OAA06592 for ; Tue, 30 May 2000 14:35: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 OAA00956; Tue, 30 May 2000 14:04: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 OAA00928 for ; Tue, 30 May 2000 14:04:01 -0400 (EDT) Received: from sol.extremenetworks.com (sol.extremenetworks.com [216.52.8.2]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA05894 for ; Tue, 30 May 2000 14:03:59 -0400 (EDT) Received: by SOL with Internet Mail Service (5.5.2650.21) id ; Tue, 30 May 2000 11:00:08 -0700 Message-ID: <808F64DDB492D3119D3C00508B5D8D733EC8E5@SOL> From: Andrew Smith To: "'Nabil Seddigh'" Cc: diffserv@ietf.org Subject: RE: [Diffserv] Diffserv MIB - droppers Date: Tue, 30 May 2000 11:00:08 -0700 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: text/plain; charset="iso-8859-1" Sender: diffserv-admin@ietf.org Errors-To: diffserv-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Diffserv Discussion List X-BeenThere: diffserv@ietf.org See [Andrew] below. > -----Original Message----- > From: Nabil Seddigh [mailto:nseddigh@nortelnetworks.com] > Sent: Monday, May 29, 2000 10:34 PM > To: fred@cisco.com; diffserv@ietf.org > Cc: Nabil Seddigh > Subject: Re: [Diffserv] Diffserv MIB - droppers ... > > not sure what you mean by that. If you mean we should > > externalize the various means, I'll argue that the > > information is ephemeral, and we have been removing > > ephemeral information from public MIBs over the past > > few years (and as a design guideline have generally > > not included it in the first place) as its utility > > was suspect. If you mean that we should allow > > separate averages to be maintained, I don't see > > anything in having a configuration block per DSCP > > per queue, or equivalently per action that > > applies to a queue, to negate that. Unfortunately, > > though, the way you *use* them could be very different. > > Not exactly sure what "externalize the means" refers to. > I was arguing that we should allow for multiple > averages to be maintained within a single Q - not > necessarily per DSCP though. More on this further > down. > > I'm not proposing we allow the admin to configure > a device to use single or multiple Q averages. > Rather, for monitoring purposes, *if* a device > uses multiple Q averages in its calculations, it > should allow the multiple averages to be read. > > BTW, I had a look at the MIB's diffservQEntry fields > and didn't find any field that returned the current Q size - > did I miss it or is this not included? [Andrew] Externalize == "make visible in a read-only variable in the MIB". The current assumption (MIB draft -03) is that such a variable should not be externalised (see Fred's response), even if it is maintained internally in the implementation. For what purpose would you want an SNMP manager to read these averages? ... > Can I add another twist :) The common case is to > have a set of RED thresholds (Qmin, Qmax, Pmax) > per DSCP within the AF class queue. > However, it is also possible to have N DSCPs in > queue and only M levels of drop precedence supported > by that device. E.g. upstream nodes mark pkts with > AF11, AF12 and AF13 but a downstream router > supports only 2 levels of drop precedence. In this > case, for the downstream device, though we have N DSCPs, > we only need M thresholds where M < N. I suggest that > we need to ensure that the MIB design handles this case > as well. [Andrew] We had a long discussion between the authors over whether an algorithmic dropper has multiple "inputs" (one per "classified stream") or has a single "input" with an implied internal classifier. We chose the latter. I place "input" in quotes because these are not really inputs and outputs in the data plane - they show relationships in the management plane, not packet flows. So there's really no problem in having multiple "inputs" to such a dropper - the data plane issues (e.g. no re-ordering) have to be handled by the data plane. The Conceptual Model draft discusses this point: "The Algorithmic Dropper is modelled as having a single input. However, it is likely that packets which were classified differently by a Classifier in this TCB will end up passing through the same dropper. The dropper's algorithm may need to apply different calculations based on characteristics of the incoming packet e.g. its DSCP. So there is a need, in implementations of this model, to be able 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." > There are probably a number of ways to handle > the above scenario. Currently, the diffservActionEntry > allows mapping of DSCPs to a particular Q. This > could be extended to allow mapping to > a diffservAlgDropEntry. Conceptually, this is > similar to the idea of "virtual queues" > that has appeared in some recent Diffserv > publications. I'm assuming that multiple RED > thresholds per Q will be handled by multiple > entries of diffservAlgDropEntry. [Andrew] If we add to this MIB support for a RED-like algorithm to handle AF, I expect that we will define a MIB structure that contains a back-pointer to the classifier filter element that selects the drop-probability function. > On a side note, is there a particular reason why > diffservAlgDropTable points to the QTable instead > of the other way around? [Andrew] I assume you mean diffServAlgDropQMeasure - this points to the queue whose characteristics the algorithm is measuring. diffServAlgDropNext points to the queue to which this dropper's traffic next goes (this may or may not be the same queue as that which is being measured). In addition, diffServAlgDropSpecific points to more specific detail of the algorithm - this -03 version of the draft considers further specification of this algorithm out of scope, but see issue 22. To quote from the MIB preamble: "2.5.1. Algorithmic Dropper Table Algorithmic Droppers have a close relationship with queueing: they are represented in this MIB by entries in an Algorithmic Dropper Table. Entries contain a "next" attribute which indicates to which queue they sink their traffic. They may also contain a pointer to specific detail of the drop algorithm. This MIB only defines the detail for one drop algorithm, Tail Drop; other algorithms are outside the scope of this MIB but the general framework is intended to allow for their inclusion in other modules. One generally-applicable parameter of a dropper is the specification of a queue-depth threshold at which some drop action is to start. This is represented in this MIB, as a base attribute of the Algorithmic Dropper entry, by pointing to the queue for which depth is to be compared and the threshold, in bytes, to compare against. " Anyhow, to answer your question: it is the algorithm that needs to refer to the queue that it is measuring: that's why it points at the queue, not vice-versa. > >If you have > > some other number, then I submit that the problem > > gets even more interesting - how do you > > correlate thresholds with averages? > > Do you want to configure that as well? > > If such exist, that would very much need to > > reshape our thinking. But if it doesn't, then the only > > question is "do you have one average or N", and a > > vendor could provide instructions for the > >configuration of his equipment. > > Agreed. I think if we allow either one average or M it > would handle majority of the popular MRED algorithms. > > > So I think I am arguing toward min-threshold and > > max-threshold, as Kathy suggested, an exponent to > > manage the exponential averaging (minp), and if > > you like an upper bound on the drop rate (the weight), > > and a counter per action so that we can measure the > > effect of the configuration. > > To use MIB terminology (pg 7) is this: > Qmin, Qmax, Pmax and a 4th parameter from which > the averaging "weight" can be derived? [Andrew] I'm still not understanding what is the exact set of parameters proposed and what they mean. Everyone so far seems to have difficulty in expressing (without referring to a particular algorithm/paper) what they mean by this mysterious "weight" thing. To me that indicates that there is no single DESCRIPTION that could possibly make everyone happy and still be meaningful - but I'm willing to listen to concrete proposals. > > I am arguing to not > > externalize the current mean depth, as it is ephemeral, > > and if we did, I would argue that we want one mean > > (an attribute of the queue) or N (an attribute of the > > action, in the same table entry with the min-threshold > > is gets compared to). > > Not sure what you mean by the above. Are you suggesting > for the "N"-average case, we hang the fields off the > diffservActionEntry? Can't we just have multiple > entries of diffservAlgDropEntry with each entry > representing a set of threholds. We then add a field > to diffservActionEntry that points to the particular > diffservAlgDropEntry. This should allow DSCP to drop > precedence level mapping. [Andrew] I think Fred's terminology has confused you: I agree with Fred that we should not have a "current queue depth" parameter in the MIB. The Model figure 5 shows how there can be one or more (what Fred calls N) "smoothing functions" per queue - these may use different parameter sets to do their calculations. These may feed into one or more (T) "trigger" or "drop probability calculation" functions. N may or may not be equal to T. I haven't yet worked out an actual MIB representation of this (was waiting to get consensus on what to include, if anything, first of all). But it would be connected with diffServAlgDropTable and diffServAlgDropSpecific and nothing to do with diffServActionTable - the Model considers algorithmic droppers to be queueing elements, not actions (yes, it's an arbitrary choice but it seems to fit better this way). > Also not sure re: reference to min-threshold? I thought > we would allow the admin to specify all the RED > parameters per level of drop precedence supported by > the device. [Andrew] Not sure what you mean here. > BTW, a general comment for the MIB authors. Section > 2.5.3 provides a visual view of the MIB Q table. > I think that's a great idea! Have you considered > similar examples for other MIB tables? [Andrew] Any ASCII drawings gratefully received (do you know how long it takes to do those diagrams without a 6-week course in nroff macro-coding?). Andrew **************************************************************** Andrew Smith tel: +1 (408) 579-2821 Extreme Networks fax: +1 (408) 579-3000 3585 Monroe St. http://www.extremenetworks.com Santa Clara CA 95051-1450 em: andrew@extremenetworks.com **************************************************************** _______________________________________________ diffserv mailing list diffserv@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 May 30 14:36: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 OAA06612 for ; Tue, 30 May 2000 14:36: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 OAA01108; Tue, 30 May 2000 14:15:25 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id OAA01084 for ; Tue, 30 May 2000 14:15:21 -0400 (EDT) Received: from e24.nc.us.ibm.com (e24.nc.us.ibm.com [32.97.136.230]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA06140 for ; Tue, 30 May 2000 14:15:19 -0400 (EDT) From: remoore@us.ibm.com Received: from southrelay02.raleigh.ibm.com (southrelay02.raleigh.ibm.com [9.37.3.209]) by e24.nc.us.ibm.com (8.9.3/8.9.3) with ESMTP id OAA34892 for ; Tue, 30 May 2000 14:02:47 -0500 Received: from d54mta04.raleigh.ibm.com (d54mta04.raleigh.ibm.com [9.67.228.36]) by southrelay02.raleigh.ibm.com (8.8.8m3/NCO v4.9) with SMTP id OAA41542 for ; Tue, 30 May 2000 14:15:19 -0400 Received: by d54mta04.raleigh.ibm.com(Lotus SMTP MTA v4.6.5 (863.2 5-20-1999)) id 852568EF.006446FD ; Tue, 30 May 2000 14:15:17 -0400 X-Lotus-FromDomain: IBMUS To: diffserv@ietf.org Message-ID: <852568EF.0063CB9F.00@d54mta04.raleigh.ibm.com> Date: Tue, 30 May 2000 14:09:15 -0400 Mime-Version: 1.0 Content-type: text/plain; charset=us-ascii Content-Disposition: inline Subject: [Diffserv] Comments on the -03 draft of the Diffserv MIB Sender: diffserv-admin@ietf.org Errors-To: diffserv-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Diffserv Discussion List X-BeenThere: diffserv@ietf.org I'll just start from the beginning of the draft and move through it: 1. Section 2.2.1, last paragraph: If you want to reference a document that describes roles, the PCIM has a much more complete discussion of them than Polterm does. 2. Section 2.3.1: This says that specific meter parameters are referenced via a RowPointer. In the MIB, though, (p.28) it's an Object Identifier rather than a RowPointer. Which is it supposed to be? 3. Section 2.4.3: This description doesn't match the MIB, since it refers to a nonexistent diffServActionType object. See my comment below, though -- what's currently in the MIB isn't right either. 4. diffServClassifierTable (p.19): The reference to "incoming" traffic seems wrong, unless it's just talking about traffic that's coming into the classifier. 5. diffServClassifierLevel (p.20): The value for the first level should be specified: I assume that it's 1, but 0 is also a possible guess. 6. diffServClassifierPrecedence (p.21): The last paragraph states clearly (except that it's misspelled:-) that the scope of a classifier is incoming traffic. But in the Conceptual Model classification is equally applicable to incoming and outgoing traffic. 7. diffServSixTupleClfrDstAddrMask (p.23): You should add UNITS="bits" to the definition. 8. diffServMeterTable (p.27): "The traffic stream to be metered is determined by the classifier upstream of the meter i.e. by the object(s) that point to each entry in this table using a RowPointer." This is too restrictive. There are examples in the Conceptual Model where an element other than a classifier feeds traffic to a meter. 9. diffServMeterSucceedNext (p.28), several other objects: I'm trying to relate the sentence about zeroDotZero back to the Conceptual Model. Does this value mean that the traffic is Muxed together with other traffic if necessary, and then passed out of the outermost TCB for the interface/direction? 10. diffServMeterSpecific (p.28): As noted above in item 2, the introduction already states that this is a RowPointer. Wouldn't a RowPointer be a better choice for this object than an Object Identifier? 11. diffServTBMeterTable (p.29): I've read the second paragraph, and compared it with section 2.3, but I'm still not sure what point is being made. It *seems* like the text in section 2.3 says that modeling complex meters with the objects defined in the MIB results in a model that's equivalent to the complex meter. (This also strikes me as how it should be.) In the description of diffServTBMeterTable, however, it says that the cascading of elements necessitated by the MIB structure results in something that is *not* "functionally equivalent to a multi-rate meter." You need to clarify what you mean here. There's also an editorial problem with the end of this description on p.30 -- the text just quits in the middle of a sentence." 12. diffServTBMeterStatus (p.30): You need to say more about how a RowStatus object works when the table it's in is just a "reflection" of another table. (I think you were about to say something about this in the sentence that got lost in the table's description.) Have you thought through whether you need a separate RowStatus object for this table at all? If you could somehow ride along on diffServMeterStatus, you'd avoid questions about what it means if these two status objects have different values. 13. diffServActionSpecific (p.33): The RowPointer TC in RFC 2579 doesn't allow you to point to a scalar object such as diffServAbsoluteDropAction. If you're *sure* that's this is the only case you'll have where you won't need to point to another table entry, then you could probably get away with assigning the absolute drop semantics to the value zeroDotZero. Otherwise, you'll need to do something else. 14. diffServActionStatus (p.33): Typo in the description: meter-->action 15. diffServDscpMarkActTable (p.34): How does this table work without a RowStatus object? Is this table just always there, with 64 rows in it, in case an action entry needs to point at it? 16. diffServDscpMarkActDscp (p.35): You need to state that the value -1 is not allowed for this object. 17. diffServCountActEntry (p.35): The last sentence of the description seems too weak. If an action entry points to this table, hasn't the entry it points to *got* to be here? 18. diffServCountActOctets (p.36), and all the other counters: There are two problems with specifying that ifCounterDiscontinuityTime is the discontinuity indicator for these counters: 1. The definition of ifCounterDiscontinuityTime gives an explicit list of counters that it "serves". I don't think you can come along later and add to this list. 2. In any case, don't these counters experience other discontinuity events (related to changes in the Diffserv configuration for an interface) that don't affect the total interface counters that ifCounterDiscontinuityTime tracks? The net is, I think you need to define a separate discontinuity indicator in diffServCountActTable to report discontinuities in these counters. 19. diffServCountActStatus (p.37): What does a RowStatus object accomplish if it's the only writeable object in the table? Rather than a RowStatus here, I think you need to describe the "magic" that causes a row of this table to come into existence as soon as there is an action entry to point to it. 20. diffServAbsoluteDropAction (p.37): As noted earlier, this object can't accomplish what you want it to. So it should just be removed. 21. diffServAlgDropQThreshold (p.40): This definition should have a UNITS clause. 22. diffServAlgDropSpecific (p.40): Why isn't this object defined as a RowPointer, since you've already said what the row index will be? 23. diffServAlgDropOctets (p;40), related counters: For the reasons given above, ifCounterDiscontinuityTime isn't the correct discontinuity indicator for these counters. Since there's no tight binding between counter action elements and algorithmic droppers, the discontinuity indicators for the counter action elements are also inappropriate. So yet another discontinuity indicator is needed for these counters. Sorry about the volume of these comments. But if you hadn't gotten them from me, I'm sure you would have gotten most of them from Bert's MIB reviewer a few weeks from now. I expect to send in some comments on the Conceptual Model by the end of this week. Regards, Bob Bob Moore IBM Networking Software +1-919-254-4436 remoore@us.ibm.com _______________________________________________ diffserv mailing list diffserv@ietf.org http://www1.ietf.org/mailman/listinfo/diffserv Archive: http://www-nrg.ee.lbl.gov/diff-serv-arch/ From diffserv-admin@ietf.org Tue May 30 15:05: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 PAA07395 for ; Tue, 30 May 2000 15:05: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 OAA01572; Tue, 30 May 2000 14: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 OAA01536 for ; Tue, 30 May 2000 14:36:20 -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 OAA06607 for ; Tue, 30 May 2000 14:36:18 -0400 (EDT) Message-Id: <200005301836.OAA06607@ietf.org> Received: from zcard00n.ca.nortel.com (actually zcard00n) by smtprch1.nortel.com; Tue, 30 May 2000 13:29:52 -0500 Received: from zcard00f.ca.nortel.com ([47.129.30.8]) by zcard00n.ca.nortel.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2650.21) id LW3AJXMM; Tue, 30 May 2000 14:29:52 -0400 Received: from zcarh014 (zcarh014.ca.nortel.com [47.23.81.6]) by zcard00f.ca.nortel.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2650.21) id L5HL7332; Tue, 30 May 2000 14:29:49 -0400 Date: Tue, 30 May 2000 14:29:36 -0400 (EDT) X-Sybari-Space: 00000000 00000000 00000000 From: "Nabil Seddigh" Reply-To: "Nabil Seddigh" Subject: RE: [Diffserv] Diffserv MIB - droppers To: Andrew Smith cc: diffserv@ietf.org X-Mailer: Rosa 2.1 HP-UXB.10.20 X-Rosa-Trace: nseddigh@zcarh014 <47.23.81.6> MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-ID: Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by optimus.ietf.org id OAA01537 Sender: diffserv-admin@ietf.org Errors-To: diffserv-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Diffserv Discussion List X-BeenThere: diffserv@ietf.org Content-Transfer-Encoding: 8bit Andrew, > >That's quite a leap - just because a device uses this >deep down in the implementation doesn't mean that it is >easy to extract and report back, >particularly for a silicon implementation. > Agreed! But then where do you draw the line? Using this line of thinking, one could argue that it is difficult for ASICs to report anything! >The criteria to use on evaluating a MIB variable for >inclusion in a standards'-track MIB must be primarily >based on the utility to a SNMP manager for the >management of commonly-agreed functionality. If it passes >that test, then we can look at whether it is too >"expensive" to implement generally. > So, if our first step (or "test") is to agree on the usefulness of the information, I would suggest that having a measure of the instantaneous and avg Q sizes is most definitely useful in a Diffserv-world. Best, --- Nabil Seddigh nseddigh@nortelnetworks.com _______________________________________________ diffserv mailing list diffserv@ietf.org http://www1.ietf.org/mailman/listinfo/diffserv Archive: http://www-nrg.ee.lbl.gov/diff-serv-arch/ From diffserv-admin@ietf.org Tue May 30 15:29: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 PAA07997 for ; Tue, 30 May 2000 15:29: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 PAA02294; Tue, 30 May 2000 15:10: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 PAA02263 for ; Tue, 30 May 2000 15:10:06 -0400 (EDT) Received: from sol.extremenetworks.com (sol.extremenetworks.com [216.52.8.2]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA07528 for ; Tue, 30 May 2000 15:10:06 -0400 (EDT) Received: by SOL with Internet Mail Service (5.5.2650.21) id ; Tue, 30 May 2000 12:06:25 -0700 Message-ID: <808F64DDB492D3119D3C00508B5D8D733EC8E8@SOL> From: Andrew Smith To: "'Nabil Seddigh'" Cc: diffserv@ietf.org Subject: RE: [Diffserv] Diffserv MIB - droppers Date: Tue, 30 May 2000 12:06: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 Sounds like a circular argument to me - it's useful because it's useful. Can you try to be a little more forthcoming in your uses? Andrew > -----Original Message----- > From: Nabil Seddigh [mailto:nseddigh@nortelnetworks.com] > Sent: Tuesday, May 30, 2000 11:30 AM > To: Andrew Smith > Cc: diffserv@ietf.org > Subject: RE: [Diffserv] Diffserv MIB - droppers ... > I would suggest that having a measure of > the instantaneous and avg Q sizes is most definitely > useful in a Diffserv-world. _______________________________________________ diffserv mailing list diffserv@ietf.org http://www1.ietf.org/mailman/listinfo/diffserv Archive: http://www-nrg.ee.lbl.gov/diff-serv-arch/ From diffserv-admin@ietf.org Tue May 30 16:07: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 QAA09288 for ; Tue, 30 May 2000 16:07: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 PAA02674; Tue, 30 May 2000 15:30: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 PAA02643 for ; Tue, 30 May 2000 15:30:38 -0400 (EDT) Received: from ennovatenetworks.com (ennovatenetworks.com [208.227.99.254]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA08079 for ; Tue, 30 May 2000 15:30:38 -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 PAA26888 for ; Tue, 30 May 2000 15:30:08 -0400 (EDT) (envelope-from bkumar@ennovatenetworks.com) Reply-To: From: "Brijesh Kumar" To: Date: Tue, 30 May 2000 15:33:58 -0400 Message-ID: <004601bfca6e$00e3b6c0$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: <808F64DDB492D3119D3C00508B5D8D733EC8DB@SOL> X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2615.200 Importance: Normal Content-Transfer-Encoding: 7bit Subject: [Diffserv] Some comments on Diff-Serve Conceptual Model Draft 3 Sender: diffserv-admin@ietf.org Errors-To: diffserv-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Diffserv Discussion List X-BeenThere: diffserv@ietf.org Content-Transfer-Encoding: 7bit This is kind of a strange draft whose usefulness seems only marginal to me (rationale for MIB definitions - do we really need one?). It may have been useful at some point, but at this point, there isn't any thing that is not already covered in Diff-Serv Arch document, or the MIB draft or the QoS policy draft. It would have been more useful it has provided more useful guidelines for implementation rather than shying away from the core issue. Any way, here are some other comments, that I jotted down while having a look at this draft. 1. What is an Absolute Dropper? Till recently, I thought a Dropper was a Dropper. Either you drop a packet (and free the memory), or you forward it and put on the queue. Let us not get into tail drop versus head drop or other infinite possible theoretical variations. There is only one object called Dropper which may drop as per the algorithm chosen from the set of possible N algorithms (tail drop, head drop, ..RED etc.). 2. Egress and ingress interfaces - despite the number of pages, the document doesn't explain the rationale for ingress queueing, and egress based classifiers and meters? Figure (1 & 2). 3. Classifiers "Note that we allow a multiplexer before the classifier (see section 6.5 ..) ...." The section 5. Well, it's not the question of this document allowing or disallowing, that is the way many (software) implementations that have a centralized routing for merged traffic streams will implement. Therefore, a classifier can be visualized either as a 1 to N mapping, or a M to N mapping of traffic streams. In reality, multiplexing is a result of an action (i.e., common ingress queueing) as all incoming traffic is written to a single classifier input queue. The similar arguments apply to a (conceptual) multiplexer preceding a meter. 4. Counting doesn't seem to be a valid action - it is kind of useless to say that if the traffic stream meets this criteria, then count, or if it doesn't meet this criteria then don't count. Gathering traffic statistics, is auto-magically implied in any network switch with or without Diff-Serv. Cheers, --brijesh Ennovate Networks Inc. _______________________________________________ diffserv mailing list diffserv@ietf.org http://www1.ietf.org/mailman/listinfo/diffserv Archive: http://www-nrg.ee.lbl.gov/diff-serv-arch/ From diffserv-admin@ietf.org Tue May 30 16:18: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 QAA09473 for ; Tue, 30 May 2000 16:18: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 PAA02921; Tue, 30 May 2000 15:45: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 PAA02890 for ; Tue, 30 May 2000 15:45:13 -0400 (EDT) Received: from ennovatenetworks.com (ennovatenetworks.com [208.227.99.254]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA08770 for ; Tue, 30 May 2000 15:45:12 -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 PAA27438; Tue, 30 May 2000 15:44:20 -0400 (EDT) (envelope-from bkumar@ennovatenetworks.com) Reply-To: From: "Brijesh Kumar" To: "'Nabil Seddigh'" , "'Andrew Smith'" Cc: Subject: RE: [Diffserv] Diffserv MIB - droppers Date: Tue, 30 May 2000 15:48:11 -0400 Message-ID: <004b01bfca6f$fd373ea0$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: <200005301836.OAA06607@ietf.org> 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 Nabil Seddigh writes: > From: diffserv-admin@ietf.org > >The criteria to use on evaluating a MIB variable for > >inclusion in a standards'-track MIB must be primarily > >based on the utility to a SNMP manager for the > >management of commonly-agreed functionality. If it passes > >that test, then we can look at whether it is too > >"expensive" to implement generally. > > > > So, if our first step (or "test") is to agree on the usefulness of the > information, I would suggest that having a measure of > the instantaneous and avg Q sizes is most definitely > useful in a Diffserv-world. > Why would you need that. On the high speed interfaces, it is hard to capture per queue data with any accuracy. For example, on a OC48 interface operating at 2.5 Giga bits per second avg queue size and instantaneous queue size may vary from 0 to buffer full in a second. Not only, it is hard to establish meaningful time period for such a measurement on high speed interfaces, such queue data conveys no meaningful information to the network manager. Cheers, --brijesh Ennovate Networks Inc. _______________________________________________ diffserv mailing list diffserv@ietf.org http://www1.ietf.org/mailman/listinfo/diffserv Archive: http://www-nrg.ee.lbl.gov/diff-serv-arch/ From diffserv-admin@ietf.org Tue May 30 17:07:06 2000 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA10563 for ; Tue, 30 May 2000 17:07:06 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id QAA03938; Tue, 30 May 2000 16:40: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 QAA03895 for ; Tue, 30 May 2000 16:40:39 -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 QAA09937 for ; Tue, 30 May 2000 16:40:33 -0400 (EDT) Message-Id: <200005302040.QAA09937@ietf.org> Received: from zcard00m.ca.nortel.com (actually zcard00m) by smtprch1.nortel.com; Tue, 30 May 2000 15:38:09 -0500 Received: from zcard00f.ca.nortel.com ([47.129.30.8]) by zcard00m.ca.nortel.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2650.21) id L8GTCSS9; Tue, 30 May 2000 16:38:01 -0400 Received: from zcarh014 (zcarh014.ca.nortel.com [47.23.81.6]) by zcard00f.ca.nortel.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2650.21) id L5HL7PB2; Tue, 30 May 2000 16:38:06 -0400 Date: Tue, 30 May 2000 16:37:52 -0400 (EDT) X-Sybari-Space: 00000000 00000000 00000000 From: "Nabil Seddigh" Reply-To: "Nabil Seddigh" Subject: RE: [Diffserv] Diffserv MIB - droppers To: Andrew Smith cc: diffserv@ietf.org X-Mailer: Rosa 2.1 HP-UXB.10.20 X-Rosa-Trace: nseddigh@zcarh014 <47.23.81.6> MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-ID: Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by optimus.ietf.org id QAA03896 Sender: diffserv-admin@ietf.org Errors-To: 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 >Sounds like a circular argument to me - it's useful because >it's useful. Can you try to be a little more forthcoming > in your uses? > Circular? I guess I thought the reasons for having average Q sizes was obvious. My apologies!! We have done extensive work with the AF PHB as incarnated by various MRED schemes: WRED, RIO & RIO-decoupled. In all cases, access to the queue averages greatly assisted in trouble shooting and "traffic engineering". Without this information, in many cases we would have been unable to tell whether end-customer achieved traffic characteristics was due to faulty configuration or algorithm specifics. Another reason for exporting the avg Q sizes are the emergence of Diffserv tools for network management. Offline traffic engineering and SLA tools require access to algorithm specific information. For the MRED algorithms, avg Q size is key to achieved performance - not only delay but also achieved bandwidth. Best, --- Nabil Seddigh nseddigh@nortelnetworks.com _______________________________________________ diffserv mailing list diffserv@ietf.org http://www1.ietf.org/mailman/listinfo/diffserv Archive: http://www-nrg.ee.lbl.gov/diff-serv-arch/ From diffserv-admin@ietf.org Tue May 30 17:12: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 RAA10682 for ; Tue, 30 May 2000 17:12: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 QAA03744; Tue, 30 May 2000 16:32: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 QAA03711 for ; Tue, 30 May 2000 16:32: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 QAA09813 for ; Tue, 30 May 2000 16:32:40 -0400 (EDT) Received: from sp3at21.hursley.ibm.com (sp3at21.hursley.ibm.com [9.20.45.21]) by mail-gw.hursley.ibm.com (AIX4.3/UCB 8.8.8/8.8.8) with ESMTP id VAA76174; Tue, 30 May 2000 21:32:10 +0100 Received: from hursley.ibm.com (gsine04.us.sine.ibm.com [9.14.6.44]) by sp3at21.hursley.ibm.com (AIX4.2/UCB 8.7/8.7.3) with ESMTP id VAA21754; Tue, 30 May 2000 21:32:08 +0100 (BST) Message-ID: <393424A9.57497A94@hursley.ibm.com> Date: Tue, 30 May 2000 15:29:29 -0500 From: Brian E Carpenter Organization: IBM X-Mailer: Mozilla 4.61 [en] (Win98; I) X-Accept-Language: en,fr MIME-Version: 1.0 To: bkumar@ennovatenetworks.com CC: diffserv@ietf.org Subject: Re: [Diffserv] Some comments on Diff-Serve Conceptual Model Draft 3 References: <004601bfca6e$00e3b6c0$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 kind of a strange draft whose usefulness seems only marginal to me > (rationale for MIB definitions - do we really need one?). It may have been > useful at some point, but at this point, there isn't any thing that is not > already covered in Diff-Serv Arch document, or the MIB draft or the QoS > policy draft. It would have been more useful it has provided more useful > guidelines for implementation rather than shying away from the core issue. Well, the WG decided it wanted such a document. One of the main reasons is to help ensure consistency between the MIB, the PIB and the higher level policy definitions, by providing a common reference nodel. > > Any way, here are some other comments, that I jotted down while having a > look at this draft. > > 1. What is an Absolute Dropper? Till recently, I thought a Dropper was a > Dropper. Either you drop a packet (and free the memory), or you forward it > and put on the queue. Let us not get into tail drop versus head drop or > other infinite possible theoretical variations. There is only one object > called Dropper which may drop as per the algorithm chosen from the set of > possible N algorithms (tail drop, head drop, ..RED etc.). Linguistically I tend to agree. > > 2. Egress and ingress interfaces - despite the number of pages, the document > doesn't explain the rationale for ingress queueing, and egress based > classifiers and meters? Figure (1 & 2). True, there is no rationale. But again, this is what the WG wanted. > > 3. Classifiers > > "Note that we allow a multiplexer before the classifier (see section 6.5 ..) > ...." The section 5. Well, it's not the question of this document allowing > or disallowing, that is the way many (software) implementations that have a > centralized routing for merged traffic streams will implement. Therefore, a > classifier can be visualized either as a 1 to N mapping, or a M to N mapping > of traffic streams. In reality, multiplexing is a result of an action (i.e., > common ingress queueing) as all incoming traffic is written to a single > classifier input queue. The similar arguments apply to a (conceptual) > multiplexer preceding a meter. Are you proposing a document change? > 4. Counting doesn't seem to be a valid action - it is kind of useless to say > that if the traffic stream meets this criteria, then count, or if it doesn't > meet this criteria then don't count. Gathering traffic statistics, is > auto-magically implied in any network switch with or without Diff-Serv. This is included as a basis for the corresponding MIB variables. Brian _______________________________________________ diffserv mailing list diffserv@ietf.org http://www1.ietf.org/mailman/listinfo/diffserv Archive: http://www-nrg.ee.lbl.gov/diff-serv-arch/ From diffserv-admin@ietf.org Tue May 30 17:14: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 RAA10707 for ; Tue, 30 May 2000 17:14: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 QAA03692; Tue, 30 May 2000 16:31:59 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id QAA03591 for ; Tue, 30 May 2000 16:31:53 -0400 (EDT) Received: from sol.extremenetworks.com (sol.extremenetworks.com [216.52.8.2]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA09802 for ; Tue, 30 May 2000 16:31:52 -0400 (EDT) Received: by SOL with Internet Mail Service (5.5.2650.21) id ; Tue, 30 May 2000 13:28:11 -0700 Message-ID: <808F64DDB492D3119D3C00508B5D8D733EC8EB@SOL> From: Andrew Smith To: "'bkumar@ennovatenetworks.com'" , diffserv@ietf.org Subject: RE: [Diffserv] Some comments on Diff-Serve Conceptual Model Draf t 3 Date: Tue, 30 May 2000 13:28:06 -0700 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: text/plain; charset="iso-8859-1" Sender: diffserv-admin@ietf.org Errors-To: diffserv-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Diffserv Discussion List X-BeenThere: diffserv@ietf.org Brijesh, It is precisely for the reasons that you mention that we need this draft: oterhwise we will get several almost-but-not-entirely-consistent drafts that compete for terminology or semantics. Yes, it is the rationale for MIB definitions, PIB definitions, policy models, UML models, LDAP schemas, etc. etc. The background material and model should not be replicated multiple times. Certainly if there is overlap with the Diffserv MIB document then that is my oversight - please tell me where and I will fix it. Overlap with the "QoS policy draft" should be addressed to the authors of that document. Implementation guidelines are often not a topic for IETF WGs to address but they are certainly not within the scope of this document. Feel free to raise this as a possible work item with the WG co-chairs if you'd like to work on it in the Diffserv WG. Andrew (speaking for the other Model draft authors, I hope) **************************************************************** Andrew Smith tel: +1 (408) 579-2821 Extreme Networks fax: +1 (408) 579-3000 3585 Monroe St. http://www.extremenetworks.com Santa Clara CA 95051-1450 em: andrew@extremenetworks.com **************************************************************** > -----Original Message----- > From: Brijesh Kumar [mailto:bkumar@ennovatenetworks.com] > Sent: Tuesday, May 30, 2000 12:34 PM > To: diffserv@ietf.org > Subject: [Diffserv] Some comments on Diff-Serve Conceptual > Model Draft 3 > > > > This is kind of a strange draft whose usefulness seems only > marginal to me > (rationale for MIB definitions - do we really need one?). It > may have been > useful at some point, but at this point, there isn't any > thing that is not > already covered in Diff-Serv Arch document, or the MIB draft > or the QoS > policy draft. It would have been more useful it has provided > more useful > guidelines for implementation rather than shying away from > the core issue. > _______________________________________________ diffserv mailing list diffserv@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 May 30 17:36: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 RAA11032 for ; Tue, 30 May 2000 17:36: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 RAA04559; Tue, 30 May 2000 17:05: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 RAA04527 for ; Tue, 30 May 2000 17:04:58 -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 RAA10520 for ; Tue, 30 May 2000 17:04:56 -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 OAA17152; Tue, 30 May 2000 14:03:49 -0700 (PDT) Received: by nt-exchange1.pmc-sierra.bc.ca with Internet Mail Service (5.5.2650.21) id ; Tue, 30 May 2000 14:03:51 -0700 Message-ID: <336ECDAFDF7DD311B9E30090277AEE4101B4059E@nt-exchange-bby.pmc-sierra.bc.ca> From: Shahram Davari To: "'bkumar@ennovatenetworks.com'" , diffserv@ietf.org Subject: RE: [Diffserv] Some comments on Diff-Serve Conceptual Model Draf t 3 Date: Tue, 30 May 2000 14:00: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 Hi, One of the reasons for having ingress queuing is for the switch fabrics that support virtual output queues (VOQ). Regards, -Shahram >-----Original Message----- >From: Brijesh Kumar [mailto:bkumar@ennovatenetworks.com] >Sent: Tuesday, May 30, 2000 3:34 PM >To: diffserv@ietf.org >Subject: [Diffserv] Some comments on Diff-Serve Conceptual >Model Draft 3 > > > >This is kind of a strange draft whose usefulness seems only >marginal to me >(rationale for MIB definitions - do we really need one?). It >may have been >useful at some point, but at this point, there isn't any thing >that is not >already covered in Diff-Serv Arch document, or the MIB draft or the QoS >policy draft. It would have been more useful it has provided >more useful >guidelines for implementation rather than shying away from the >core issue. > >Any way, here are some other comments, that I jotted down >while having a >look at this draft. > >1. What is an Absolute Dropper? Till recently, I thought a >Dropper was a >Dropper. Either you drop a packet (and free the memory), or >you forward it >and put on the queue. Let us not get into tail drop versus head drop or >other infinite possible theoretical variations. There is only >one object >called Dropper which may drop as per the algorithm chosen from >the set of >possible N algorithms (tail drop, head drop, ..RED etc.). > >2. Egress and ingress interfaces - despite the number of >pages, the document >doesn't explain the rationale for ingress queueing, and egress based >classifiers and meters? Figure (1 & 2). > >3. Classifiers > >"Note that we allow a multiplexer before the classifier (see >section 6.5 ..) >...." The section 5. Well, it's not the question of this >document allowing >or disallowing, that is the way many (software) >implementations that have a >centralized routing for merged traffic streams will implement. >Therefore, a >classifier can be visualized either as a 1 to N mapping, or a >M to N mapping >of traffic streams. In reality, multiplexing is a result of an >action (i.e., >common ingress queueing) as all incoming traffic is written to a single >classifier input queue. The similar arguments apply to a (conceptual) >multiplexer preceding a meter. > >4. Counting doesn't seem to be a valid action - it is kind of >useless to say >that if the traffic stream meets this criteria, then count, or >if it doesn't >meet this criteria then don't count. Gathering traffic statistics, is >auto-magically implied in any network switch with or without Diff-Serv. > > >Cheers, > >--brijesh >Ennovate Networks Inc. > > >_______________________________________________ >diffserv mailing list >diffserv@ietf.org >http://www1.ietf.org/mailman/listinfo/diffserv >Archive: http://www-nrg.ee.lbl.gov/diff-serv-arch/ > _______________________________________________ diffserv mailing list diffserv@ietf.org http://www1.ietf.org/mailman/listinfo/diffserv Archive: http://www-nrg.ee.lbl.gov/diff-serv-arch/ From diffserv-admin@ietf.org Tue May 30 18:00:50 2000 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA11483 for ; Tue, 30 May 2000 18:00:50 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id RAA05323; Tue, 30 May 2000 17:40: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 RAA05296 for ; Tue, 30 May 2000 17:40: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 RAA11109 for ; Tue, 30 May 2000 17:40:05 -0400 (EDT) Received: from sp3at21.hursley.ibm.com (sp3at21.hursley.ibm.com [9.20.45.21]) by mail-gw.hursley.ibm.com (AIX4.3/UCB 8.8.8/8.8.8) with ESMTP id WAA170326; Tue, 30 May 2000 22:39:18 +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 WAA15384; Tue, 30 May 2000 22:39:15 +0100 (BST) Message-ID: <3934344D.23F750B2@hursley.ibm.com> Date: Tue, 30 May 2000 16:36:13 -0500 From: Brian E Carpenter Organization: IBM X-Mailer: Mozilla 4.61 [en] (Win98; I) X-Accept-Language: en,fr MIME-Version: 1.0 To: Andrew Smith CC: "'bkumar@ennovatenetworks.com'" , diffserv@ietf.org Subject: Re: [Diffserv] Some comments on Diff-Serve Conceptual Model Draft 3 References: <808F64DDB492D3119D3C00508B5D8D733EC8EB@SOL> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: diffserv-admin@ietf.org Errors-To: diffserv-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Diffserv Discussion List X-BeenThere: diffserv@ietf.org Content-Transfer-Encoding: 7bit Andrew Smith wrote: > Overlap with the "QoS > policy draft" should be addressed to the authors of that document. Indeed the Policy Framework WG people are looking very carefully at the model draft, since consistency between their work and ours is essential. Brian _______________________________________________ diffserv mailing list diffserv@ietf.org http://www1.ietf.org/mailman/listinfo/diffserv Archive: http://www-nrg.ee.lbl.gov/diff-serv-arch/ From diffserv-admin@ietf.org Tue May 30 18:02: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 SAA11610 for ; Tue, 30 May 2000 18:02: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 RAA05212; Tue, 30 May 2000 17:34: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 RAA05183 for ; Tue, 30 May 2000 17:33:59 -0400 (EDT) Received: from ennovatenetworks.com (ennovatenetworks.com [208.227.99.254]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA11003 for ; Tue, 30 May 2000 17:33:57 -0400 (EDT) Received: from broncos (broncos.tst.ennovatenetworks.com [10.1.1.208]) by ennovatenetworks.com (8.8.7/8.8.7) with SMTP id RAA01845; Tue, 30 May 2000 17:33:26 -0400 (EDT) (envelope-from bkumar@ennovatenetworks.com) Reply-To: From: "Brijesh Kumar" To: "'Brian E Carpenter'" Cc: Subject: RE: [Diffserv] Some comments on Diff-Serve Conceptual Model Draft 3 Date: Tue, 30 May 2000 17:37:14 -0400 Message-ID: <004c01bfca7f$38c11ae0$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: <393424A9.57497A94@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 In his previous mail, Brian Carpenter writes > > > > 1. What is an Absolute Dropper? Till recently, I thought a > Dropper was a > > Dropper. Either you drop a packet (and free the memory), or > you forward it > > and put on the queue. Let us not get into tail drop versus > head drop or > > other infinite possible theoretical variations. There is > only one object > > called Dropper which may drop as per the algorithm chosen > from the set of > > possible N algorithms (tail drop, head drop, ..RED etc.). > > Linguistically I tend to agree. Brian, I am glad that you agree. I hope the authors will re-consider their use of multiple Dropper objects (Absolute and Algorithmic) which, I think, is unnecessary. > > > > 2. Egress and ingress interfaces - despite the number of > pages, the document > > doesn't explain the rationale for ingress queueing, and egress based > > classifiers and meters? Figure (1 & 2). > > True, there is no rationale. But again, this is what the WG wanted. If the model doesn't explain why an object exists in a model, and its rationale for existence, then, at least to me, it is like a protocol state machine which has a state that cannot be reached from any other state. It is fine with me if others don't see it that way. > > 3. Classifiers > > > > "Note that we allow a multiplexer before the classifier > (see section 6.5 ..) > > ...." The section 5. Well, it's not the question of this > document allowing > > or disallowing, that is the way many (software) > implementations that have a > > centralized routing for merged traffic streams will > implement. Therefore, a > > classifier can be visualized either as a 1 to N mapping, or > a M to N mapping > > of traffic streams. In reality, multiplexing is a result of > an action (i.e., > > common ingress queueing) as all incoming traffic is written > to a single > > classifier input queue. The similar arguments apply to a > (conceptual) > > multiplexer preceding a meter. > > Are you proposing a document change? I hope the authors will consider it. > > 4. Counting doesn't seem to be a valid action - it is kind > of useless to say > > that if the traffic stream meets this criteria, then count, > or if it doesn't > > meet this criteria then don't count. Gathering traffic > statistics, is > > auto-magically implied in any network switch with or > without Diff-Serv. > > This is included as a basis for the corresponding MIB variables. What I wanted to convey that the existence of a count action object by itself is meaningless. In a Diff-Serv context, an action will always be "Count and Drop" or "Count and Forward" combination (i.e., (1) Drop with Count or (2) Forward with Count). Cheers, --brijesh Ennovate Networks Inc., _______________________________________________ diffserv mailing list diffserv@ietf.org http://www1.ietf.org/mailman/listinfo/diffserv Archive: http://www-nrg.ee.lbl.gov/diff-serv-arch/ From diffserv-admin@ietf.org Tue May 30 18:08: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 SAA11694 for ; Tue, 30 May 2000 18:08: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 RAA05375; Tue, 30 May 2000 17:41:19 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id RAA05347 for ; Tue, 30 May 2000 17:41:15 -0400 (EDT) Received: from sol.extremenetworks.com (sol.extremenetworks.com [216.52.8.2]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA11120 for ; Tue, 30 May 2000 17:41:13 -0400 (EDT) Received: by SOL with Internet Mail Service (5.5.2650.21) id ; Tue, 30 May 2000 14:37:33 -0700 Message-ID: <808F64DDB492D3119D3C00508B5D8D733EC8EC@SOL> From: Andrew Smith To: "'remoore@us.ibm.com'" Cc: diffserv@ietf.org Subject: RE: [Diffserv] Comments on the -03 draft of the Diffserv MIB Date: Tue, 30 May 2000 14:37:30 -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 Bob, Thanks for your thorough review. Please see below. In general these are nearly all MIB style/syntax/interpretation issues (except for 21 which is Diffserv). Please see suggested resolutions below. We'd also appreciate anyone's opinions on any of the other listed open issues. > -----Original Message----- > From: remoore@us.ibm.com [mailto:remoore@us.ibm.com] > Sent: Tuesday, May 30, 2000 11:09 AM > To: diffserv@ietf.org > Subject: [Diffserv] Comments on the -03 draft of the Diffserv MIB > > > > > I'll just start from the beginning of the draft and move > through it: > > 1. Section 2.2.1, last paragraph: If you want to reference > a document that describes roles, the PCIM has a much more > complete discussion of them than Polterm does. Can you give a specific reference? - there are many uses of the term "role" and I want to make sure we have the right one :-) > 2. Section 2.3.1: This says that specific meter parameters > are referenced via a RowPointer. In the MIB, though, (p.28) > it's an Object Identifier rather than a RowPointer. > Which is it supposed to be? OID pointing to the table. Indexing is implicit since the table has same indices as diffServMeterTable. This is simpler to implement and use than a more generic RowPointer. Will fix the descriptive text. > 3. Section 2.4.3: This description doesn't match the MIB, > since it refers to a nonexistent diffServActionType > object. See my comment below, though -- what's currently > in the MIB isn't right either. Will fix the description here to say: "2.4.3. Absolute Drop Action This action just silently discards all traffic presented to it, without counting it. This action has no additional parameters and so is represented only as a diffServActionSpecific pointing to diffServAbsoluteDropAction without any specific parameters." > 4. diffServClassifierTable (p.19): The reference to "incoming" > traffic seems wrong, unless it's just talking about traffic > that's coming into the classifier. Will clarify. > 5. diffServClassifierLevel (p.20): The value for the first > level should be specified: I assume that it's 1, but > 0 is also a possible guess. Not sure that this needs to be specified. The semantics of "lower" are clear. You might to label them as e.g. 10, 20, 30 to make adds/changes easier. What's a good reason to limit this further? > 6. diffServClassifierPrecedence (p.21): The last paragraph > states clearly (except that it's misspelled:-) that the > scope of a classifier is incoming traffic. But in the > Conceptual Model classification is equally applicable to > incoming and outgoing traffic. The completeness requirement only applies to incoming - that's what the Model draft 4.1.2 says anyhow: "Note that this completeness is only required of the first classifier that incoming traffic will meet as it enters an interface - subsequent classifiers on an interface only need to handle the traffic that it is known that they will receive." Will clarify this in the MIB draft. > 7. diffServSixTupleClfrDstAddrMask (p.23): You should add > UNITS="bits" to the definition. Sure. I guess it doesn't hurt to add it. > 8. diffServMeterTable (p.27): "The traffic stream to be > metered is determined by the classifier upstream of the > meter i.e. by the object(s) that point to each entry in > this table using a RowPointer." This is too restrictive. > There are examples in the Conceptual Model where an > element other than a classifier feeds traffic to a > meter. OK. > 9. diffServMeterSucceedNext (p.28), several other objects: > I'm trying to relate the sentence about zeroDotZero > back to the Conceptual Model. Does this value mean that > the traffic is Muxed together with other traffic if > necessary, and then passed out of the outermost TCB for > the interface/direction? Yes. > 10. diffServMeterSpecific (p.28): As noted above in item 2, > the introduction already states that this is a RowPointer. > Wouldn't a RowPointer be a better choice for this object > than an Object Identifier? I don't think it needs to be that flexible - see item 2 above. > 11. diffServTBMeterTable (p.29): I've read the second > paragraph, and compared it with section 2.3, but I'm > still not sure what point is being made. It *seems* > like the text in section 2.3 says that modeling complex > meters with the objects defined in the MIB results in > a model that's equivalent to the complex meter. (This > also strikes me as how it should be.) In the description > of diffServTBMeterTable, however, it says that the > cascading of elements necessitated by the MIB structure > results in something that is *not* "functionally > equivalent to a multi-rate meter." You need to clarify > what you mean here. Thank you - that's a leftover from the previous formulation. > There's also an editorial problem with the end of this > description on p.30 -- the text just quits in the middle > of a sentence." Hmm ... don't know what happened there. Thanks. > 12. diffServTBMeterStatus (p.30): You need to say more about > how a RowStatus object works when the table it's in is > just a "reflection" of another table. (I think you were > about to say something about this in the sentence that > got lost in the table's description.) Yes. > Have you thought > through whether you need a separate RowStatus object for > this table at all? If you could somehow ride along on > diffServMeterStatus, you'd avoid questions about what it > means if these two status objects have different values. No. That ought to have been listed as an open issue, similar to (16), (18) and (19). I agree with you in principal but you do have to handle the case where it is a different sort of meter than TB and where the columns of diffServTBMeterEntry are not meaningful (it is debatable whether they even ought to exist or not in this case). One possible solution would be to have a read-write variable that just selected valid/invalid but I'd rather this were automatically controlled by the base table i.e. diffServTBMeterValid = (diffServMeterSpecific == diffServTBMeterTable). diffServMeterStatus would probably be the wrong think to ride on. > 13. diffServActionSpecific (p.33): The RowPointer TC in > RFC 2579 doesn't allow you to point to a scalar object > such as diffServAbsoluteDropAction. If you're *sure* > that's this is the only case you'll have where you won't > need to point to another table entry, then you could > probably get away with assigning the absolute drop > semantics to the value zeroDotZero. Otherwise, you'll > need to do something else. I had looked at RFC 2579 and to me it was not clear to me whether a scalar OID would count or not - depends on the definition of "conceptual row" I guess (the reference pointer in 2579 to the definition in 2578 seems to be broken). We really want to make this an InstancePointer (a.k.a. RowOrVariablePointer) but that has been deprecated :-(. I guess we can just make this an OBJECT IDENTIFIER if we're uncomfortable with the semantics of RowPointer. > 14. diffServActionStatus (p.33): Typo in the description: > > meter-->action OK. > 15. diffServDscpMarkActTable (p.34): How does this table > work without a RowStatus object? Is this table just > always there, with 64 rows in it, in case an action > entry needs to point at it? Yes. Seems simpler than the alternatives (it's not like an agent ever need store anything here - it's just a list of OIDs to point to). > 16. diffServDscpMarkActDscp (p.35): You need to state that > the value -1 is not allowed for this object. OK. > 17. diffServCountActEntry (p.35): The last sentence of the > description seems too weak. If an action entry points > to this table, hasn't the entry it points to *got* to > be here? It's deliberately weak. I think what you are saying is that we must mandate that a pointed-to entry can not be deleted until all references to it have first been deleted. We could do that if people think it necessary - it's harder to implement though. Whenever we use RowPointer in a MIB, a manager has to handle the case of dangling pointers reported by the agent. It's a lot easier though just to define the required semantics if there is a dangling pointer. > 18. diffServCountActOctets (p.36), and all the other > counters: There are two problems with specifying that > ifCounterDiscontinuityTime is the discontinuity > indicator for these counters: > > 1. The definition of ifCounterDiscontinuityTime gives > an explicit list of counters that it "serves". > I don't think you can come along later and add to > this list. We are not referring to those other interface counters (ifTable and ifXTable in http://www.ietf.org/rfc/rfc2233.txt), we are just piggy-backing onto the reasons for which that variable might have been updated. This is comon practice see e.g. RFC2668. > 2. In any case, don't these counters experience other > discontinuity events (related to changes in the > Diffserv configuration for an interface) that don't > affect the total interface counters that > ifCounterDiscontinuityTime tracks? Can you be more specific? Do you just mean whenever a diffServCountActStatus changes? > The net is, I think you need to define a separate > discontinuity indicator in diffServCountActTable to > report discontinuities in these counters. Possibly - need examples of what scenarios. > 19. diffServCountActStatus (p.37): What does a RowStatus > object accomplish if it's the only writeable object in > the table? Rather than a RowStatus here, I think you > need to describe the "magic" that causes a row of this > table to come into existence as soon as there is an > action entry to point to it. This was open issue 16. Either of the solutions I mentioned in the draft could be applied - further opinions are sought. > 20. diffServAbsoluteDropAction (p.37): As noted earlier, > this object can't accomplish what you want it to. So > it should just be removed. See earlier. > 21. diffServAlgDropQThreshold (p.40): This definition > should have a UNITS clause. Any suggestions? Bytes? Bits? Packets? Cells? > 22. diffServAlgDropSpecific (p.40): Why isn't this object > defined as a RowPointer, since you've already said > what the row index will be? RowPointer seems to have the implied semantics of being an arbitrary row for which the index portions of the OID would have to be checked for sanity, which would be redundant. Insisting that it just point to the OID of a table makes life a lot simpler for the agent and manager. If we are allowed to "refine" the semantics of RowPointer like this in a DESCRIPTION clause then we can call it a RowPointer but I expected the MIB Inquisition to descend on me if I did that. > 23. diffServAlgDropOctets (p;40), related counters: For > the reasons given above, ifCounterDiscontinuityTime > isn't the correct discontinuity indicator for these > counters. Since there's no tight binding between > counter action elements and algorithmic droppers, > the discontinuity indicators for the counter > action elements are also inappropriate. So yet > another discontinuity indicator is needed for these > counters. One way would be to say the the discontinuity is ANY OF sysUpTime was reset OR ifCounterDiscontinuityTime OR diffServAlgDropStatus changed. It seems a shame to have to define a new indicator just for these counters - can we get away with a diffServIfDiscontinuityTime for the complete interface or {interface, direction} perhaps? BTW, there is a need, I think, for a "diffserv capabilities" table so it could go in there maybe. > Sorry about the volume of these comments. But if you hadn't > gotten them from me, I'm sure you would have gotten most of > them from Bert's MIB reviewer a few weeks from now. I expect > to send in some comments on the Conceptual Model by the end > of this week. No problem. We needed some fresh reviewing talent, having been immersed in this stuff for so long. > Regards, > Bob Andrew **************************************************************** Andrew Smith tel: +1 (408) 579-2821 Extreme Networks fax: +1 (408) 579-3000 3585 Monroe St. http://www.extremenetworks.com Santa Clara CA 95051-1450 em: andrew@extremenetworks.com **************************************************************** _______________________________________________ diffserv mailing list diffserv@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 May 30 18:13: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 SAA11805 for ; Tue, 30 May 2000 18:13: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 RAA05649; Tue, 30 May 2000 17:50: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 RAA05621 for ; Tue, 30 May 2000 17:50:19 -0400 (EDT) Received: from mail-gw.hursley.ibm.com (mail-gw.hursley.ibm.com [194.196.110.15]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA11253 for ; Tue, 30 May 2000 17:50: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 WAA169064; Tue, 30 May 2000 22:49:48 +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 WAA21720; Tue, 30 May 2000 22:49:45 +0100 (BST) Message-ID: <393436C4.D5A6EA9A@hursley.ibm.com> Date: Tue, 30 May 2000 16:46:44 -0500 From: Brian E Carpenter Organization: IBM X-Mailer: Mozilla 4.61 [en] (Win98; I) X-Accept-Language: en,fr MIME-Version: 1.0 To: Nabil Seddigh CC: Andrew Smith , diffserv@ietf.org Subject: Re: [Diffserv] Diffserv MIB - droppers References: <200005302040.QAA09937@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 I have to say that I still don't understand. I can see how percentiles might be useful (95th percentile of queue length for example) but I don't see what diagnostic information the mean queue length conveys. Brian Nabil Seddigh wrote: > > >Sounds like a circular argument to me - it's useful because > >it's useful. Can you try to be a little more forthcoming > > in your uses? > > > > Circular? I guess I thought the reasons for having > average Q sizes was obvious. My apologies!! > > We have done extensive work with the AF PHB as > incarnated by various MRED schemes: WRED, RIO > & RIO-decoupled. In all cases, access to the queue > averages greatly assisted in trouble shooting and "traffic > engineering". > > Without this information, in many cases we would > have been unable to tell whether end-customer achieved > traffic characteristics was due to faulty configuration or > algorithm specifics. > > Another reason for exporting the avg Q sizes are > the emergence of Diffserv tools for network management. > Offline traffic engineering and SLA tools > require access to algorithm specific information. > For the MRED algorithms, avg Q size is key > to achieved performance - not only delay but > also achieved bandwidth. > > Best, > --- > Nabil Seddigh > nseddigh@nortelnetworks.com > > _______________________________________________ > diffserv mailing list > diffserv@ietf.org > http://www1.ietf.org/mailman/listinfo/diffserv > Archive: http://www-nrg.ee.lbl.gov/diff-serv-arch/ _______________________________________________ diffserv mailing list diffserv@ietf.org http://www1.ietf.org/mailman/listinfo/diffserv Archive: http://www-nrg.ee.lbl.gov/diff-serv-arch/ From diffserv-admin@ietf.org Tue May 30 18:25: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 SAA11973 for ; Tue, 30 May 2000 18:25: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 RAA06039; Tue, 30 May 2000 17:58: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 RAA05934 for ; Tue, 30 May 2000 17:58:42 -0400 (EDT) Received: from sol.extremenetworks.com (sol.extremenetworks.com [216.52.8.2]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA11428 for ; Tue, 30 May 2000 17:58:40 -0400 (EDT) Received: by SOL with Internet Mail Service (5.5.2650.21) id ; Tue, 30 May 2000 14:55:00 -0700 Message-ID: <808F64DDB492D3119D3C00508B5D8D733EC8EE@SOL> From: Andrew Smith To: Nabil Seddigh Cc: diffserv@ietf.org Subject: RE: [Diffserv] Diffserv MIB - droppers Date: Tue, 30 May 2000 14:55: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 I'm still slightly confused as to what is being requested here - is it visibility into the *averaged* queue length or the *instantaneous* queue length? In an earlier message you seemed to be arguing for the latter but here you are arguing for the former. It seems to me that you've got to be particularly careful if you sample on some already-averaged value. Please clarify. Andrew > -----Original Message----- > From: Brian E Carpenter [mailto:brian@hursley.ibm.com] > Sent: Tuesday, May 30, 2000 2:47 PM > To: Nabil Seddigh > Cc: Andrew Smith; diffserv@ietf.org > Subject: Re: [Diffserv] Diffserv MIB - droppers > > > I have to say that I still don't understand. I can see how percentiles > might be useful (95th percentile of queue length for example) > but I don't > see what diagnostic information the mean queue length conveys. > > Brian > > Nabil Seddigh wrote: > > > > >Sounds like a circular argument to me - it's useful because > > >it's useful. Can you try to be a little more forthcoming > > > in your uses? > > > > > > > Circular? I guess I thought the reasons for having > > average Q sizes was obvious. My apologies!! > > > > We have done extensive work with the AF PHB as > > incarnated by various MRED schemes: WRED, RIO > > & RIO-decoupled. In all cases, access to the queue > > averages greatly assisted in trouble shooting and "traffic > > engineering". > > > > Without this information, in many cases we would > > have been unable to tell whether end-customer achieved > > traffic characteristics was due to faulty configuration or > > algorithm specifics. > > > > Another reason for exporting the avg Q sizes are > > the emergence of Diffserv tools for network management. > > Offline traffic engineering and SLA tools > > require access to algorithm specific information. > > For the MRED algorithms, avg Q size is key > > to achieved performance - not only delay but > > also achieved bandwidth. > > > > Best, > > --- > > Nabil Seddigh > > nseddigh@nortelnetworks.com > > > > _______________________________________________ > > diffserv mailing list > > diffserv@ietf.org > > http://www1.ietf.org/mailman/listinfo/diffserv > > Archive: http://www-nrg.ee.lbl.gov/diff-serv-arch/ > _______________________________________________ diffserv mailing list diffserv@ietf.org http://www1.ietf.org/mailman/listinfo/diffserv Archive: http://www-nrg.ee.lbl.gov/diff-serv-arch/ From diffserv-admin@ietf.org Tue May 30 18:27: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 SAA12026 for ; Tue, 30 May 2000 18:27: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 RAA05826; Tue, 30 May 2000 17:53: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 RAA05795 for ; Tue, 30 May 2000 17:53:45 -0400 (EDT) Received: from sol.extremenetworks.com (sol.extremenetworks.com [216.52.8.2]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA11327 for ; Tue, 30 May 2000 17:53:44 -0400 (EDT) Received: by SOL with Internet Mail Service (5.5.2650.21) id ; Tue, 30 May 2000 14:50:04 -0700 Message-ID: <808F64DDB492D3119D3C00508B5D8D733EC8ED@SOL> From: Andrew Smith To: "'bkumar@ennovatenetworks.com'" , diffserv@ietf.org Subject: RE: [Diffserv] Some comments on Diff-Serve Conceptual Model Draf t 3 Date: Tue, 30 May 2000 14:50:02 -0700 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: text/plain; charset="iso-8859-1" Sender: diffserv-admin@ietf.org Errors-To: diffserv-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Diffserv Discussion List X-BeenThere: diffserv@ietf.org Brijesh, On your detailed points 1 and 2 (Brian answered 3 and 4): > -----Original Message----- > From: Brijesh Kumar [mailto:bkumar@ennovatenetworks.com] > Sent: Tuesday, May 30, 2000 12:34 PM > To: diffserv@ietf.org > Subject: [Diffserv] Some comments on Diff-Serve Conceptual > Model Draft 3 ... > > 1. What is an Absolute Dropper? Till recently, I thought a > Dropper was a > Dropper. Either you drop a packet (and free the memory), or > you forward it > and put on the queue. Let us not get into tail drop versus > head drop or > other infinite possible theoretical variations. There is only > one object > called Dropper which may drop as per the algorithm chosen > from the set of > possible N algorithms (tail drop, head drop, ..RED etc.). Maybe you missed the discussion in Adelaide: the consensus there seemed to be to use the terms "absolute dropper" for what you describe above and "algorithmic dropper" for anything that makes a decision based on some sort of external inputs (e.g. a queue length). It's a somewhat arbitrary choice but we need to pick a terminology and this was declared the winner. > 2. Egress and ingress interfaces - despite the number of > pages, the document > doesn't explain the rationale for ingress queueing, and egress based > classifiers and meters? Figure (1 & 2). That is what Fred's material (originally in the MIB draft, now transplanted to the Model section 3.2 because it is generally applicable) is talking about: it explains the requirement to model the same things on ingress as on egress, at least for management purposes. BTW, which pages would you like to see left out? Andrew **************************************************************** Andrew Smith tel: +1 (408) 579-2821 Extreme Networks fax: +1 (408) 579-3000 3585 Monroe St. http://www.extremenetworks.com Santa Clara CA 95051-1450 em: andrew@extremenetworks.com **************************************************************** _______________________________________________ diffserv mailing list diffserv@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 May 30 18:37: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 SAA12178 for ; Tue, 30 May 2000 18:37: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 SAA06626; Tue, 30 May 2000 18:11: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 SAA06594 for ; Tue, 30 May 2000 18:10:57 -0400 (EDT) Received: from rerun.lucentctc.com (rerun.lucentctc.com [199.93.237.2]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA11762 for ; Tue, 30 May 2000 18:10:54 -0400 (EDT) Received: by rerun.lucentctc.com with Internet Mail Service (5.5.2448.0) id ; Tue, 30 May 2000 18:10:24 -0400 Message-ID: <75ADD7496F0BD211ADC000104B8846CF01E861EC@rerun.lucentctc.com> From: "Weiss, Walter" To: Fred Baker , Nabil Seddigh Cc: "Diffserv (E-mail)" Subject: RE: [Diffserv] Diffserv MIB - droppers Date: Tue, 30 May 2000 18:10:23 -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 Fred, I agree that this is a reasonable starting point. regards, -Walter > -----Original Message----- > From: Fred Baker [mailto:fred@cisco.com] > Sent: Friday, May 26, 2000 3:44 PM > To: Nabil Seddigh > Cc: Diffserv (E-mail) > Subject: Re: [Diffserv] Diffserv MIB - droppers > > > At 09:51 PM 5/25/00 -0400, Nabil Seddigh wrote: > >I would suggest that the MIB contain at least the > >3 key parameters traditionally associated with configuring > >RED-93 (minth, maxth and maxp). It would also be good if the > >MIB contained the weight (wq) since it seems to be > >a key parameter in governing RED's performance. [1] > > I'll buy that > > >Instead of 1 set of RED parameters > >per physical queue, we would have 3 sets of parameters > >for queues used for the AF classes > > This needs to be generalized, as AF defines but is not limited to 3 > classes. We need it to be indexed in such a way that it is clear what > parameters apply to which class of traffic. > > > - I thought the MIB already supported this but I haven't > looked at the > > recent versions. [2] > > The most recent version of the MIB leaves this as an open issue. > > >I would suggest that the MIB allows a configurable number of > Qaverages to > >be calculated and returned for monitoring purposes. This > leaves it to the > >vendor to decide which type > >of MRED algorithm to use to achieve AF. [3] > > not sure what you mean by that. If you mean we should externalize the > various means, I'll argue that the information is ephemeral, > and we have > been removing ephemeral information from public MIBs over the > past few > years (and as a design guideline have generally not included > it in the > first place) as its utility was suspect. If you mean that we > should allow > separate averages to be maintained, I don't see anything in having a > configuration block per DSCP per queue, or equivalently per > action that > applies to a queue, to negate that. Unfortunately, though, > the way you > *use* them could be very different. > > For example, Cisco's WRED (one of the MRED's you mention) > uses a single > average, and it is the mean depth of the queue. we start > dropping from a > DSCP when its target queue depth (minth) is less than or > equal to the mean > queue depth associated with it. The effect of usual > configurations is to > drop most to all of AFx3 if we have to drop any of AFx2, and > and most or > all of AFx2 if we have to drop any of AFx1. RIO is another > algorithm, and > keeps a separate mean depth for each DSCP - the number of > packets of that > DSCP in the queue. Depending on how that is configured, it > could keep some > of each DSCP in the queue, or might similarly exhaust one > before dropping > from the next. So you would wind up configuring the thresholds quite > differently. > > SO now the next question might be whether there are > implementations which > use a different number - If you have N DSCPs in the same > queue, do you have > one mean, N means, or some other number? If you have some > other number, > then I submit that the problem gets even more interesting - > how do you > correlate thresholds with averages? Do you want to configure > that as well? > If such exist, that would very much need to reshape our > thinking. But if it > doesn't, then the only question is "do you have one average > or N", and a > vendor could provide instructions for the configuration of > his equipment. > > So I think I am arguing toward min-threshold and > max-threshold, as Kathy > suggested, an exponent to manage the exponential averaging > (minp), and if > you like an upper bound on the drop rate (the weight), and a > counter per > action so that we can measure the effect of the > configuration. I am arguing > to not externalize the current mean depth, as it is > ephemeral, and if we > did, I would argue that we want one mean (an attribute of the > queue) or N > (an attribute of the action, in the same table entry with the > min-threshold > is gets compared to). > > Is that acceptable to you? Does that represent a list consensus? > > > _______________________________________________ > 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 May 30 18:48: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 SAA12362 for ; Tue, 30 May 2000 18:48: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 SAA06909; Tue, 30 May 2000 18:22:39 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id SAA06878 for ; Tue, 30 May 2000 18:22:35 -0400 (EDT) Received: from sol.extremenetworks.com (sol.extremenetworks.com [216.52.8.2]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA11926 for ; Tue, 30 May 2000 18:22:33 -0400 (EDT) Received: by SOL with Internet Mail Service (5.5.2650.21) id ; Tue, 30 May 2000 15:18:54 -0700 Message-ID: <808F64DDB492D3119D3C00508B5D8D733EC8EF@SOL> From: Andrew Smith To: "'bkumar@ennovatenetworks.com'" Cc: diffserv@ietf.org Subject: RE: [Diffserv] Some comments on Diff-Serve Conceptual Model Draf t 3 Date: Tue, 30 May 2000 15:18:51 -0700 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: text/plain; charset="iso-8859-1" Sender: diffserv-admin@ietf.org Errors-To: diffserv-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Diffserv Discussion List X-BeenThere: diffserv@ietf.org Brijesh, Please see below. > -----Original Message----- > From: Brijesh Kumar [mailto:bkumar@ennovatenetworks.com] > Sent: Tuesday, May 30, 2000 2:37 PM > To: 'Brian E Carpenter' > Cc: diffserv@ietf.org > Subject: RE: [Diffserv] Some comments on Diff-Serve Conceptual Model > Draft 3 > > > > In his previous mail, Brian Carpenter writes > > > > > > > 1. What is an Absolute Dropper? Till recently, I thought a > > Dropper was a > > > Dropper. Either you drop a packet (and free the memory), or > > you forward it > > > and put on the queue. Let us not get into tail drop versus > > head drop or > > > other infinite possible theoretical variations. There is > > only one object > > > called Dropper which may drop as per the algorithm chosen > > from the set of > > > possible N algorithms (tail drop, head drop, ..RED etc.). > > > > Linguistically I tend to agree. > Brian, > > I am glad that you agree. I hope the authors will re-consider > their use of > multiple Dropper objects (Absolute and Algorithmic) which, I think, is > unnecessary. I, for one, am reluctant to re-open that discussion. This was one of the (few) items that we closed in Adelaide. ... > > > > 3. Classifiers > > > > > > "Note that we allow a multiplexer before the classifier > > (see section 6.5 ..) > > > ...." The section 5. Well, it's not the question of this > > document allowing > > > or disallowing, that is the way many (software) > > implementations that have a > > > centralized routing for merged traffic streams will > > implement. Therefore, a > > > classifier can be visualized either as a 1 to N mapping, or > > a M to N mapping > > > of traffic streams. In reality, multiplexing is a result of > > an action (i.e., > > > common ingress queueing) as all incoming traffic is written > > to a single > > > classifier input queue. The similar arguments apply to a > > (conceptual) > > > multiplexer preceding a meter. > > > > Are you proposing a document change? > > I hope the authors will consider it. Let us see your proposed changes and of course we will consider them. > > > 4. Counting doesn't seem to be a valid action - it is kind > > of useless to say > > > that if the traffic stream meets this criteria, then count, > > or if it doesn't > > > meet this criteria then don't count. Gathering traffic > > statistics, is > > > auto-magically implied in any network switch with or > > without Diff-Serv. > > > > This is included as a basis for the corresponding MIB variables. > > What I wanted to convey that the existence of a count action object by > itself is meaningless. In a Diff-Serv context, an action will > always be > "Count and Drop" or "Count and Forward" combination (i.e., > (1) Drop with > Count or (2) Forward with Count). It is not clear to me whether you are suggesting that we (a) do not include any counters in this management model, (b) we rename them from "count actions" to something without the word action in the name or (c) we define a new element called a "forwarder" just so that we can have some counters in it. Up to now, the consensus has been that it is useful to include counters explicitly. I assume that the 3 other co-authors also believe so. > Cheers, > > --brijesh > Ennovate Networks Inc., 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 Tue May 30 18:49: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 SAA12385 for ; Tue, 30 May 2000 18:49: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 SAA07096; Tue, 30 May 2000 18:28: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 SAA07068 for ; Tue, 30 May 2000 18:28: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 SAA12038 for ; Tue, 30 May 2000 18:27:59 -0400 (EDT) Received: from zubin.dnrc.bell-labs.com ([135.180.130.56]) by crufty; Tue May 30 18:27:52 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 SAA05208; Tue, 30 May 2000 18:27:43 -0400 (EDT) Message-ID: <3934412C.CDEAC84B@dnrc.bell-labs.com> Date: Tue, 30 May 2000 15:31:08 -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: Andrew Smith CC: diffserv@ietf.org Subject: Re: [Diffserv] Some comments on Diff-Serve Conceptual Model Draft 3 References: <808F64DDB492D3119D3C00508B5D8D733EC8ED@SOL> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: diffserv-admin@ietf.org Errors-To: diffserv-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Diffserv Discussion List X-BeenThere: diffserv@ietf.org Content-Transfer-Encoding: 7bit Andrew Smith wrote: [..] > Maybe you missed the discussion in Adelaide: the consensus there seemed to > be to use the terms "absolute dropper" for what you describe above and > "algorithmic dropper" for anything that makes a decision based on some sort > of external inputs (e.g. a queue length). It's a somewhat arbitrary choice > but we need to pick a terminology and this was declared the winner. Now I'm a little confused. I thought a dropper always derived its drop/no-drop decision based on additional inputs (e.g. a queue length or metering stage output). Not that I'm particularly opposed to having two types of 'dropper', just curious if there's any better phrasing that would avoid this discussion recurring after the I-D becomes an RFC. (Somehow show that an 'absolute' dropper isn't simply a particular instance of an 'algorithmic' dropper.) 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 Tue May 30 18:56: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 SAA12496 for ; Tue, 30 May 2000 18:56: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 SAA07496; Tue, 30 May 2000 18: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 SAA07463 for ; Tue, 30 May 2000 18:38:33 -0400 (EDT) Received: from sol.extremenetworks.com (sol.extremenetworks.com [216.52.8.2]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA12214 for ; Tue, 30 May 2000 18:38:30 -0400 (EDT) Received: by SOL with Internet Mail Service (5.5.2650.21) id ; Tue, 30 May 2000 15:34:48 -0700 Message-ID: <808F64DDB492D3119D3C00508B5D8D733EC8F0@SOL> From: Andrew Smith To: "'Grenville Armitage'" Cc: diffserv@ietf.org Subject: RE: [Diffserv] Some comments on Diff-Serve Conceptual Model Draf t 3 Date: Tue, 30 May 2000 15:34:47 -0700 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: text/plain; charset="iso-8859-1" Sender: diffserv-admin@ietf.org Errors-To: diffserv-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Diffserv Discussion List X-BeenThere: diffserv@ietf.org I think it is well enough described in the Conceptual Model draft. Should we maybe place it in UPPERCASE PRINT (or even in upside-down print since we agreed it dahn-unda)? Seriously though, we could make the definitions more prominent by placing them in the Glossary section up front. I really don't think any more radical restructuring than that is needed. Andrew P.S. I need one of those quote-of-the-day things that comes up with some deep and meaningful philosophy from Marx or Confucius about all taxonomies and glossaries being arbitrary - but that that does not matter as long as everyone uses the same ones. > -----Original Message----- > From: Grenville Armitage [mailto:gja@dnrc.bell-labs.com] > Sent: Tuesday, May 30, 2000 3:31 PM > To: Andrew Smith > Cc: diffserv@ietf.org > Subject: Re: [Diffserv] Some comments on Diff-Serve Conceptual Model > Draft 3 > > > > > Andrew Smith wrote: > [..] > > Maybe you missed the discussion in Adelaide: the consensus > there seemed to > > be to use the terms "absolute dropper" for what you > describe above and > > "algorithmic dropper" for anything that makes a decision > based on some sort > > of external inputs (e.g. a queue length). It's a somewhat > arbitrary choice > > but we need to pick a terminology and this was declared the winner. > > Now I'm a little confused. I thought a dropper always derived its > drop/no-drop decision based on additional inputs (e.g. a queue length > or metering stage output). Not that I'm particularly opposed to having > two types of 'dropper', just curious if there's any better > phrasing that > would avoid this discussion recurring after the I-D becomes an RFC. > (Somehow show that an 'absolute' dropper isn't simply a particular > instance of an 'algorithmic' dropper.) > > 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 Tue May 30 19:46: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 TAA13193 for ; Tue, 30 May 2000 19:46: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 TAA08271; Tue, 30 May 2000 19:20: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 TAA08238 for ; Tue, 30 May 2000 19:20: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 TAA12818 for ; Tue, 30 May 2000 19:19:58 -0400 (EDT) Received: from zubin.dnrc.bell-labs.com ([135.180.130.56]) by dirty; Tue May 30 19:18:46 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 TAA05624; Tue, 30 May 2000 19:18:57 -0400 (EDT) Message-ID: <39344D2C.22B4BFD3@dnrc.bell-labs.com> Date: Tue, 30 May 2000 16:22:20 -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: Andrew Smith CC: diffserv@ietf.org Subject: Re: [Diffserv] Some comments on Diff-Serve Conceptual Model Draft 3 References: <808F64DDB492D3119D3C00508B5D8D733EC8F0@SOL> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: diffserv-admin@ietf.org Errors-To: diffserv-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Diffserv Discussion List X-BeenThere: diffserv@ietf.org Content-Transfer-Encoding: 7bit Consistency is one thing, conciseness is another. I'm suggesting that the Absolute dropper is merely an instance of an Algorithmic dropper (with an algorithm of 'always drop'). Other readers are going to notice (or believe they've noticed) the same thing, and wonder why 'we' created two different names. To forestall confusion, yes you probably ought to define the two terms (and their differences) at the front of the document. cheers, gja Andrew Smith wrote: > > I think it is well enough described in the Conceptual Model draft. Should we > maybe place it in UPPERCASE PRINT (or even in upside-down print since we > agreed it dahn-unda)? Seriously though, we could make the definitions more > prominent by placing them in the Glossary section up front. I really don't > think any more radical restructuring than that is needed. > > Andrew > > P.S. I need one of those quote-of-the-day things that comes up with some > deep and meaningful philosophy from Marx or Confucius about all taxonomies > and glossaries being arbitrary - but that that does not matter as long as > everyone uses the same ones. > > > -----Original Message----- > > From: Grenville Armitage [mailto:gja@dnrc.bell-labs.com] > > Sent: Tuesday, May 30, 2000 3:31 PM > > To: Andrew Smith > > Cc: diffserv@ietf.org > > Subject: Re: [Diffserv] Some comments on Diff-Serve Conceptual Model > > Draft 3 > > > > > > > > > > Andrew Smith wrote: > > [..] > > > Maybe you missed the discussion in Adelaide: the consensus > > there seemed to > > > be to use the terms "absolute dropper" for what you > > describe above and > > > "algorithmic dropper" for anything that makes a decision > > based on some sort > > > of external inputs (e.g. a queue length). It's a somewhat > > arbitrary choice > > > but we need to pick a terminology and this was declared the winner. > > > > Now I'm a little confused. I thought a dropper always derived its > > drop/no-drop decision based on additional inputs (e.g. a queue length > > or metering stage output). Not that I'm particularly opposed to having > > two types of 'dropper', just curious if there's any better > > phrasing that > > would avoid this discussion recurring after the I-D becomes an RFC. > > (Somehow show that an 'absolute' dropper isn't simply a particular > > instance of an 'algorithmic' dropper.) > > > > 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/ -- ________________________________________________________________________ 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 May 30 20:05: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 UAA13479 for ; Tue, 30 May 2000 20:05: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 TAA08379; Tue, 30 May 2000 19:26: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 TAA08348 for ; Tue, 30 May 2000 19:26:34 -0400 (EDT) Received: from sol.extremenetworks.com (sol.extremenetworks.com [216.52.8.2]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA12889 for ; Tue, 30 May 2000 19:26:31 -0400 (EDT) Received: by SOL with Internet Mail Service (5.5.2650.21) id ; Tue, 30 May 2000 16:22:52 -0700 Message-ID: <808F64DDB492D3119D3C00508B5D8D733EC8F2@SOL> From: Andrew Smith To: "'Grenville Armitage'" Cc: diffserv@ietf.org Subject: RE: [Diffserv] Some comments on Diff-Serve Conceptual Model Draf t 3 Date: Tue, 30 May 2000 16:22: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 "Absolute A functional datapath element which simply discards all Dropper packets arriving at its input. Algorithmic A functional datapath element which selectively discards Dropper packets that arrive at its input, based on a discarding algorithm. It has one data input and one output." Their different plumbing is the primary reason for treating them differently. This draft is for building plumbing diagrams. Andrew > -----Original Message----- > From: Grenville Armitage [mailto:gja@dnrc.bell-labs.com] > Sent: Tuesday, May 30, 2000 4:22 PM > To: Andrew Smith > Cc: diffserv@ietf.org > Subject: Re: [Diffserv] Some comments on Diff-Serve Conceptual Model > Draft 3 > > > > Consistency is one thing, conciseness is another. I'm suggesting > that the Absolute dropper is merely an instance of an Algorithmic > dropper (with an algorithm of 'always drop'). Other readers are going > to notice (or believe they've noticed) the same thing, and wonder why > 'we' created two different names. To forestall confusion, yes you > probably ought to define the two terms (and their differences) at > the front of the document. > > cheers, > gja > > Andrew Smith wrote: > > > > I think it is well enough described in the Conceptual Model > draft. Should we > > maybe place it in UPPERCASE PRINT (or even in upside-down > print since we > > agreed it dahn-unda)? Seriously though, we could make the > definitions more > > prominent by placing them in the Glossary section up front. > I really don't > > think any more radical restructuring than that is needed. > > > > Andrew > > > > P.S. I need one of those quote-of-the-day things that comes > up with some > > deep and meaningful philosophy from Marx or Confucius about > all taxonomies > > and glossaries being arbitrary - but that that does not > matter as long as > > everyone uses the same ones. > > > > > -----Original Message----- > > > From: Grenville Armitage [mailto:gja@dnrc.bell-labs.com] > > > Sent: Tuesday, May 30, 2000 3:31 PM > > > To: Andrew Smith > > > Cc: diffserv@ietf.org > > > Subject: Re: [Diffserv] Some comments on Diff-Serve > Conceptual Model > > > Draft 3 > > > > > > > > > > > > > > > Andrew Smith wrote: > > > [..] > > > > Maybe you missed the discussion in Adelaide: the consensus > > > there seemed to > > > > be to use the terms "absolute dropper" for what you > > > describe above and > > > > "algorithmic dropper" for anything that makes a decision > > > based on some sort > > > > of external inputs (e.g. a queue length). It's a somewhat > > > arbitrary choice > > > > but we need to pick a terminology and this was declared > the winner. > > > > > > Now I'm a little confused. I thought a dropper always derived its > > > drop/no-drop decision based on additional inputs (e.g. a > queue length > > > or metering stage output). Not that I'm particularly > opposed to having > > > two types of 'dropper', just curious if there's any better > > > phrasing that > > > would avoid this discussion recurring after the I-D > becomes an RFC. > > > (Somehow show that an 'absolute' dropper isn't simply a particular > > > instance of an 'algorithmic' dropper.) > > > > > > 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/ > > -- > ______________________________________________________________ > __________ > 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 May 30 20:15: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 UAA13577 for ; Tue, 30 May 2000 20:15: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 TAA08787; Tue, 30 May 2000 19:44: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 TAA08761 for ; Tue, 30 May 2000 19:44:25 -0400 (EDT) Received: from prue.eim.surrey.ac.uk (IDENT:exim@[131.227.76.5]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA13184 for ; Tue, 30 May 2000 19:44:20 -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 12wvgB-0005PO-00; Wed, 31 May 2000 00:44:11 +0100 Date: Wed, 31 May 2000 00:43:53 +0100 (BST) From: Lloyd Wood X-Sender: eep1lw@petra.ee.surrey.ac.uk Reply-To: L.Wood@eim.surrey.ac.uk To: Andrew Smith cc: "'Grenville Armitage'" , diffserv@ietf.org Subject: RE: [Diffserv] Some comments on Diff-Serve Conceptual Model Draf t 3 In-Reply-To: <808F64DDB492D3119D3C00508B5D8D733EC8F2@SOL> 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, 30 May 2000, Andrew Smith wrote: > "Absolute A functional datapath element which simply discards all > Dropper packets arriving at its input. functional? I prefer 'dysfunctional'. L. prefers 'uncontrolled dropper' and 'controlled dropper' for these, too. 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 May 30 20: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 UAA13763 for ; Tue, 30 May 2000 20: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 UAA08987; Tue, 30 May 2000 20:00: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 UAA08953 for ; Tue, 30 May 2000 20:00:01 -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 UAA13361 for ; Tue, 30 May 2000 20:00:00 -0400 (EDT) Received: from zubin.dnrc.bell-labs.com ([135.180.130.56]) by dirty; Tue May 30 19:59: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 UAA06003; Tue, 30 May 2000 20:00:01 -0400 (EDT) Message-ID: <393456CC.CEC57D5@dnrc.bell-labs.com> Date: Tue, 30 May 2000 17:03:24 -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: Andrew Smith CC: diffserv@ietf.org Subject: Re: [Diffserv] Some comments on Diff-Serve Conceptual Model Draft 3 References: <808F64DDB492D3119D3C00508B5D8D733EC8F2@SOL> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: diffserv-admin@ietf.org Errors-To: diffserv-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Diffserv Discussion List X-BeenThere: diffserv@ietf.org Content-Transfer-Encoding: 7bit Andrew Smith wrote: > > "Absolute A functional datapath element which simply discards all > Dropper packets arriving at its input. > > Algorithmic A functional datapath element which selectively discards > Dropper packets that arrive at its input, based on a discarding > algorithm. It has one data input and one output." Perhaps I'm being dense, but wouldn't the Algorithmic dropper be better described as having *two* inputs - one data, and one control? (the control input being the external variable(s) upon which the algorithm makes the drop decision) > Their different plumbing is the primary reason for treating them > differently. This draft is for building plumbing diagrams. Understand the desire to build plumbing diagrams - guess I'd just prefer there to be less 'functional elements' if it is possible to use parameters to control functional elements. Yes, I should have been more awake during the preceding discussions on this topic :) cheers, gja p.s. but if there's any chance to revisit it - how about: DROP(F) is a functional datapath element that discards packets arriving at its input if F==1, otherwise passes packets through if F==0. An 'absolute dropper' would be just DROP(1), an algorithmic RED dropper on queue X could be expressed as DROP(RED(X)), etc.... _______________________________________________ diffserv mailing list diffserv@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 May 30 21:36: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 VAA14391 for ; Tue, 30 May 2000 21:36: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 VAA10070; Tue, 30 May 2000 21:09: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 VAA09968 for ; Tue, 30 May 2000 21:09:01 -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 VAA14167 for ; Tue, 30 May 2000 21:08:59 -0400 (EDT) From: fred@cisco.com Received: from irp-view7.cisco.com (irp-view7.cisco.com [171.69.63.148]) by sj-msg-core-1.cisco.com (8.9.3/8.9.1) with ESMTP id SAA01019 for ; Tue, 30 May 2000 18:08:40 -0700 (PDT) Received: (fred@localhost) by irp-view7.cisco.com (8.8.8-Cisco List Logging/CISCO.WS.1.2) id SAA09049 for diffserv@ietf.org; Tue, 30 May 2000 18:08:30 -0700 (PDT) Date: Tue, 30 May 2000 18:08:30 -0700 (PDT) Message-Id: <200005310108.SAA09049@irp-view7.cisco.com> To: diffserv@ietf.org Subject: [Diffserv] Proposal for Diffserv MIB - droppers Sender: diffserv-admin@ietf.org Errors-To: diffserv-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Diffserv Discussion List X-BeenThere: diffserv@ietf.org OK, I have a proposed set of changes to the MIB. I extracted the text blobs that have something to do with Algorithmic Droppers and built some text about random droppers based on them. I assume that Andrew (who last held the pen) can do the right thing with the text once we agree with it. This re-uses the Algorithmic Drop Table in the way Andrew intended (I think, and if it didn't, sorry, it intended to, so he can tell us how to fix it). It does not include the queue depth (average or actual) as I'm not convinced and I personally don't see consensus at this point towards including it. First, I want to change the following paragraph in this way: o Random Droppers are recommended as a way to control congestion, in > [RFC 2309], and called for in the [RFC 2597]. Various implementations > exist, which agree on marking or dropping just enough traffic to > communicate with TCP-like protocols about congestion avoidance, but > differ markedly on their specific parameters. This MIB attempts to > offer a minimal set of controls and reports to control any random > dropper, but expects that vendors will augment the table with > additional controls in accordance with their implementation. remove this paragraph: ------------------------------------- One way to extend this MIB structure to accomodate a more complex dropping algorithm might be to define a specific dropper table in another MIB module, pointed at by diffServAlgDropSpecific, containing its own parameters, as shown in figure 2. This algorithm might depend for its operation e.g. on feedback of a queue's depth but pre-processed by some type of smoothing function with its own parameters. The extended table could still use some of the fields of the standard Algorithmic Dropper Table, if relevant, although any divergent uses would have to be well-documented in the extended MIB. Remove the last sentence from this paragraph, regarding RED. <(13) Droppers: we used to have a common "dropper" table that represented < all of: dropAlways, randomDrop, tailDrop with just some parameters < valid for the simpler ones. A simpler representation is to define < specific dropper tables for each type (e.g. a single OID to point < at for dropAlways since it is always the last action in a chain) < but this would mean a larger number of (simpler) MIB objects. < CHANGES: dropAlways is still an Action but the others are moved to < a diffServAlgDropTable. This table can handle tail/head drop. Other < algorithms, specifically RED, are out of scope for now but can be < added using the framework defined here. decision reached on the list: apparently we do need this option. <(21) Do we need diffServAlgDropType of both "headDrop" and "tailDrop" or < should we just represent the tail dropper by placing a dropper < after the queue instead of before the queue, as linked by the < diffServQNext and diffServAlgDropNext RowPointers? (the former). Remove this paragraph from the diffServAlgDropEntry description: < Specifically, Random Drop algorithms are not directly represented < in this MIB but can be indicated by an entry in this table with < diffServRandomDropType of other(1) and extensions, pointed to by < diffServRandomDropSpecific, in some other MIB module that parallels < entries in this table e.g. by using the same index attribute(s)." Add this text to diffServAlgDropType: diffServRandomDropType OBJECT-TYPE SYNTAX INTEGER { other(1), tailDrop(2), headDrop(3), > randomDrop(4) } MAX-ACCESS read-create STATUS current DESCRIPTION "The type of algorithm used by this dropper. A value of tailDrop(2) or headDrop(3) represents an algorithm that is completely specified by this MIB. A value of other(1) requires further specification in some other MIB module. The tailDrop(2) algorithm is described as follows: diffServRandomDropQThreshold represents the depth of the queue diffServRandomDropQMeasure at which all newly arriving packets will be dropped. The headDrop(3) algorithm is described as follows: if a packet arrives when the current depth of the queue diffServRandomDropQMeasure is at diffServRandomDropQThreshold, the packet currently at the head of the queue is dropped and the new packet is enqueued at the tail of the queue. > The randomDrop algorithm is described as follows: on packet > arrival, an algorithm is executed which may randomly drop it, or > drop another packet from the queue in its place. The specifics > of the algorithm may be proprietary. In this case, a > diffServRandomDropEntry is pointed to by diffServAlgDropSpecific, > diffServAlgQThreshold is understood to be the absolute maximum > size of the queue, and additional parameters beyond those in the > diffServRandomDropTable may be found in a vendor-specific MIB." ::= { diffServRandomDropEntry 3 } New Text: diffServRandomDropTable OBJECT-TYPE SYNTAX SEQUENCE OF DiffServRandomDropEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "The random drop table augments the algorithmic drop table. It contains entries describing a process that drops packets randomly. It is pointed to by diffServAlgDropSpecific in such cases." REFERENCE "[MODEL] section 7.1.3" ::= { diffServTables ? } Just a thought: this could literally AUGMENT {diffServTables 8} using the Augments clause if we want it to. Not sure what anyone thinks. diffServRandomDropEntry OBJECT-TYPE SYNTAX DiffServRandomDropEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "An entry describes a process that drops packets according to a random Algorithm." INDEX { ifIndex, diffServAlgDropIfDirection, diffServAlgDropId } ::= { diffServRandomDropTable 1 } DiffServRandomDropEntry ::= SEQUENCE { diffServRandomDropMinThreshold Unsigned32, diffServRandomDropMaxThreshold Unsigned32, diffServRandomDropAvgInterval Unsigned32, diffServRandomDropMinSpace Unsigned32, diffServRandomDropStatus RowStatus } diffServRandomDropMinThreshold OBJECT-TYPE SYNTAX Unsigned32 UNITS "packets" MAX-ACCESS read-create STATUS current DESCRIPTION "The target number of packets to be held in queue. If the average queue depth exceeds this amount, one will expect that traffic exercising this action (which is to say, traffic which either has the indicated DSCP or which will be marked to it as the result of a meter overflowing) has a non-zero probability of being dropped or marked." ::= { diffServRandomDropEntry 1 } diffServRandomDropMaxThreshold OBJECT-TYPE SYNTAX Unsigned32 UNITS "packets" MAX-ACCESS read-create STATUS current DESCRIPTION "The limit number of packets to be held in queue. If the average queue depth exceeds this amount, one one may presume that randomly dropping or marking them has not been successful in reducing the source's rate, and these packets must be dropped." ::= { diffServRandomDropEntry 2 } -- -- this can be done in many ways. One could, for example, maintain an -- exponentially weighted moving average and put the binary logarithm -- ("k" in 2^k) here, which is what Cisco equipment does. I get lots of -- questions of the form "what is this 'k' thingie for?", and Cisco -- originally refused to put an equation into the manual, claiming that -- this was difficult for customers (read "English majors working in -- tech pubs") to understand. Since Kathy seems to think that an interval -- of milliseconds is about right, I propose we go with that... diffServRandomDropAvgInterval OBJECT-TYPE SYNTAX Unsigned32 UNITS "milliseconds" MAX-ACCESS read-create STATUS current DESCRIPTION "The number of milliseconds between calculations of the required drop rate, in milliseconds. Presumptively, every so often the drop rate is calibrated, either increasing it due to increased mean queue depth, or decreasing it because previous drops have had the necessary effect." ::= { diffServRandomDropEntry 3 } diffServRandomDropMinSpace OBJECT-TYPE SYNTAX Unsigned32 MAX-ACCESS read-create STATUS current DESCRIPTION "The minimum number of packets that must be forwarded between successive marking or dropping events. The number zero implies that all packets are subject to drop; the number 99 indicates that at most 1% of packets may be dropped, as between any two packets there must be at least 99 packets forwarded. This has the effect of limiting the percentage drop rate to some bound." ::= { diffServRandomDropEntry 4 } diffServRandomDropStatus OBJECT-TYPE SYNTAX RowStatus MAX-ACCESS read-create STATUS current DESCRIPTION "The RowStatus variable controls the activation, deactivation, or deletion of this entry. Any writable variable may be modified whether the row is active or notInService." ::= { diffServRandomDropEntry 12 } diffServMIBCompliance MODULE-COMPLIANCE ... MANDATORY-GROUPS { diffServMIBClassifierGroup, diffServMIBSixTupleClfrGroup, > diffServMIBActionGroup, diffServMIBRandomDropGroup, diffServMIBAlgDropGroup, diffServMIBQueueGroup, diffServMIBSchedulerGroup } OBJECT diffServRandomDropMinThreshold MIN-ACCESS read-only DESCRIPTION "Write access is not required." OBJECT diffServRandomDropMaxThreshold MIN-ACCESS read-only DESCRIPTION "Write access is not required." OBJECT diffServRandomDropAvgInterval MIN-ACCESS read-only DESCRIPTION "Write access is not required." OBJECT diffServRandomDropMinSpace MIN-ACCESS read-only DESCRIPTION "Write access is not required." OBJECT diffServRandomDropStatus MIN-ACCESS read-only DESCRIPTION "Write access is not required." diffServMIBRandomDropGroup OBJECT-GROUP OBJECTS { diffServRandomDropMinThreshold, diffServRandomDropMaxThreshold, diffServRandomDropAvgInterval, diffServRandomDropMinSpace, diffServRandomDropStatus } STATUS current DESCRIPTION "The Random Drop Group augments the Algorithmic Drop Group for random dropper operation and configuration." ::= { diffServMIBGroups ? } At the end of the document, we need an appropriate reference to RED93, and probably some subset of the papers that proceed from it. _______________________________________________ diffserv mailing list diffserv@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 May 31 00:18: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 AAA17945 for ; Wed, 31 May 2000 00:18: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 XAA11452; Tue, 30 May 2000 23:49: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 XAA11421 for ; Tue, 30 May 2000 23:49:10 -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 XAA17593 for ; Tue, 30 May 2000 23:49:09 -0400 (EDT) Received: (cpmta 18108 invoked from network); 30 May 2000 20:48:40 -0700 Received: from sj-isp-nat-pool-2.cisco.com (HELO packetdesign.com) (204.69.198.2) by smtp.packetdesign.com with SMTP; 30 May 2000 20:48:40 -0700 X-Sent: 31 May 2000 03:48:40 GMT Message-ID: <39348B7F.A3B63722@packetdesign.com> Date: Tue, 30 May 2000 20:48:15 -0700 From: Kathleen Nichols X-Mailer: Mozilla 4.7 [en] (Win98; U) X-Accept-Language: en MIME-Version: 1.0 To: diffserv@ietf.org Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Subject: [Diffserv] Comments on draft-bonaventure-diffserv-rashaper-02.txt solicited Sender: diffserv-admin@ietf.org Errors-To: diffserv-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Diffserv Discussion List X-BeenThere: diffserv@ietf.org Content-Transfer-Encoding: 7bit diffservers, Although draft-bonaventure-diffserv-rashaper-02.txt is not an official WG document, it concerns a diffserv WG topic, a traffic conditioner. The authors are interested in having this draft become an experimental RFC and thoughtful comments from diffservers would be helpful. thanks, Kathie and Brian diffserv WG co-chairs _______________________________________________ diffserv mailing list diffserv@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 May 31 04:55: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 EAA01830 for ; Wed, 31 May 2000 04:55: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 EAA19335; Wed, 31 May 2000 04:19: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 EAA19304 for ; Wed, 31 May 2000 04:19: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 EAA01630 for ; Wed, 31 May 2000 04:19: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 e4V8IYr18308; Wed, 31 May 2000 10:18:34 +0200 (MET DST) Received: from alcatel.be (btm41q [138.203.66.43]) by btmq9s.rc.bel.alcatel.be (8.8.8+Sun/8.8.8/1.1) with ESMTP id KAA16685; Wed, 31 May 2000 10:18:34 +0200 (MET DST) Message-ID: <3934CAD0.644F575@alcatel.be> Date: Wed, 31 May 2000 10:18:24 +0200 From: Stefaan De Cnodder Organization: Alcatel X-Mailer: Mozilla 4.61 [en] (WinNT; I) X-Accept-Language: en MIME-Version: 1.0 To: diffserv@ietf.org CC: Kathleen Nichols Subject: Re: [Diffserv] Comments on draft-bonaventure-diffserv-rashaper-02.txt solicited References: <39348B7F.A3B63722@packetdesign.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 In the meanwhile, a paper has been published about the traffic conditioner described in draft-bonaventure-diffserv-rashaper-02.txt at the Networld+Interop engineers conference in Las Vegas (May 2000). People interested in this paper can sent me an email such that I can sent you an electronic version of the paper. To rectify, we are moving this draft to become an informational RFC rather than experimental as stated below. Stefaan Kathleen Nichols wrote: > > diffservers, > > Although draft-bonaventure-diffserv-rashaper-02.txt is not > an official WG document, it concerns a diffserv WG topic, > a traffic conditioner. The authors are interested in having > this draft become an experimental RFC and thoughtful comments > from diffservers would be helpful. > > thanks, > Kathie and Brian > diffserv WG co-chairs > > _______________________________________________ > 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 May 31 08:23:43 2000 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA06147 for ; Wed, 31 May 2000 08:23:42 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id IAA21680; Wed, 31 May 2000 08: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 IAA21647 for ; Wed, 31 May 2000 08:02:02 -0400 (EDT) Received: from cyberus.ca (mail.cyberus.ca [209.195.95.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA05487 for ; Wed, 31 May 2000 08:02:00 -0400 (EDT) Received: from shell.cyberus.ca (shell [209.195.95.7]) by cyberus.ca (8.9.3/8.9.3/Cyberus Online Inc.) with ESMTP id HAA13470; Wed, 31 May 2000 07:59:56 -0400 (EDT) Received: from localhost (hadi@localhost) by shell.cyberus.ca (8.9.1b+Sun/8.9.3) with ESMTP id HAA08441; Wed, 31 May 2000 07:59:55 -0400 (EDT) Date: Wed, 31 May 2000 07:59:55 -0400 (EDT) From: jamal To: Brian E Carpenter cc: diffserv@ietf.org, fred@cisco.com, nseddigh@nortelnetworks.com, khchan@nortelnetworks.com Subject: Re: [Diffserv] Diffserv MIB - droppers In-Reply-To: <3933BF09.4E60BB86@hursley.ibm.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: diffserv-admin@ietf.org Errors-To: diffserv-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Diffserv Discussion List X-BeenThere: diffserv@ietf.org On Tue, 30 May 2000, Brian E Carpenter wrote: > Jamal, > > So what MIB parameters do you think are necessary for a RED dropper? > For each of the MRED algorithms you need to be able to: A) select it (among a set of such algorithms. In our case We have two: GRED and GRIO and a small variation of the first one.) B) Configure the associated FIFO with limits which are defined by either packet or byte counting (in our case we only do byte counting) C) Select the number of "virtual Queues" within the physical queue. (This is mostly for flexibility. In the case of AF one can assume 3 virtual queueus within a physical queue). For example if you have one virtual queue within the physical queue, it reduces to the simple case of classical RED. If you have two virtual queues within a physical queue and have select the GRIO mode then it reduces to RIO with the IN/OUT defining the virtual queues. We have limited to 16 virtual queues, but your mileage may vary. C) above is implementation specific whereas A) and B) are what i would consider to be available generally. For each of the above you need to configure the virtual queue parameters; There is no way around this, unless you start making more specific assumptions. Each of these virtual queues in some cases could be "a little RED" in itself. We have made it generic such that you can couple the relationship between the virtual queues or leave them independent of each other (since we wanted to have the flexibility of service setup). The coupling is controlled by a parameter we define as "prio" (expndable to priority). You can think of this as the reverse of precedence in CISCOs WRED. The virtual queue parameters also include: 0) a virtual queue identifier/selector 1) physical limit (again byte or packet counting) 2) min avg threshold 3) max avg threshold 4) defining the moving window queue weight, W. In our case to make it intuitive we select to use the number of packets allowed to burst as the parameter to set because it is more intuitive. This is based on the 93 paper which limits the lower limit of W burst + 1 - qmin/avpkt < (1-(1-W)^burst)/W 5) The drop probability 6) "avpkt" the average packet size in bytes foreseen 7) "bandwidth" the wire-speed of the interface being configured. 6) and 7) are implementation specific. 4) is needed but could be described in a multitude of ways (eg CISCO-WRED with the "n" parameter, and some folks who use floating point who might want to describe it as floating point number with information regarding the mantissa and exponent). We configure things in two steps; first the shared MRED parameters A)-C) then followed by the virtual queue specifics (0-7). However, since we have selectors in both A) and 0) things can be configured in one step using the selectors/identifiers. In case all that is still note clear here is an example of the policy set (which could be done using an SNMP MIB ). This is an example with virtual queue coupling for AF1*. ---------------------------------------- # select GRIO mode with 3 virtual queues with virtual queue 2 as the default configure gred setup DPs 3 default 2 grio # --- AF Class 1 DP/VQ 1 min/max 15KB/45KB etc --- configure 1 gred DP 1 limit 60KB min 15KB max 45KB burst 20 avpkt 1000 \ bandwidth 10Mbit probability 0.02 prio 2 # --- AF Class 1 DP 2--- configure gred limit 60KB min 15KB max 45KB burst 20 avpkt 1000 \ bandwidth 10Mbit DP 2 probability 0.04 prio 3 # --- AF Class 1 DP 3--- configure gred limit 60KB min 15KB max 45KB burst 20 avpkt 1000 \ bandwidth 10Mbit DP 3 probability 0.06 prio 4 -------------------------------------- All the above settable parameters are retrievable in addition to the current values that dynamically change +per AF Class paramter values: (Physical queue limit, total packets/bytes, the amount out of the total that have been dropped) +per virtual queue dynamic values: -the current virtual queue size -the physical queue. -total packets/bytes, the amount out of the total that have been dropped) If i could rant for a sec: Unfortunately most people on the list seem to be preaching their own version of the truth (based on some specific implementation). You need to get away from that. It is sad to see that the compromise seems to be heading towards a really silly direction of "lets leave RED out of this". I suggest maybe you need a bakeoff of some sort before you close this document. Keep this document open! cheers, jamal _______________________________________________ diffserv mailing list diffserv@ietf.org http://www1.ietf.org/mailman/listinfo/diffserv Archive: http://www-nrg.ee.lbl.gov/diff-serv-arch/ From diffserv-admin@ietf.org Wed May 31 08:52: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 IAA07232 for ; Wed, 31 May 2000 08:52: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 IAA22169; Wed, 31 May 2000 08:30: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 IAA22139 for ; Wed, 31 May 2000 08:30:28 -0400 (EDT) Received: from cyberus.ca (mail.cyberus.ca [209.195.95.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA06380 for ; Wed, 31 May 2000 08:30:27 -0400 (EDT) Received: from shell.cyberus.ca (shell [209.195.95.7]) by cyberus.ca (8.9.3/8.9.3/Cyberus Online Inc.) with ESMTP id IAA23637; Wed, 31 May 2000 08:30:27 -0400 (EDT) Received: from localhost (hadi@localhost) by shell.cyberus.ca (8.9.1b+Sun/8.9.3) with ESMTP id IAA08465; Wed, 31 May 2000 08:30:27 -0400 (EDT) Date: Wed, 31 May 2000 08:30:27 -0400 (EDT) From: jamal To: Andrew Smith cc: diffserv@ietf.org Subject: RE: [Diffserv] Comment on model draft-03 In-Reply-To: <808F64DDB492D3119D3C00508B5D8D7302DF8680@SOL> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: diffserv-admin@ietf.org Errors-To: diffserv-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Diffserv Discussion List X-BeenThere: diffserv@ietf.org On Tue, 30 May 2000, Andrew Smith wrote: > See below. > > > -----Original Message----- > > From: Brian E Carpenter [SMTP:brian@hursley.ibm.com] > > Sent: Tuesday, May 30, 2000 6:29 AM > > To: jamal > > Cc: diffserv@ietf.org > > Subject: Re: [Diffserv] Comment on model draft-03 > > > ... > > > Could a BA classifier be defined to be a special case of the six tuple > > > classifier (with the 5 tuples other than the DSCP being wildcards?) > > > > We chose to differentiate between BA and MF classifiers two years ago. > > It would be very confusing to change that now. > > [Andrew] In fact, the proposed Diffserv MIB only defines a 6-tuple table and > makes you wildcard the fields you don't want to use - this is for the > pragmatic reason that the MIB style-police do not like having 2 objects with > overlapping functionality and that fewer objects is better than more > objects. The Conceptual Model, however, ought to be "purer" and treat them > separately, which it does. > Do you mind adding a line or so to state the above? cheers, jamal _______________________________________________ diffserv mailing list diffserv@ietf.org http://www1.ietf.org/mailman/listinfo/diffserv Archive: http://www-nrg.ee.lbl.gov/diff-serv-arch/ From diffserv-admin@ietf.org Wed May 31 08: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 IAA07397 for ; Wed, 31 May 2000 08: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 IAA22005; Wed, 31 May 2000 08:29:20 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id IAA21974 for ; Wed, 31 May 2000 08:29:16 -0400 (EDT) Received: from cyberus.ca (mail.cyberus.ca [209.195.95.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA06332 for ; Wed, 31 May 2000 08:29:14 -0400 (EDT) Received: from shell.cyberus.ca (shell [209.195.95.7]) by cyberus.ca (8.9.3/8.9.3/Cyberus Online Inc.) with ESMTP id IAA23150; Wed, 31 May 2000 08:29:15 -0400 (EDT) Received: from localhost (hadi@localhost) by shell.cyberus.ca (8.9.1b+Sun/8.9.3) with ESMTP id IAA08461; Wed, 31 May 2000 08:29:15 -0400 (EDT) Date: Wed, 31 May 2000 08:29:14 -0400 (EDT) From: jamal To: Brian E Carpenter cc: diffserv@ietf.org Subject: Re: [Diffserv] Comment on model draft-03 In-Reply-To: <3933C22F.4E178F41@hursley.ibm.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: diffserv-admin@ietf.org Errors-To: diffserv-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Diffserv Discussion List X-BeenThere: diffserv@ietf.org On Tue, 30 May 2000, Brian E Carpenter wrote: > Jamal, > > Comments on some of your comments... > And comments on your comments to my comments ;-> > > This version seems to have sunk into more "implementation specifics" > > That's not my impression. While we are not describing an implementation, > it's impossible to describe a model that has no connection to *potential* > implementations. > Fair enough. But why the suggestions on how to do things? The details on freeing buffers etc are based on one/several authors implementation i am sure. Where is this document heading towards again? I can only see it as an informational RFC. > > [One could argue that infact a classifier is a N:1 element. You have N > > different type of packet headers coming in and one "class identifier" or > > queue selector or whatever you wanna call it as an output.] > > Nah. It has a single input stream of mixed up packets and multiple > output streams of classified packets. > Thats one way to look at it ;-> You could probably go further and say it is N:N. For consistency, your definition is fine. > > > > Is Counting really an action element? I would have thought it is explicitly > > part of statistics maintanance; regardless, what has it really got to do > > with defining a diffserv router model? > > In the real world it will be a function of the classifier, and it's > needed for the MIB. I think it's fine where it is. > There has to be a deeper meaning than this which is not clearly elaborated in the text. The question is: do you ever foresee an implementation which does not do stats like the packet/byte counters (incoming/outgoing/dropped etc) such that you end up needing this luxury of choosing not to do stat collection? > ... > > > > With the algorithmic dropper,since you use the RED-like algorithm as > > an example, where does ECN marking fit? (note your usage of "dropper"). > > ECN isn't part of Diffserv, so it doesn't fit in anywhere. > Great; so now Diffserv lives in an isolated world. I thought you said that you cant avoid implementation specifics in some cases. I know you are trying to close this document but ... Both ECN and Diffserv use RED and some of "marking" the old 8bits. That is a bit too close to hand wave away. I see the use of the ECN bits for example being used to provide a lossless AF end2end service for TCP. > > Another rat hole. > > Out of band smoothing function versus in-data-path smoothing function. > > Doesn't look out of band to me; there's a feedback loop right there. I should have been more specific: with the abovce scheme you periodically sample the queue and compute the RED paramaters offline on the control plane (as in not in the data path). I refer to this as out of band. Some other scheme might compute things per packet on the data path; this would be inband. cheers, jamal _______________________________________________ diffserv mailing list diffserv@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 May 31 11:12: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 LAA13354 for ; Wed, 31 May 2000 11:12: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 KAA24110; Wed, 31 May 2000 10:38: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 KAA24079 for ; Wed, 31 May 2000 10:38:46 -0400 (EDT) Received: from nexen.nexen.com (nexen.nexen.com [204.249.96.18]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA12210 for ; Wed, 31 May 2000 10:38:44 -0400 (EDT) Received: from maelstrom.nexen.com (maelstrom.nexen.com [204.249.97.5]) by nexen.nexen.com (8.8.8/8.8.8) with ESMTP id KAA29870; Wed, 31 May 2000 10:38:09 -0400 (EDT) Received: from zanuda.nexen.com (zanuda.nexen.com [204.249.98.150]) by maelstrom.nexen.com (8.8.5/8.7.3) with ESMTP id KAA15163; Wed, 31 May 2000 10:38:09 -0400 (EDT) Received: from nexen.com (sales2.nexen.com [204.249.97.154]) by zanuda.nexen.com (8.8.5/8.8.5) with ESMTP id KAA00053; Wed, 31 May 2000 10:38:07 -0400 (EDT) Message-ID: <393523CF.94CCB019@nexen.com> Date: Wed, 31 May 2000 10:38:07 -0400 From: Mark Stewart X-Mailer: Mozilla 4.7 [en] (Win95; U) X-Accept-Language: en MIME-Version: 1.0 To: Grenville Armitage CC: Andrew Smith , diffserv@ietf.org Subject: Re: [Diffserv] Some comments on Diff-Serve Conceptual Model Draft 3 References: <808F64DDB492D3119D3C00508B5D8D733EC8F0@SOL> <39344D2C.22B4BFD3@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 Armitage wrote: > Consistency is one thing, conciseness is another. I'm suggesting > that the Absolute dropper is merely an instance of an Algorithmic > dropper (with an algorithm of 'always drop'). Other readers are going > to notice (or believe they've noticed) the same thing, and wonder why > 'we' created two different names. To forestall confusion, yes you > probably ought to define the two terms (and their differences) at > the front of the document. > > cheers, > gja Hi Grenville I sympathize with your opinion that the definition of Algorithmic dropper appears to include the Absolute droppers, but differ in the verdict that we should flag it at the front of the document. This phenomena where a superset of old functionality is defined and terms are then needed to define "new" and "old" is common and always problematic. Placing a bundle of "explanations" at the front of every standard, in my opinion, detracts from rather than enhances their clarity. Unfortunately I believe the only avenue you will find open to improving the clarity is some clever wordsmithing of the definitions. I wish you the best as the apparent overlap rubs me the wrong way too. Ciao Mark Stewart _______________________________________________ diffserv mailing list diffserv@ietf.org http://www1.ietf.org/mailman/listinfo/diffserv Archive: http://www-nrg.ee.lbl.gov/diff-serv-arch/ From diffserv-admin@ietf.org Wed May 31 11:44: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 LAA14315 for ; Wed, 31 May 2000 11:44: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 LAA24639; Wed, 31 May 2000 11:20: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 LAA24611 for ; Wed, 31 May 2000 11:20:39 -0400 (EDT) Received: from ennovatenetworks.com (ennovatenetworks.com [208.227.99.254]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA13550 for ; Wed, 31 May 2000 11:20:37 -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 LAA23477 for ; Wed, 31 May 2000 11:20:08 -0400 (EDT) (envelope-from bkumar@ennovatenetworks.com) Reply-To: From: "Brijesh Kumar" To: Subject: RE: [Diffserv] Some comments on Diff-Serve Conceptual Model Draft 3 Date: Wed, 31 May 2000 11:23:56 -0400 Message-ID: <008001bfcb14$3d23bd00$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: <393456CC.CEC57D5@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 In his previous mail Grenville Armitage wrote: > p.s. but if there's any chance to revisit it - how about: > > DROP(F) is a functional datapath element that discards packets > arriving at its input if F==1, otherwise passes packets > through if F==0. > > An 'absolute dropper' would be just DROP(1), an algorithmic RED > dropper on queue X could be expressed as DROP(RED(X)), etc.... You nicely explained it. This is exactly the way I have internally documented here except that in my case F=0 (means no control algorithm defined than drop it - which is an instance of always drop), else apply Drop Algorithm F(X) whatever it is. Either way is OK. Why define a new class for an object, when the new object is nothing, but an instance of an existing class. That is the way I see it. 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 May 31 13: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 NAA17481 for ; Wed, 31 May 2000 13: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 NAA26109; Wed, 31 May 2000 13:07: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 NAA26078 for ; Wed, 31 May 2000 13:07:29 -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 NAA16882 for ; Wed, 31 May 2000 13:07:28 -0400 (EDT) Received: (cpmta 21782 invoked from network); 31 May 2000 10:04:44 -0700 Received: from dnai-216-15-59-68.cust.dnai.com (HELO packetdesign.com) (216.15.59.68) by smtp.packetdesign.com with SMTP; 31 May 2000 10:04:44 -0700 X-Sent: 31 May 2000 17:04:44 GMT Message-ID: <39354631.E3A791AD@packetdesign.com> Date: Wed, 31 May 2000 10:04:49 -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: jamal CC: diffserv@ietf.org Subject: Re: [Diffserv] Diffserv MIB - droppers References: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: diffserv-admin@ietf.org Errors-To: diffserv-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Diffserv Discussion List X-BeenThere: diffserv@ietf.org Content-Transfer-Encoding: 7bit Jamal, One of the problems with getting too specific about how people set/interpret the various RED parameters can be seen in two of your recent emails to the list. First, you said you pick the "queue weight" to "select the number of packets allowed to burst": jamal wrote: > ... > 4) defining the moving window queue weight, W. In our case to make > it intuitive we select to use the number of packets allowed to burst as the > parameter to set because it is more intuitive. This is based on the 93 > paper which limits the lower limit of W > burst + 1 - qmin/avpkt < (1-(1-W)^burst)/W This interpretation would derive from using consecutive packet arrivals (with no idle time) to run your RED algorithm. This was the approach that was used in the simulations and the development of the 93 Floyd and Jacobson RED paper. There is a mention of using the "sampled queue" approach in that paper, but the algorithm and parameters are not developed for that assumption. Then, in your next email, you say: > I should have been more specific: > with the abovce scheme you periodically sample the queue and compute the > RED paramaters offline on the control plane (as in not in the data > path). I refer to this as out of band. Some other scheme might compute > things per packet on the data path; this would be inband. For a variety of reasons, this is our preferred approach and the one we've been working on the past couple of years. In this case, the "queue weight" type of parameter has, of necessity, a slightly different interpretation. So it's important to NOT make any implementation-specific statements about parameter setting. (For example, consider sampling queues for high-speed links at times on the order of 1 ms.) Kathie _______________________________________________ diffserv mailing list diffserv@ietf.org http://www1.ietf.org/mailman/listinfo/diffserv Archive: http://www-nrg.ee.lbl.gov/diff-serv-arch/ From diffserv-admin@ietf.org Wed May 31 14:44: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 OAA19991 for ; Wed, 31 May 2000 14:44: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 OAA26936; Wed, 31 May 2000 14:18: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 OAA26905 for ; Wed, 31 May 2000 14:18:42 -0400 (EDT) Received: from sol.extremenetworks.com (sol.extremenetworks.com [216.52.8.2]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA19072 for ; Wed, 31 May 2000 14:18:39 -0400 (EDT) Received: by SOL with Internet Mail Service (5.5.2650.21) id ; Wed, 31 May 2000 11:14:56 -0700 Message-ID: <808F64DDB492D3119D3C00508B5D8D733EC8FA@SOL> From: Andrew Smith To: "'jamal'" Cc: diffserv@ietf.org Subject: RE: [Diffserv] Comment on model draft-03 Date: Wed, 31 May 2000 11:14:56 -0700 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: text/plain; charset="iso-8859-1" Sender: diffserv-admin@ietf.org Errors-To: diffserv-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Diffserv Discussion List X-BeenThere: diffserv@ietf.org Section 2.2.2 already contains what I think you ask for: "A Behavior Aggregate (BA) Classifier, acting only on DSCPs, is a simple form of the IP Six-Tuple Classifier. It is represented by having the diffServSixTupleClfrDscp attribute set to the desired DSCP and all other classification attributes set to match-all, their default settings. The alternative approach of providing a specific definition in this MIB for a BA Classifier was discussed and rejected." Andrew > -----Original Message----- > From: jamal [mailto:hadi@cyberus.ca] > Sent: Wednesday, May 31, 2000 5:30 AM > To: Andrew Smith > Cc: diffserv@ietf.org > Subject: RE: [Diffserv] Comment on model draft-03 > > > > > On Tue, 30 May 2000, Andrew Smith wrote: > > > See below. > > > > > -----Original Message----- > > > From: Brian E Carpenter [SMTP:brian@hursley.ibm.com] > > > Sent: Tuesday, May 30, 2000 6:29 AM > > > To: jamal > > > Cc: diffserv@ietf.org > > > Subject: Re: [Diffserv] Comment on model draft-03 > > > > > ... > > > > Could a BA classifier be defined to be a special case > of the six tuple > > > > classifier (with the 5 tuples other than the DSCP being > wildcards?) > > > > > > We chose to differentiate between BA and MF classifiers > two years ago. > > > It would be very confusing to change that now. > > > > [Andrew] In fact, the proposed Diffserv MIB only defines a > 6-tuple table and > > makes you wildcard the fields you don't want to use - this > is for the > > pragmatic reason that the MIB style-police do not like > having 2 objects with > > overlapping functionality and that fewer objects is better than more > > objects. The Conceptual Model, however, ought to be "purer" > and treat them > > separately, which it does. > > > > Do you mind adding a line or so to state the above? > > cheers, > jamal > _______________________________________________ diffserv mailing list diffserv@ietf.org http://www1.ietf.org/mailman/listinfo/diffserv Archive: http://www-nrg.ee.lbl.gov/diff-serv-arch/ From diffserv-admin@ietf.org Wed May 31 15:24: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 PAA21285 for ; Wed, 31 May 2000 15:24: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 OAA27431; Wed, 31 May 2000 14: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 OAA27400 for ; Wed, 31 May 2000 14:58:02 -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 OAA20434 for ; Wed, 31 May 2000 14:58:00 -0400 (EDT) Received: from zubin.dnrc.bell-labs.com ([135.180.130.56]) by crufty; Wed May 31 14:57:11 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 OAA14832; Wed, 31 May 2000 14:57:23 -0400 (EDT) Message-ID: <3935616A.EA380F21@dnrc.bell-labs.com> Date: Wed, 31 May 2000 12:00:58 -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: Mark Stewart CC: diffserv@ietf.org Subject: Re: [Diffserv] Some comments on Diff-Serve Conceptual Model Draft 3 References: <808F64DDB492D3119D3C00508B5D8D733EC8F0@SOL> <39344D2C.22B4BFD3@dnrc.bell-labs.com> <393523CF.94CCB019@nexen.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: diffserv-admin@ietf.org Errors-To: diffserv-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Diffserv Discussion List X-BeenThere: diffserv@ietf.org Content-Transfer-Encoding: 7bit Mark Stewart wrote: [..] > This phenomena where a superset > of old functionality is defined and terms are then needed to define "new" and > "old" is common and always problematic. Placing a bundle of "explanations" at > the front of every standard, in my opinion, detracts from rather than enhances > their clarity. 'Dropper' by itself is an old (or at least intuitive) term. Unfortunately in this case neither Absolute Dropper nor Algorithmic Dropper are "old" terms. Of these two new terms, the former isn't even particularly intuitive. Linguistic wierdness ought to be flagged at the start of a document if it is new (and cannot be modified post-Adelaide :-) cheers, gja _______________________________________________ diffserv mailing list diffserv@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 May 31 15:37: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 PAA21728 for ; Wed, 31 May 2000 15:37: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 PAA27760; Wed, 31 May 2000 15:10: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 PAA27724 for ; Wed, 31 May 2000 15:10:05 -0400 (EDT) Received: from ziggy.stardust.com (root@ns.stardust.com [205.184.205.34]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA20740 for ; Wed, 31 May 2000 15:10:03 -0400 (EDT) Received: from WHITESTAR (dhcp204-106.stardust.com [205.184.204.106]) by ziggy.stardust.com (8.9.3/8.9.3/Debian/GNU) with SMTP id MAA13168 for ; Wed, 31 May 2000 12:09:59 -0700 Message-Id: <3.0.5.32.20000531120825.03184100@stardust.com> X-Sender: martinb@stardust.com X-Mailer: QUALCOMM Windows Eudora Pro Version 3.0.5 (32) Date: Wed, 31 May 2000 12:08:25 -0700 To: diffserv@ietf.org From: Marty Bickford Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Subject: [Diffserv] iBAND4: Free Educational Passes & QoS Demonstration Sender: diffserv-admin@ietf.org Errors-To: diffserv-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Diffserv Discussion List X-BeenThere: diffserv@ietf.org ----------------------------------------------------------- iBAND4 - Internet Traffic Management & Service Provisioning for IP Network Engineers & Techno-Savvy Colleagues San Francisco Airport Marriott Hotel Conference: June 11-13 + Workshops: June 14 http://www.stardust.com/iband4/ ----------------------------------------------------------- Free Educational Passes ----------------------- Stardust.com is happy to offer a limited number of free conference passes to educators and non-commercial researchers. If you are interested in obtaining a pass, please email Marty Bickford . iBAND4 is the fourth in the only series of events focused on bandwidth management, traffic engineering and service provisioning. iBAND is your chance to explore the latest thinking about smart bandwidth. Learn about the new standards and technologies, deployment strategies, and business opportunities. Get access to information, insight, knowledge and experts not available at less-focused industry shows. QoS Network Showcase -------------------- The iBAND4 Showcase is the third in a series of networks engineered by members of the QoS Forum. This time around, the showcase features solutions to two substantial classes of problem being confronted by managers of IP networks: - Napster/MP3-based traffic saturation - Denial of Service Attacks Within this showcase, you can see new Quality of Service and Policy Management capabilities in hosts, applications, routers, switches and network analysis tools. Engineered into several different network topologies, these interoperable products harness new protocol standards and show how network managers can use them to address real problems confronting their IP networks. Keynotes outline QoS-enabled, Policy-based B2B networks! -------------------------------------------------------- Evan Kaplan, ceo of Aventail: "B2B Models & the Fundamental Need for Policy-based Networking" Tony Naughtin, ceo of InterNAP: "The Real-World Marriage of QoS and Policy" Brian Carpenter, dir of Internet technology & standards for IBM: "The Evolution and Integration of Emerging Standards" IPv6 and IP Multicast Workshops ------------------------------- Attend one of these advanced technology workshops to understand how the protocols work and how they can be integrated into your network. IP Multicast at a Crossroads http://www.stardust.com/iband4/multicast.htm IPv6 - Understanding the Next Generation http://www.stardust.com/iband4/ipv6.htm The iBAND workshops will be taught on June 14th. Space is very limited. For more information call (408)879-8080 or visit http://www.stardust.com/iband4/ Sign-up Now and Save Money -------------------------- The price will move to $1,395 after June 2nd. Register today at http://www.stardust.com/iband4/ or call (408)879-8080. --- Marty Bickford - 408.879.8080 (8081-fax) Stardust.com - http://www.stardust.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 May 31 16:25: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 QAA23857 for ; Wed, 31 May 2000 16:25:10 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id QAA28754; Wed, 31 May 2000 16:07: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 QAA28648 for ; Wed, 31 May 2000 16:06:51 -0400 (EDT) Received: from ertpg14e1.nortelnetworks.com (ertpg14e1.nortelnetworks.com [47.234.0.35]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA23194 for ; Wed, 31 May 2000 16:06:49 -0400 (EDT) Message-Id: <200005312006.QAA23194@ietf.org> Received: from zcard00n.ca.nortel.com (actually zcard00n) by ertpg14e1.nortelnetworks.com; Wed, 31 May 2000 14:04:19 -0400 Received: from zcard00f.ca.nortel.com ([47.129.30.8]) by zcard00n.ca.nortel.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2650.21) id L9YQAPVC; Wed, 31 May 2000 14:03:28 -0400 Received: from zcarh014 (zcarh014.ca.nortel.com [47.23.81.6]) by zcard00f.ca.nortel.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2650.21) id L5HL7RFT; Wed, 31 May 2000 14:03:25 -0400 Date: Wed, 31 May 2000 14:03:19 -0400 (EDT) X-Sybari-Space: 00000000 00000000 00000000 From: "Nabil Seddigh" Reply-To: "Nabil Seddigh" Subject: RE: [Diffserv] Diffserv MIB - droppers To: Andrew Smith cc: diffserv@ietf.org X-Mailer: Rosa 2.1 HP-UXB.10.20 X-Rosa-Trace: nseddigh@zcarh014 <47.23.81.6> MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-ID: Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by optimus.ietf.org id QAA28649 Sender: diffserv-admin@ietf.org Errors-To: diffserv-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Diffserv Discussion List X-BeenThere: diffserv@ietf.org Content-Transfer-Encoding: 8bit The average queue length (whether multiple or single per queue) is the primary item of interest since that is what the MRED algorithms utilize to make their drop decisions. As my previous email stated, this information will assist with network management, trouble-shooting, SLA tools, traffic engineering and probably to provide observability into the operation of the MRED algorithms. The instantaneous queue length is of lesser interest.... but why preclude it from the MIB? If certain products are unable to provide such information why constrain other products? Again, I believe most products should easily be able to report this information. Should we limit the "many" because of the exception cases? If a product is unable to report this information, maybe it can simply zero it out. Best, Nabil >I'm still slightly confused as to what is being requested here - is it >visibility into the *averaged* queue length or the *instantaneous* queue >length? In an earlier message you seemed to be arguing for the latter but >here you are arguing for the former. It seems to me that you've got to be >particularly careful if you sample on some already-averaged value. Please >clarify. > >Andrew > >> -----Original Message----- >> From: Brian E Carpenter [mailto:brian@hursley.ibm.com] >> Sent: Tuesday, May 30, 2000 2:47 PM >> To: Nabil Seddigh >> Cc: Andrew Smith; diffserv@ietf.org >> Subject: Re: [Diffserv] Diffserv MIB - droppers >> >> >> I have to say that I still don't understand. I can see how percentiles >> might be useful (95th percentile of queue length for example) >> but I don't >> see what diagnostic information the mean queue length conveys. >> >> Brian >> >> Nabil Seddigh wrote: >> > >> > >Sounds like a circular argument to me - it's useful because >> > >it's useful. Can you try to be a little more forthcoming >> > > in your uses? >> > > >> > >> > Circular? I guess I thought the reasons for having >> > average Q sizes was obvious. My apologies!! >> > >> > We have done extensive work with the AF PHB as >> > incarnated by various MRED schemes: WRED, RIO >> > & RIO-decoupled. In all cases, access to the queue >> > averages greatly assisted in trouble shooting and "traffic >> > engineering". >> > >> > Without this information, in many cases we would >> > have been unable to tell whether end-customer achieved >> > traffic characteristics was due to faulty configuration or >> > algorithm specifics. >> > >> > Another reason for exporting the avg Q sizes are >> > the emergence of Diffserv tools for network management. >> > Offline traffic engineering and SLA tools >> > require access to algorithm specific information. >> > For the MRED algorithms, avg Q size is key >> > to achieved performance - not only delay but >> > also achieved bandwidth. >> > >> > Best, >> > --- >> > Nabil Seddigh >> > nseddigh@nortelnetworks.com >> > >> > _______________________________________________ >> > diffserv mailing list >> > diffserv@ietf.org >> > http://www1.ietf.org/mailman/listinfo/diffserv >> > Archive: http://www-nrg.ee.lbl.gov/diff-serv-arch/ >> > > _______________________________________________ diffserv mailing list diffserv@ietf.org http://www1.ietf.org/mailman/listinfo/diffserv Archive: http://www-nrg.ee.lbl.gov/diff-serv-arch/ From diffserv-admin@ietf.org Wed May 31 16:29: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 QAA24019 for ; Wed, 31 May 2000 16:29: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 QAA28774; Wed, 31 May 2000 16:07: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 QAA28656 for ; Wed, 31 May 2000 16:06:53 -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 QAA23198 for ; Wed, 31 May 2000 16:06:50 -0400 (EDT) Message-Id: <200005312006.QAA23198@ietf.org> Received: from zcard00n.ca.nortel.com (actually zcard00n) by ertpg14e1.nortelnetworks.com; Wed, 31 May 2000 15:19:08 -0400 Received: from zcard00f.ca.nortel.com ([47.129.30.8]) by zcard00n.ca.nortel.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2650.21) id L9YQA0Y1; Wed, 31 May 2000 15:19:00 -0400 Received: from zcarh014 (zcarh014.ca.nortel.com [47.23.81.6]) by zcard00f.ca.nortel.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2650.21) id L5HL7RQ3; Wed, 31 May 2000 15:18:56 -0400 Date: Wed, 31 May 2000 15:18:34 -0400 (EDT) X-Sybari-Space: 00000000 00000000 00000000 From: "Nabil Seddigh" Reply-To: "Nabil Seddigh" Subject: RE: [Diffserv] Diffserv MIB - droppers To: Andrew Smith cc: diffserv@ietf.org X-Mailer: Rosa 2.1 HP-UXB.10.20 X-Rosa-Trace: nseddigh@zcarh014 <47.23.81.6> MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-ID: Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by optimus.ietf.org id QAA28659 Sender: diffserv-admin@ietf.org Errors-To: diffserv-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Diffserv Discussion List X-BeenThere: diffserv@ietf.org Content-Transfer-Encoding: 8bit In message "[Diffserv] Diffserv MIB - droppers", Andrew Smith writes: >"The Algorithmic Dropper is modelled as having a >single input. However, it is likely that packets which were >classified differently by a Classifier in this TCB will end up >passing through the same dropper. The dropper's algorithm >may need to apply different calculations based on >characteristics of the incoming packet e.g. its DSCP. >So there is a need, in implementations of this model, >to be able 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." > I am confused. The above is quoted from sec 7.1.3 of the Model Draft and says there's a reverse pointer from the dropper to the classifer. I looked at the MIB's diffServAlgDropEntry and its associated fields. The only pointers I found were diffServDropNext and diffservDropQMeasure - the former points to the next datapath element (Q) and the latter to the diffServQueueTable. Where's the reverse pointer to the Classifier? Did I miss it? In addition, I would have thought that the pointer should be from the classifier to the dropper and not the other way around. > >> On a side note, is there a particular reason why >> diffservAlgDropTable points to the QTable instead >> of the other way around? > >[Andrew] I assume you mean diffServAlgDropQMeasure - >this points to the queue whose characteristics the >algorithm is measuring. diffServAlgDropNext >points to the queue to which this dropper's traffic >next goes (this may or may not be the same queue as >that which is being measured). > I'm not sure I understand how you can measure solely on one queue yet drop solely on another queue. > >on multiple queues then this single-queue pointer and >threshold is not adequate: should we >leave them here or not? they will be useful for many, but not all, >dropper algorithms.>" > Do we need to represent a dropper as being dependent on multiple physical queues or just multiple "virtual queues" within a physical queue? >Anyhow, to answer your question: it is the algorithm that >needs to refer to the queue that it is measuring: that's why >it points at the queue, not vice-versa. > The MIB is only intended to provide config and monitoring info. It is not intended to model implementation. Each queue will have a bunch of config info associated with it. Why not have the queue point to the config info? >> >> To use MIB terminology (pg 7) is this: >> Qmin, Qmax, Pmax and a 4th parameter from which >> the averaging "weight" can be derived? > >[Andrew] I'm still not understanding what is the >exact set of parameters proposed and what they mean. >Everyone so far seems to have difficulty in >expressing (without referring to a particular algorithm/paper) >what they mean by this mysterious "weight" thing. To me that >indicates that there is no single DESCRIPTION that could >possibly make everyone happy and still be >meaningful - but I'm willing to listen to concrete proposals. > I think there's agreement on at least 3 parameters: (Qmin, Qmax and Pmax). As for the weight, different products might use the weight differently but that is implementation specific. Can't we just agree that there's a weight that needs to be used? I wouldn't mind seeing the weight as a float but I suspect that's a hard-sell :) The option of having an exponent that translates into a weight is an acceptable compromise. The MIB doesn't need to nail down exactly how this weight is used does it? I believe Page 28 of the Model draft has an example of suitable RED/MRED parameters instantiated as RIO parameters. >[Andrew] I think Fred's terminology has confused you: I agree >with Fred that we should not have a "current queue depth" >parameter in the MIB. The Model figure 5 shows how there >can be one or more (what Fred calls N) "smoothing >functions" per queue - these may use different parameter >sets to do their calculations. These may feed into one or >more (T) "trigger" or "drop probability calculation" functions. >N may or may not be equal to T. > >I haven't yet worked out an actual MIB representation >of this (was waiting to get consensus on what to include, >if anything, first of all). But it would be connected with >diffServAlgDropTable and diffServAlgDropSpecific and >nothing to do with diffServActionTable - the Model >considers algorithmic droppers to be queueing elements, >not actions (yes, it's an arbitrary choice >but it seems to fit better this way). > Agreed! I think you can easily achieve the above with a new dropType in diffservAlgDropEntry. I think you would also need to connect the output of the classifier-action with the structure that contains the specific thresholds on which the packet is to be compared. Best ---- Nabil Seddigh nseddigh@nortelnetworks.com _______________________________________________ diffserv mailing list diffserv@ietf.org http://www1.ietf.org/mailman/listinfo/diffserv Archive: http://www-nrg.ee.lbl.gov/diff-serv-arch/ From diffserv-admin@ietf.org Wed May 31 17:51:29 2000 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA25713 for ; Wed, 31 May 2000 17:51:28 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id RAA29904; Wed, 31 May 2000 17:23: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 RAA29873 for ; Wed, 31 May 2000 17:23:11 -0400 (EDT) Received: from sol.extremenetworks.com (sol.extremenetworks.com [216.52.8.2]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA25265 for ; Wed, 31 May 2000 17:23:09 -0400 (EDT) Received: by SOL with Internet Mail Service (5.5.2650.21) id ; Wed, 31 May 2000 14:19:27 -0700 Message-ID: <808F64DDB492D3119D3C00508B5D8D733EC8FD@SOL> From: Andrew Smith To: "'Nabil Seddigh'" Cc: diffserv@ietf.org Subject: RE: [Diffserv] Diffserv MIB - droppers Date: Wed, 31 May 2000 14:19:26 -0700 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: text/plain; charset="iso-8859-1" Sender: diffserv-admin@ietf.org Errors-To: diffserv-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Diffserv Discussion List X-BeenThere: diffserv@ietf.org See below. > -----Original Message----- > From: Nabil Seddigh [mailto:nseddigh@nortelnetworks.com] > Sent: Wednesday, May 31, 2000 12:19 PM > To: Andrew Smith > Cc: diffserv@ietf.org > Subject: RE: [Diffserv] Diffserv MIB - droppers > > > In message "[Diffserv] Diffserv MIB - droppers", Andrew Smith writes: > > >"The Algorithmic Dropper is modelled as having a > >single input. However, it is likely that packets which were > >classified differently by a Classifier in this TCB will end up > >passing through the same dropper. The dropper's algorithm > >may need to apply different calculations based on > >characteristics of the incoming packet e.g. its DSCP. > >So there is a need, in implementations of this model, > >to be able 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." > > > > I am confused. The above is quoted from sec 7.1.3 of > the Model Draft and says there's a reverse pointer > from the dropper to the classifer. I looked at the MIB's > diffServAlgDropEntry and its associated fields. > The only pointers I found were diffServDropNext and > diffservDropQMeasure - the former points to the > next datapath element (Q) and the latter to the > diffServQueueTable. Where's the reverse pointer to the > Classifier? Did I miss it? That text is from the Model draft which is designed to cover all algorithms in a generic way but not the specifics of any one algorithm. The MIB does not (currently) handle specific drop algorithms. I would expect that a MIB that included e.g. RED support, would have a RED structure which contained appropriate pointer(s) back to the classifier(s) that are appropriate for that algorithm. There is no sensible way to do this using SMIv2 in a general-enough way to include such pointer(s) in the generic diffServAlgDropEntry. > In addition, I would have thought that the pointer should > be from the classifier to the dropper and not the > other way around. If you have a "from" and a "to" then the choice is arbitrary from a plumbing point of view - it just depends from whose point of view you are describing the thing. that said, it does not make sense to add the pointer field to every classifier element - it is more efficient to add it just to those drop algorithm elements that need to know something about classification. Are you arguing for bi-directional pointers then? > >> On a side note, is there a particular reason why > >> diffservAlgDropTable points to the QTable instead > >> of the other way around? > > > >[Andrew] I assume you mean diffServAlgDropQMeasure - > >this points to the queue whose characteristics the > >algorithm is measuring. diffServAlgDropNext > >points to the queue to which this dropper's traffic > >next goes (this may or may not be the same queue as > >that which is being measured). > > > > I'm not sure I understand how you can measure solely > on one queue yet drop solely on another queue. Do you mean "how" or "why"? I don't see any reason *how* this would not be feasible. I cannot think of a very good reason *why* you might want to do this though. A contrived example might be that you use congestion backpressure from a low-priority queue to also throttle down a high-priority stream. > > >on multiple queues then this single-queue pointer and > >threshold is not adequate: should we > >leave them here or not? they will be useful for many, but not all, > >dropper algorithms.>" > > Do we need to represent a dropper as being dependent on > multiple physical queues or just multiple "virtual queues" within > a physical queue? Not sure what you mean by a "virtual queue". We don't currently have such a concept in the Model. > >Anyhow, to answer your question: it is the algorithm that > >needs to refer to the queue that it is measuring: that's why > >it points at the queue, not vice-versa. > > > > The MIB is only intended to provide config and monitoring > info. It is not intended to model implementation. > Each queue will have a bunch of config info associated > with it. Why not have the queue point to the config info? Be more precise. > >> > >> To use MIB terminology (pg 7) is this: > >> Qmin, Qmax, Pmax and a 4th parameter from which > >> the averaging "weight" can be derived? > > > >[Andrew] I'm still not understanding what is the > >exact set of parameters proposed and what they mean. > >Everyone so far seems to have difficulty in > >expressing (without referring to a particular algorithm/paper) > >what they mean by this mysterious "weight" thing. To me that > >indicates that there is no single DESCRIPTION that could > >possibly make everyone happy and still be > >meaningful - but I'm willing to listen to concrete proposals. > > > > I think there's agreement on at least 3 parameters: > (Qmin, Qmax and Pmax). Please provide definitions. > As for the weight, different products > might use the weight differently but that is implementation > specific. Can't we just agree that there's a weight that > needs to be used? Please provide a definition of "weight". > I wouldn't mind seeing the weight as a float > but I suspect that's a hard-sell :) The option > of having an exponent that translates into a weight is > an acceptable compromise. The MIB doesn't need to nail down > exactly how this weight is used does it? Yes it does, for some definition of consensus on the definition. > I believe Page 28 of the Model draft has an example > of suitable RED/MRED parameters instantiated as RIO > parameters. > > >[Andrew] I think Fred's terminology has confused you: I agree > >with Fred that we should not have a "current queue depth" > >parameter in the MIB. The Model figure 5 shows how there > >can be one or more (what Fred calls N) "smoothing > >functions" per queue - these may use different parameter > >sets to do their calculations. These may feed into one or > >more (T) "trigger" or "drop probability calculation" functions. > >N may or may not be equal to T. > > > >I haven't yet worked out an actual MIB representation > >of this (was waiting to get consensus on what to include, > >if anything, first of all). But it would be connected with > >diffServAlgDropTable and diffServAlgDropSpecific and > >nothing to do with diffServActionTable - the Model > >considers algorithmic droppers to be queueing elements, > >not actions (yes, it's an arbitrary choice > >but it seems to fit better this way). > > > > Agreed! > > I think you can easily achieve the above with a > new dropType in diffservAlgDropEntry. I think you would > also need to connect the output of the classifier-action with > the structure that contains the specific thresholds on > which the packet is to be compared. Let me try the following to see if I understand these 2 points: I think you are saying that diffServAlgDropType needs a new "randomDrop" enumeration - agreed. And I think you are saying that you need a pointer between the classifier element and the drop-algorithm-element - agreed. But there's more than that needed, along the lines of what Fred proposed yesterday. 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 May 31 18:37: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 SAA26341 for ; Wed, 31 May 2000 18:37: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 SAA00837; Wed, 31 May 2000 18:19: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 SAA00733 for ; Wed, 31 May 2000 18:19:21 -0400 (EDT) Received: from sol.extremenetworks.com (sol.extremenetworks.com [216.52.8.2]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA26138 for ; Wed, 31 May 2000 18:19:19 -0400 (EDT) Received: by SOL with Internet Mail Service (5.5.2650.21) id ; Wed, 31 May 2000 15:15:38 -0700 Message-ID: <808F64DDB492D3119D3C00508B5D8D733EC901@SOL> From: Andrew Smith To: "'fred@cisco.com'" , diffserv@ietf.org Subject: RE: [Diffserv] Proposal for Diffserv MIB - droppers Date: Wed, 31 May 2000 15:15: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 Fred, Thanks for that concrete proposal. I agree with it in general and it fits nicely in the current (-03) structures; just a couple of specifics, please see below. > -----Original Message----- > From: fred@cisco.com [mailto:fred@cisco.com] > Sent: Tuesday, May 30, 2000 6:09 PM > To: diffserv@ietf.org > Subject: [Diffserv] Proposal for Diffserv MIB - droppers ... > decision reached on the list: apparently we do need this option. > <(21) Do we need diffServAlgDropType of both "headDrop" and > "tailDrop" or > < should we just represent the tail dropper by placing a dropper > < after the queue instead of before the queue, as linked by the > < diffServQNext and diffServAlgDropNext RowPointers? (the former). [Andrew] I assume you mean "the former" and that we do *not* need to be allowed to place droppers after the queue in the plumbing diagram, right? ... > Add this text to diffServAlgDropType: > diffServRandomDropType OBJECT-TYPE [Andrew] Nit: above should be "diffServAlgDropType" > SYNTAX INTEGER { other(1), > tailDrop(2), > headDrop(3), > > randomDrop(4) > } > MAX-ACCESS read-create > STATUS current > DESCRIPTION > "The type of algorithm used by this dropper. A value of > tailDrop(2) or headDrop(3) represents an algorithm that is > completely specified by this MIB. A value of other(1) requires > further specification in some other MIB module. > > The tailDrop(2) algorithm is described as follows: > diffServRandomDropQThreshold represents the depth of the queue > diffServRandomDropQMeasure at which all newly arriving > packets will > be dropped. > > The headDrop(3) algorithm is described as follows: if a packet > arrives when the current depth of the queue > diffServRandomDropQMeasure is at > diffServRandomDropQThreshold, the > packet currently at the head of the queue is dropped > and the new > packet is enqueued at the tail of the queue. [Andrew] Nit: replace "diffServRandomDrop" by "diffServAlgDrop" everywhere in the above 2 paragraphs. > > The randomDrop algorithm is described as follows: on packet > > arrival, an algorithm is executed which may randomly > drop it, or > > drop another packet from the queue in its place. The specifics > > of the algorithm may be proprietary. In this case, a > > diffServRandomDropEntry is pointed to by > diffServAlgDropSpecific, > > diffServAlgQThreshold is understood to be the absolute maximum > > size of the queue, and additional parameters beyond > those in the > > diffServRandomDropTable may be found in a > vendor-specific MIB." > ::= { diffServRandomDropEntry 3 } [Andrew] Not sure of the difference between diffServAlg(Drop)QThreshold in the above description and diffServRandomDropMaxThreshold in the table below. Please clarify. > > New Text: > > diffServRandomDropTable OBJECT-TYPE > SYNTAX SEQUENCE OF DiffServRandomDropEntry > MAX-ACCESS not-accessible > STATUS current > DESCRIPTION > "The random drop table augments the algorithmic drop table. > It contains entries describing a process that drops packets > randomly. It is pointed to by diffServAlgDropSpecific in such > cases." > REFERENCE > "[MODEL] section 7.1.3" > ::= { diffServTables ? } > > Just a thought: this could literally AUGMENT {diffServTables > 8} using the > Augments clause if we want it to. Not sure what anyone thinks. [Andrew] They frown on "sparse augments" usage: elsewhere in this MIB I have just re-used the same indices for things like this, as you have, and used a "specific" pointer to point at the base of the table (*not* at a row entry within the table) - this gives better efficiency of access for read and create operations, without needing a new IANA registry for extension. > diffServRandomDropEntry OBJECT-TYPE > SYNTAX DiffServRandomDropEntry > MAX-ACCESS not-accessible > STATUS current > DESCRIPTION > "An entry describes a process that drops packets according to > a random Algorithm." > INDEX { ifIndex, diffServAlgDropIfDirection, > diffServAlgDropId } > ::= { diffServRandomDropTable 1 } > > DiffServRandomDropEntry ::= SEQUENCE { > diffServRandomDropMinThreshold Unsigned32, > diffServRandomDropMaxThreshold Unsigned32, > diffServRandomDropAvgInterval Unsigned32, > diffServRandomDropMinSpace Unsigned32, > diffServRandomDropStatus RowStatus > } > > diffServRandomDropMinThreshold OBJECT-TYPE > SYNTAX Unsigned32 > UNITS "packets" > MAX-ACCESS read-create > STATUS current > DESCRIPTION > "The target number of packets to be held in queue. If > the average > queue depth exceeds this amount, one will expect that traffic > exercising this action (which is to say, traffic which > either has > the indicated DSCP or which will be marked to it as > the result of a > meter overflowing) has a non-zero probability of being > dropped or > marked." > ::= { diffServRandomDropEntry 1 } [Andrew] We need a way of indicating which indicated DSCP. This is where we need a RowPointer to the specific classifier element (or filter element?). Suggest we add in a new column: diffServRandomDropClassifier RowPointer DESCRIPTION "The classification pattern indicating which traffic is to receive the drop treatment specified by this drop algorithm." > diffServRandomDropMaxThreshold OBJECT-TYPE > SYNTAX Unsigned32 > UNITS "packets" > MAX-ACCESS read-create > STATUS current > DESCRIPTION > "The limit number of packets to be held in queue. If > the average > queue depth exceeds this amount, one one may presume > that randomly > dropping or marking them has not been successful in > reducing the > source's rate, and these packets must be dropped." > ::= { diffServRandomDropEntry 2 } > > -- > -- this can be done in many ways. One could, for example, maintain an > -- exponentially weighted moving average and put the binary logarithm > -- ("k" in 2^k) here, which is what Cisco equipment does. I > get lots of > -- questions of the form "what is this 'k' thingie for?", and Cisco > -- originally refused to put an equation into the manual, > claiming that > -- this was difficult for customers (read "English majors working in > -- tech pubs") to understand. Since Kathy seems to think > that an interval > -- of milliseconds is about right, I propose we go with that... [Andrew] **** This is where I think we may be overstepping the mark into implementation specifics. Fred, you seem here to have moved towards Kwok's earlier position of including more knobs rather than fewer. I was comfortable with min/max thresholds and some sort of generalised notion of "weight" although I was waiting for some sort of definition for the latter. Last Friday you wrote (not sure if you have "minp" and "the weight" interchanged here maybe?): "So I think I am arguing toward min-threshold and max-threshold, as Kathy suggested, an exponent to manage the exponential averaging (minp), and if you like an upper bound on the drop rate (the weight)" And, before Adelaide, Kathy was proposing something like: "- Threshold for the averaged queue size below which no packet dropping takes place (in 93RED this is min_thresh) - Parameter for that average that controls the history of the averaging: a filter "gain" or a "queue weight". - Upper bound to the "controlled range": a value of the filtered or averaged queue above which 100% of packets are dropped." Your formulation below seems to stray from the "3-parameter RED" that we'd talked about before. Are you saying that Interval is equivalent to the "weight" we'd talked about before? I'm not sure that milliseconds are the right units for one thing and I thought we'd already agreed that intervals were not appropriate for implementations that were triggered by packet events, not timers, no? And I thought Kathy and Van were arguing that maxP (aka MinSpace) was not appropriate to "better" forms of RED (maybe I misunderstood what Van was arguing for in Adelaide). I'd just as soon stick with the 3 parameters using a "weight" not an "interval". But I'm still struggling to find a definition for "weight" that is general enough. **** > diffServRandomDropAvgInterval OBJECT-TYPE > SYNTAX Unsigned32 > UNITS "milliseconds" > MAX-ACCESS read-create > STATUS current > DESCRIPTION > "The number of milliseconds between calculations of > the required > drop rate, in milliseconds. Presumptively, every so often the > drop rate is calibrated, either increasing it due to increased > mean queue depth, or decreasing it because previous drops have > had the necessary effect." > ::= { diffServRandomDropEntry 3 } > > diffServRandomDropMinSpace OBJECT-TYPE > SYNTAX Unsigned32 > MAX-ACCESS read-create > STATUS current > DESCRIPTION > "The minimum number of packets that must be forwarded between > successive marking or dropping events. The number zero > implies that > all packets are subject to drop; the number 99 > indicates that at > most 1% of packets may be dropped, as between any two > packets there > must be at least 99 packets forwarded. This has the effect of > limiting the percentage drop rate to some bound." > ::= { diffServRandomDropEntry 4 } > > diffServRandomDropStatus OBJECT-TYPE > SYNTAX RowStatus > MAX-ACCESS read-create > STATUS current > DESCRIPTION > "The RowStatus variable controls the activation, > deactivation, or > deletion of this entry. Any writable variable may be modified > whether the row is active or notInService." > ::= { diffServRandomDropEntry 12 } [Andrew] I think we can finesse the Status variable out of existence by saying that these entries appear automatically when a diffServAlgDropEntry of type randomDrop is created. That is what I'd propose for the MeterTable/TBMeterTable pair as well. ... 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 May 31 20:30: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 UAA28412 for ; Wed, 31 May 2000 20:30: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 UAA02227; Wed, 31 May 2000 20:06: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 UAA02196 for ; Wed, 31 May 2000 20:06: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 UAA27889 for ; Wed, 31 May 2000 20:06: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 BAA38148; Thu, 1 Jun 2000 01:05: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 BAA22184; Thu, 1 Jun 2000 01:05:41 +0100 (BST) Message-ID: <393568F6.6FC67ADF@hursley.ibm.com> Date: Wed, 31 May 2000 14:33: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: bkumar@ennovatenetworks.com CC: diffserv@ietf.org Subject: Re: [Diffserv] Some comments on Diff-Serve Conceptual Model Draft 3 References: <004c01bfca7f$38c11ae0$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: > > In his previous mail, Brian Carpenter writes > > > > > > > 1. What is an Absolute Dropper? Till recently, I thought a > > Dropper was a > > > Dropper. Either you drop a packet (and free the memory), or > > you forward it > > > and put on the queue. Let us not get into tail drop versus > > head drop or > > > other infinite possible theoretical variations. There is > > only one object > > > called Dropper which may drop as per the algorithm chosen > > from the set of > > > possible N algorithms (tail drop, head drop, ..RED etc.). > > > > Linguistically I tend to agree. > Brian, > > I am glad that you agree. I hope the authors will re-consider their use of > multiple Dropper objects (Absolute and Algorithmic) which, I think, is > unnecessary. That's not quite what I meant. I meant that personally I don't like the choice of word "absolute" - "unconditional" would be better IMHO. But there is a difference between an absolute dropper and an algorithmic dropper. (Well, OK, an absolute dropper is an algorithmic dropper whose algorithm is TRUE, but that's a very formal approach. It's much more intuitive to distinguish the two.) 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 May 31 20:46: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 UAA28716 for ; Wed, 31 May 2000 20:46: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 UAA02675; Wed, 31 May 2000 20: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 UAA02644 for ; Wed, 31 May 2000 20:33:42 -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 UAA28519 for ; Wed, 31 May 2000 20:33:41 -0400 (EDT) Received: from wooly-booly.cisco.com (wooly-booly.cisco.com [171.69.167.33]) by sj-msg-core-2.cisco.com (8.9.3/8.9.1) with ESMTP id RAA25061; Wed, 31 May 2000 17:33:21 -0700 (PDT) Received: from p7020-img-nt.cisco.com (fred-hm-dhcp1.cisco.com [171.69.128.116]) by wooly-booly.cisco.com (8.8.8-Cisco List Logging/CISCO.WS.1.2) with ESMTP id TAA07836; Wed, 31 May 2000 19:33:02 -0500 (CDT) Message-Id: <4.3.2.7.2.20000531171028.02cc6100@flipper.cisco.com> X-Sender: fred@flipper.cisco.com X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Wed, 31 May 2000 17:29:29 -0700 To: Andrew Smith From: Fred Baker Subject: RE: [Diffserv] Proposal for Diffserv MIB - droppers Cc: diffserv@ietf.org In-Reply-To: <808F64DDB492D3119D3C00508B5D8D733EC901@SOL> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: diffserv-admin@ietf.org Errors-To: diffserv-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Diffserv Discussion List X-BeenThere: diffserv@ietf.org At 03:15 PM 5/31/00 -0700, Andrew Smith wrote: >Fred, > >Thanks for that concrete proposal. I agree with it in general and it fits >nicely in the current (-03) structures; just a couple of specifics, please >see below. >[Andrew] I assume you mean "the former" and that we do *not* need to be >allowed to place droppers after the queue in the plumbing diagram, right? yes, and we do indeed allow for head droppers. >[Andrew] Not sure of the difference between diffServAlg(Drop)QThreshold in >the above description and diffServRandomDropMaxThreshold in the table below. >Please clarify. In the head/tail drop implementation, QThreshold is the actual size of the queue, and if we try to put more packets in it than it will hold, something falls on the floor. In the random drop implementation, the queue is actually larger than max-threshold; we don't start dropping everything until the *mean* queue depth exceeds max-threshold. It is quite possible for the instantaneous queue depth to greatly exceed max-threshold, but it cannot do so for very long. So to me, the actual size of the queue and the place you start dropping should the mean exceed that are two very different things. You might, for example, configure: min-threshold[AFx3] = 0 max-threshold[AFx3] <= min-threshold[AFx2] max-threshold[AFx2] <= min-threshold[AFx1] max-threshold[AFx1] = half the *actual* storage space available for the queue In fact, I thought I heard someone say he literally wanted to be dropping all of AFxN+1 before dropping any of AFxN. Did you hear that desire? If QThreshold tells me the actual size of the queue, that is potentially useful information, and I don't know how to interpret it in the above context. >[Andrew] We need a way of indicating which indicated DSCP. This is where we >need a RowPointer to the specific classifier element (or filter element?). Why? The classifier (or the meter, and in that AF case you presumably have just remarked the packet to the new DSCP) is what got you to this action, and is therefore implicit in the fact that you got here. We can add the column you propose, but we should add it to the AlgDropEntry, as the same question applies there, for tail drop (how did the packet get headed towards the queue that is deciding to drop it?). And I think we should not add it unless there is a real utility for it. >Your formulation below seems to stray from the "3-parameter RED" that we'd >talked about before. Yes, mea culpa. Not that I tried to, but I tried to describe it in a way less tied to the moving average definition, and messed it up. I have since had some private email with Joel Halpern. The "interval" object I proposed is broken - we actually want something that will set the "k" in 2^k-1 current queue depth mean queue depth = ----- * mean queue depth + ------------------- i 2^k i-1 2^k as opposed to trying to finesse that. >I'd just as soon stick with the 3 parameters using a "weight" not an >"interval". But I'm still struggling to find a definition for "weight" that >is general enough. weight is the one that follows - it tells us what the greatest possible drop rate is. > > diffServRandomDropMinSpace OBJECT-TYPE > > SYNTAX Unsigned32 > > MAX-ACCESS read-create > > STATUS current > > DESCRIPTION > > "The minimum number of packets that must be forwarded between > > successive marking or dropping events. The number zero > > implies that > > all packets are subject to drop; the number 99 > > indicates that at > > most 1% of packets may be dropped, as between any two > > packets there > > must be at least 99 packets forwarded. This has the effect of > > limiting the percentage drop rate to some bound." > > ::= { diffServRandomDropEntry 4 } >[Andrew] I think we can finesse the Status variable out of existence by >saying that these entries appear automatically when a diffServAlgDropEntry >of type randomDrop is created. That is what I'd propose for the >MeterTable/TBMeterTable pair as well. works for me. _______________________________________________ diffserv mailing list diffserv@ietf.org http://www1.ietf.org/mailman/listinfo/diffserv Archive: http://www-nrg.ee.lbl.gov/diff-serv-arch/ From diffserv-admin@ietf.org Wed May 31 20:49: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 UAA28747 for ; Wed, 31 May 2000 20:49: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 UAA02416; Wed, 31 May 2000 20:24: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 UAA02373 for ; Wed, 31 May 2000 20:24:47 -0400 (EDT) Received: from sol.extremenetworks.com (sol.extremenetworks.com [216.52.8.2]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA28309 for ; Wed, 31 May 2000 20:24:45 -0400 (EDT) Received: by SOL with Internet Mail Service (5.5.2650.21) id ; Wed, 31 May 2000 17:21:03 -0700 Message-ID: <808F64DDB492D3119D3C00508B5D8D733EC907@SOL> From: Andrew Smith To: "'jamal'" Cc: diffserv@ietf.org Subject: RE: [Diffserv] Comment on model draft-03 Date: Wed, 31 May 2000 17:21:03 -0700 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: text/plain; charset="iso-8859-1" Sender: diffserv-admin@ietf.org Errors-To: diffserv-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Diffserv Discussion List X-BeenThere: diffserv@ietf.org See below. > -----Original Message----- > From: jamal [mailto:hadi@cyberus.ca] > Sent: Wednesday, May 31, 2000 5:29 AM > To: Brian E Carpenter > Cc: diffserv@ietf.org > Subject: Re: [Diffserv] Comment on model draft-03 ... > There has to be a deeper meaning than this which is not > clearly elaborated in the text. > The question is: do you ever foresee an implementation which does not > do stats like the packet/byte counters (incoming/outgoing/dropped > etc) such that you end up needing this luxury of choosing not to do > stat collection? One person's "luxury" is another's "cattle class". I think you're trying to impose your value judgements here on economic reality. ... > I should have been more specific: > with the abovce scheme you periodically sample the queue and > compute the > RED paramaters offline on the control plane (as in not in the data > path). I refer to this as out of band. Some other scheme might compute > things per packet on the data path; this would be inband. I think you're reading too much into figure 5 and section 7.1.3. I don't know where you are getting "periodically sample", "offline" or "control plane" from here. What you describe asn in- or out-of-band sounds very much like implementation specifics, not a general model. 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 May 31 21:21: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 VAA29226 for ; Wed, 31 May 2000 21:21: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 UAA03027; Wed, 31 May 2000 20:55: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 UAA02997 for ; Wed, 31 May 2000 20:55:04 -0400 (EDT) Received: from sol.extremenetworks.com (sol.extremenetworks.com [216.52.8.2]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA28815 for ; Wed, 31 May 2000 20:55:03 -0400 (EDT) Received: by SOL with Internet Mail Service (5.5.2650.21) id ; Wed, 31 May 2000 17:51:21 -0700 Message-ID: <808F64DDB492D3119D3C00508B5D8D733EC908@SOL> From: Andrew Smith To: "'Fred Baker'" Cc: diffserv@ietf.org Subject: RE: [Diffserv] Proposal for Diffserv MIB - droppers Date: Wed, 31 May 2000 17:51:20 -0700 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: text/plain; charset="iso-8859-1" Sender: diffserv-admin@ietf.org Errors-To: diffserv-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Diffserv Discussion List X-BeenThere: diffserv@ietf.org OK, things are getting clearer. > -----Original Message----- > From: Fred Baker [mailto:fred@cisco.com] > Sent: Wednesday, May 31, 2000 5:29 PM > To: Andrew Smith > Cc: diffserv@ietf.org > Subject: RE: [Diffserv] Proposal for Diffserv MIB - droppers ... > >[Andrew] Not sure of the difference between > diffServAlg(Drop)QThreshold in > >the above description and diffServRandomDropMaxThreshold in > the table below. > >Please clarify. > > In the head/tail drop implementation, QThreshold is the > actual size of the > queue, and if we try to put more packets in it than it will > hold, something > falls on the floor. In the random drop implementation, the queue is > actually larger than max-threshold; we don't start dropping > everything > until the *mean* queue depth exceeds max-threshold. It is > quite possible > for the instantaneous queue depth to greatly exceed > max-threshold, but it > cannot do so for very long. > > So to me, the actual size of the queue and the place you > start dropping > should the mean exceed that are two very different things. OK. > You might, for > example, configure: > > min-threshold[AFx3] = 0 > max-threshold[AFx3] <= min-threshold[AFx2] > max-threshold[AFx2] <= min-threshold[AFx1] > max-threshold[AFx1] = half the *actual* storage > space available > for the queue > > In fact, I thought I heard someone say he literally wanted to > be dropping > all of AFxN+1 before dropping any of AFxN. Did you hear that desire? I heard that from someone - don't remember who. > If QThreshold tells me the actual size of the queue, that is > potentially > useful information, and I don't know how to interpret it in > the above context. i.e. the "actual depth of queue at which 100% will be dropped", so we can re-use the same QThreshold parameter as we had for hedDrop/tailDrop. Not sure what you mean about not knowing how to interpret it. Do you think QThreshold needs to be read/write for the RED scenario? > >[Andrew] We need a way of indicating which indicated DSCP. > This is where we > >need a RowPointer to the specific classifier element (or > filter element?). > > Why? The classifier (or the meter, and in that AF case you > presumably have > just remarked the packet to the new DSCP) is what got you to > this action, > and is therefore implicit in the fact that you got here. We > can add the > column you propose, but we should add it to the AlgDropEntry, > as the same > question applies there, for tail drop (how did the packet get headed > towards the queue that is deciding to drop it?). And I think > we should not > add it unless there is a real utility for it. This goes back to the "implicit classifier inside the dropper" discussion we had with Dan and Brian. I'd argued that a dropper needed multiple "inputs" in order for it to have multiple packet streams coming into it from separate classifiers, for example. That way a dropper could treat AF11 differently to AF12 (a requirement, I assume). But Dan argued that this was unnatural - you end up duplicating functional elements in the picture unnecessarily (e.g. you might want a single meter on AF1x, not on the individual DSCPs that make up AF1); instead it should be considered as a single packet stream that has different dropping applied to packets with different AF values i.e. there is an implicit classifier inside the dropper - but I think *that* is unnatural. The compromise was that there was some implied sort of linkage back to the classifier for each DSCP - that was described in model-03 without any details attached. Now I'm attempting to flesh out the details. But my proposal is broken for the case where you have several DSCPs all to receive the same drop treatment - an alternative, suggested by Jamal I think, is to point from the classifier to the dropper: this allows for a many-to-1 mapping but it imposes a burden on *all* classifier elements, not just those that impact dropping. More tomorrow ... 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 May 31 21:51: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 VAA00520 for ; Wed, 31 May 2000 21:51: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 VAA03728; Wed, 31 May 2000 21:32: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 VAA03700 for ; Wed, 31 May 2000 21:32:03 -0400 (EDT) Received: from cyberus.ca (mail.cyberus.ca [209.195.95.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA29360 for ; Wed, 31 May 2000 21:32:01 -0400 (EDT) Received: from shell.cyberus.ca (shell [209.195.95.7]) by cyberus.ca (8.9.3/8.9.3/Cyberus Online Inc.) with ESMTP id VAA21333; Wed, 31 May 2000 21:32:02 -0400 (EDT) Received: from localhost (hadi@localhost) by shell.cyberus.ca (8.9.1b+Sun/8.9.3) with ESMTP id VAA10561; Wed, 31 May 2000 21:32:02 -0400 (EDT) Date: Wed, 31 May 2000 21:32:02 -0400 (EDT) From: jamal To: Andrew Smith cc: diffserv@ietf.org Subject: RE: [Diffserv] Comment on model draft-03 In-Reply-To: <808F64DDB492D3119D3C00508B5D8D733EC8FA@SOL> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: diffserv-admin@ietf.org Errors-To: diffserv-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Diffserv Discussion List X-BeenThere: diffserv@ietf.org Indeed i missed this. It is sufficient, thanks. On Wed, 31 May 2000, Andrew Smith wrote: > Section 2.2.2 already contains what I think you ask for: > > "A Behavior Aggregate (BA) Classifier, acting only on DSCPs, is a simple > form of the IP Six-Tuple Classifier. It is represented by having the > diffServSixTupleClfrDscp attribute set to the desired DSCP and all other > classification attributes set to match-all, their default settings. The > alternative approach of providing a specific definition in this MIB for > a BA Classifier was discussed and rejected." > > Andrew > > > -----Original Message----- > > From: jamal [mailto:hadi@cyberus.ca] > > Sent: Wednesday, May 31, 2000 5:30 AM > > To: Andrew Smith > > Cc: diffserv@ietf.org > > Subject: RE: [Diffserv] Comment on model draft-03 > > > > > > > > > > On Tue, 30 May 2000, Andrew Smith wrote: > > > > > See below. > > > > > > > -----Original Message----- > > > > From: Brian E Carpenter [SMTP:brian@hursley.ibm.com] > > > > Sent: Tuesday, May 30, 2000 6:29 AM > > > > To: jamal > > > > Cc: diffserv@ietf.org > > > > Subject: Re: [Diffserv] Comment on model draft-03 > > > > > > > ... > > > > > Could a BA classifier be defined to be a special case > > of the six tuple > > > > > classifier (with the 5 tuples other than the DSCP being > > wildcards?) > > > > > > > > We chose to differentiate between BA and MF classifiers > > two years ago. > > > > It would be very confusing to change that now. > > > > > > [Andrew] In fact, the proposed Diffserv MIB only defines a > > 6-tuple table and > > > makes you wildcard the fields you don't want to use - this > > is for the > > > pragmatic reason that the MIB style-police do not like > > having 2 objects with > > > overlapping functionality and that fewer objects is better than more > > > objects. The Conceptual Model, however, ought to be "purer" > > and treat them > > > separately, which it does. > > > > > > > Do you mind adding a line or so to state the above? > > > > cheers, > > jamal > > > _______________________________________________ diffserv mailing list diffserv@ietf.org http://www1.ietf.org/mailman/listinfo/diffserv Archive: http://www-nrg.ee.lbl.gov/diff-serv-arch/ From diffserv-admin@ietf.org Wed May 31 21:56: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 VAA00564 for ; Wed, 31 May 2000 21:56: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 VAA03696; Wed, 31 May 2000 21:31: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 VAA03665 for ; Wed, 31 May 2000 21:31:34 -0400 (EDT) Received: from cyberus.ca (mail.cyberus.ca [209.195.95.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA29341 for ; Wed, 31 May 2000 21:31:27 -0400 (EDT) Received: from shell.cyberus.ca (shell [209.195.95.7]) by cyberus.ca (8.9.3/8.9.3/Cyberus Online Inc.) with ESMTP id VAA21109; Wed, 31 May 2000 21:31:28 -0400 (EDT) Received: from localhost (hadi@localhost) by shell.cyberus.ca (8.9.1b+Sun/8.9.3) with ESMTP id VAA10557; Wed, 31 May 2000 21:31:29 -0400 (EDT) Date: Wed, 31 May 2000 21:31:29 -0400 (EDT) From: jamal To: Kathleen Nichols cc: diffserv@ietf.org Subject: Re: [Diffserv] Diffserv MIB - droppers In-Reply-To: <39354631.E3A791AD@packetdesign.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: diffserv-admin@ietf.org Errors-To: diffserv-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Diffserv Discussion List X-BeenThere: diffserv@ietf.org Kathie, On Wed, 31 May 2000, Kathleen Nichols wrote: > One of the problems with getting too specific about > how people set/interpret the various RED parameters > can be seen in two of your recent emails to the list. > [..] So in general i agree with you but it seems tricky to ignore some implementation specifics in the case of some _very important_ parameters. ones i have seen being kicked around are: - the time constant, w or some concept used for its derivation can be visualized/represented in a variety of ways to the network manager: +as a floating point number, +as the negative log 2 number, +as a "queue sampling time" +and as i just described in my earlier post using the "burst" parameter. - the drop probability; +if you time sample offline then it is possible to say to the data path "drop after x packets" (refering to Van's presentation to NANOG which i think is the scheme Fred is preaching) +if you use the ns-like implementation then in the simple case you do actually roll the dice in the fast path So the dilema is: you cant leave these parameters out and neither can you ignore the existence of "implementation specifics" If inter-operability is key then there should be some compromise; imagine multiple vendor boxes and some poor ISP network manager trying to get a service created inter-operating them ;-< cheers, jamal _______________________________________________ diffserv mailing list diffserv@ietf.org http://www1.ietf.org/mailman/listinfo/diffserv Archive: http://www-nrg.ee.lbl.gov/diff-serv-arch/ From diffserv-admin@ietf.org Wed May 31 22:41: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 WAA02037 for ; Wed, 31 May 2000 22:41: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 WAA04308; Wed, 31 May 2000 22:11: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 WAA04278 for ; Wed, 31 May 2000 22:11:20 -0400 (EDT) Received: from cyberus.ca (mail.cyberus.ca [209.195.95.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA00760 for ; Wed, 31 May 2000 22:11:17 -0400 (EDT) Received: from shell.cyberus.ca (shell [209.195.95.7]) by cyberus.ca (8.9.3/8.9.3/Cyberus Online Inc.) with ESMTP id WAA05970; Wed, 31 May 2000 22:11:19 -0400 (EDT) Received: from localhost (hadi@localhost) by shell.cyberus.ca (8.9.1b+Sun/8.9.3) with ESMTP id WAA10616; Wed, 31 May 2000 22:11:20 -0400 (EDT) Date: Wed, 31 May 2000 22:11:19 -0400 (EDT) From: jamal To: Andrew Smith cc: diffserv@ietf.org Subject: RE: [Diffserv] Comment on model draft-03 In-Reply-To: <808F64DDB492D3119D3C00508B5D8D733EC907@SOL> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: diffserv-admin@ietf.org Errors-To: diffserv-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Diffserv Discussion List X-BeenThere: diffserv@ietf.org On Wed, 31 May 2000, Andrew Smith wrote: > See below. > > > -----Original Message----- > > From: jamal [mailto:hadi@cyberus.ca] > > Sent: Wednesday, May 31, 2000 5:29 AM > > To: Brian E Carpenter > > Cc: diffserv@ietf.org > > Subject: Re: [Diffserv] Comment on model draft-03 > ... > > There has to be a deeper meaning than this which is not > > clearly elaborated in the text. > > The question is: do you ever foresee an implementation which does not > > do stats like the packet/byte counters (incoming/outgoing/dropped > > etc) such that you end up needing this luxury of choosing not to do > > stat collection? > > One person's "luxury" is another's "cattle class". I think you're trying to > impose your value judgements here on economic reality. > ... hehe. Someone else's "cattle class" is the main reason we are having all these discusions in the first place. Relax. What is your opinion this, really? > I think you're reading too much into figure 5 and section 7.1.3. I don't > know where you are getting "periodically sample", "offline" or "control > plane" from here. What you describe asn in- or out-of-band sounds very much > like implementation specifics, not a general model. I might be but lets review the evidence in question ;-> +------------------+ +-----------+ | +-------+ | n |smoothing | | |trigger|<----------/---|function(s)| | |calc. | | |(optional) | | +-------+ | +-----------+ | | | ^ | v | |Depth Input | +-------+ no | ------------+ to Scheduler ---------->|discard|--------------> |x|x|x|x|-------> | | ? | | ------------+ | +-------+ | FIFO | |yes | | | | | | | | v | count + | | +---+ bit-bucket| +------------------+ Algorithmic Dropper The data path is where the input comes into the discard box, out to the queue and finally scheduled out of the queue. What i see above is some smoothing function taking its input from the queue aka "sampling the queue"; i dont see this being kicked by the arrival of the packet, so naturally i assumed there's probably a time trigger associated aka "periodicity"; The trigger calculation has its input from the smoothing function and feeds the discard box. Given the above representation it would be very rational to assume that the trigger and smoothing functionality are running somewhere off the data path ("offline") and logically that would be in the "control plane" If you gave me this diagram, this is how i would have implemented (as am sure a lot of others will). So there is an implementation specific-ation attached ;-> I would need a lot more information to deduce that the trigger calculation and the smoothing function would be along the fast path. Unless the excuse is that the diagram would look rather ugly ;-> cheers, jamal _______________________________________________ diffserv mailing list diffserv@ietf.org http://www1.ietf.org/mailman/listinfo/diffserv Archive: http://www-nrg.ee.lbl.gov/diff-serv-arch/