From diffserv-admin@ietf.org Fri Dec 1 01:37: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 SMTP id BAA04662 for ; Fri, 1 Dec 2000 01:37:51 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id BAA09787; Fri, 1 Dec 2000 01:16:46 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id BAA09758 for ; Fri, 1 Dec 2000 01:16:41 -0500 (EST) Received: from pilgrim.cisco.com (pilgrim.cisco.com [171.69.204.12]) by ietf.org (8.9.1a/8.9.1a) with SMTP id BAA20494 for ; Fri, 1 Dec 2000 01:16:37 -0500 (EST) Received: from acharny-nt.cisco.com ([161.44.189.106]) by pilgrim.cisco.com (8.8.8-Cisco List Logging/8.8.8) with ESMTP id BAA02572; Fri, 1 Dec 2000 01:15:04 -0500 (EST) Message-Id: <4.3.2.7.2.20001201010751.028aa520@pilgrim.cisco.com> X-Sender: acharny@pilgrim.cisco.com X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Fri, 01 Dec 2000 01:20:39 -0500 To: demir , Anna Charny From: Anna Charny Subject: Re: [Diffserv] EFRESOLVE definition in the presence of excess input burstiness Cc: "Joel M. Halpern" , diffserv@ietf.org In-Reply-To: References: <4.3.2.7.2.20001126144043.025f8780@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 At 05:14 PM 11/30/00 -0800, demir wrote: >Anna, > > > However the statement we were making was that the definition of a per-hop > > behavior should *not* be left undefined in any case, and especially when > > you put together conformant EF devices. In fact, Diffserv Architecture > > explicitly says that a PHB definition should describe the behavior when > > input constraints are violated: > >What about AF PHB? You may say that for AF PHB when input constraints are >violated (Note: we might have different definitions for input >constraints. I assumed trafic input constraints), packets are >dropped. During congestion, behavior might end up, even, dropping >"in" packets. there is no constraint on how much packet will be dropped >or whatever. If you are talking about input parameters to define the >functions of PHB, in AF PHB, there is no constraint how you assign >threshold values of RIO or whatever. From my understanding, what you state >above is not valid to me. Or, is there a point that I am missing here? > It seems to me that it is OK to drop the packets. If packets are *always* dropped when the burst is exceeded, then the behavior is always defined and this is not an issue. But *requiring* dropping may be excessively restrictive and imposes implementation constraints that are quite undesirable. We still need to say what happens when the burst is exceeded but some or all excess packets are not dropped. Currently the behavior is not defined in that case. Anna >Alper K. Demir --------------------------------------- Anna Charny Cisco Systems, Inc 300 Apollo Drive Chelmsford, MA 01824 Tel. (978)-244-8172 Fax (978)-244-8126 _______________________________________________ diffserv mailing list diffserv@ietf.org http://www1.ietf.org/mailman/listinfo/diffserv Archive: http://www2.ietf.org/mail-archive/working-groups/diffserv/current/maillist.html From mailman-owner@ietf.org Fri Dec 1 05:23:58 2000 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with SMTP id FAA17853 for ; Fri, 1 Dec 2000 05:23:58 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id FAA28276 for ; Fri, 1 Dec 2000 05:23:59 -0500 (EST) Date: Fri, 1 Dec 2000 05:23:59 -0500 (EST) Message-Id: <200012011023.FAA28276@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 7ujhy6 http://www1.ietf.org/mailman/options/diffserv/diffserv-archive@optimus.ietf.org From diffserv-admin@ietf.org Fri Dec 1 06:17: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 SMTP id GAA17154 for ; Fri, 1 Dec 2000 06:17:47 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id FAA03522; Fri, 1 Dec 2000 05:51:49 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id FAA03493 for ; Fri, 1 Dec 2000 05:51:45 -0500 (EST) Received: from zcars04f.ca.nortel.com (h57s242a129n47.user.nortelnetworks.com [47.129.242.57]) by ietf.org (8.9.1a/8.9.1a) with SMTP id FAA03205 for ; Fri, 1 Dec 2000 05:51:42 -0500 (EST) Message-Id: <200012011051.FAA03205@ietf.org> Received: from zcard00m.ca.nortel.com by zcars04f.ca.nortel.com; Fri, 1 Dec 2000 05:51:11 -0500 Received: from zbl6c002.corpeast.baynetworks.com ([132.245.205.52]) by zcard00m.ca.nortel.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2652.39) id X8XQKSXG; Fri, 1 Dec 2000 05:51:09 -0500 Received: from tweedy (dhcp171-104.engeast.baynetworks.com [192.32.171.104]) by zbl6c002.corpeast.baynetworks.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2652.39) id X6M8DXR5; Fri, 1 Dec 2000 05:51:08 -0500 X-Sender: khchan@zbl6c002.corpeast.baynetworks.com X-Mailer: QUALCOMM Windows Eudora Pro Version 4.0 Date: Fri, 01 Dec 2000 05:49:56 -0500 To: Robert Moore X-Sybari-Space: 00000000 00000000 00000000 From: "Kwok-Ho Chan" Subject: Re: [Diffserv] DiffServ MIB -06: statistics Cc: diffserv@ietf.org, "Kwok-Ho Chan" In-Reply-To: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" X-Orig: Sender: diffserv-admin@ietf.org Errors-To: diffserv-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Diffserv Discussion List X-BeenThere: diffserv@ietf.org Bob: The DiffServ MIB is geared toward using COPS-PR or SNMPCONF for configuration/provisioning. Hence the setting up of the data path per interface using straight SNMP may not be as optimized but do-able. With use of COPS-PR and SNMPCONF for the setting up, all interfaces of the same Role/RoleCombination will need one and only one set of commands from the Management Server/Station, the duplication/cloning will be done at the Network Device, hence it may not look as bad. Hope this is sufficient to answer your concerns. If the addition you suggest is added to the DiffServ MIB, then this will need to be duplicated in the SNMPCONF DiffServ Policy MIB. Correct? Thanks! -- Kwok -- At 03:33 PM 11/29/00 -0500, Robert Moore wrote: >The approach to statistics in the DiffServ MIB, where >a set of counters is represented as a particular type of >Action element, is very general and very flexible. It >strikes me, though, that it makes some ordinary types of >statistics gathering *mighty* hard to set up. > >To take one example that our developers have asked about, >suppose I want byte and packet counts for packets that >come in / go out over an interface for each of the 64 >DSCP values. If I want these counts on an ingress >interface, I need to build something like this ahead of >any other DiffServ elements on the interface: > > +-----+ > | / |--->CountAct --\ > | / |--->CountAct ---\ > DataPathStart->|->-- |--->CountAct ----->NextElement > | \ |--->CountAct ---/ > | \ |--->CountAct --/ > +-----+ > 64-way 64-way > classifier fan-in > >This involves a whole lot of retrieving the various >NextFree objects, creating the rows in four tables, >and linking them up. Plus, there are those ominous >words before the diffServCountActTable, saying that >in any case, implementations either support counters >(at specific points in their datapaths?) or they >don't. > >The case of an egress interface looks essentially >the same, but with an additional oddity: the >classify/count/fan-in logic would need to sit >after the last scheduler, which is ordinarily >thought of as the last DiffServ element on the >interface. > >If we think that this particular set of statistics - >per-DSCP counts for an interface - are sufficiently >useful that they'll often be needed, they could be >explicitly addressed in the MIB. This would not >mean removing the existing CountAction objects, >which would still be useful for capturing data at >arbitrary points in a DiffServ processing path. >But a structure of the following sort could be >added to the MIB: > >+++++++++++++++++++++++++++++++++++++++++++++++++++++ >dscpStatsTable OBJECT-TYPE > SYNTAX SEQUENCE OF DscpStatsEntry > MAX-ACCESS not-accessible > STATUS current > DESCRIPTION > "." > > ::= { xxxObjects 1 } > >dscpStatsEntry OBJECT-TYPE > SYNTAX DscpStatsEntry > MAX-ACCESS not-accessible > STATUS current > DESCRIPTION > "." > > INDEX { ifNumber, > dscpStatsDirection, > dscpStatsDscp } > > ::= { dscpStatsTable 1 } > >DscpStatsEntry ::= SEQUENCE { > dscpStatsDirection IfDirection, > dscpStatsDscp Dscp, > dscpStatsPackets Counter32, > dscpStatsOctets Counter32, > dscpStatsHCPackets Counter64, > dscpStatsHCOctets Counter64, > dscpStatsDiscontinuityIndicator DateAndTime } >+++++++++++++++++++++++++++++++++++++++++++++++++++++ > >If it's going to be the case that implementations either >do or don't support these counters at this point in the >DiffServ processing on an interface, then why not make >it easy to get the data from those that do? > >Does anybody (besides me) think this would be a >worthwhile addition to the MIB? > >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://www2.ietf.org/mail-archive/working-groups/diffserv/current/maillist.h tml > _______________________________________________ diffserv mailing list diffserv@ietf.org http://www1.ietf.org/mailman/listinfo/diffserv Archive: http://www2.ietf.org/mail-archive/working-groups/diffserv/current/maillist.html From diffserv-admin@ietf.org Fri Dec 1 06:55: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 SMTP id GAA08556 for ; Fri, 1 Dec 2000 06:55:39 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id GAA04206; Fri, 1 Dec 2000 06:29:08 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id GAA04103 for ; Fri, 1 Dec 2000 06:29:00 -0500 (EST) Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA23147; Fri, 1 Dec 2000 06:28:59 -0500 (EST) Message-Id: <200012011128.GAA23147@ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce: ; Cc: diffserv@ietf.org From: Internet-Drafts@ietf.org Reply-to: Internet-Drafts@ietf.org Date: Fri, 01 Dec 2000 06:28:59 -0500 Subject: [Diffserv] I-D ACTION:draft-ietf-diffserv-pib-02.txt Sender: diffserv-admin@ietf.org Errors-To: diffserv-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Diffserv Discussion List X-BeenThere: diffserv@ietf.org --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Differentiated Services Working Group of the IETF. Title : Differentiated Services Quality of Service Policy Information Base Author(s) : M. Fine, K. McCloghrie, J. Seligson, K. Chan, S. Hahn, A. Smith, F. Reichmeyer Filename : draft-ietf-diffserv-pib-02.txt Pages : 82 Date : 30-Nov-00 [SPPI] describes a structure for specifying policy information that can then be transmitted to a network device for the purpose of configuring policy at that device. The model underlying this structure is one of well defined policy rule classes and instances of these classes residing in a virtual information store called the Policy Information Base (PIB). This document specifies a set of policy rule classes specifically for configuring QoS Policy for Differentiated Services [DSARCH]. One way to provision policy is by means of the COPS protocol [COPS] with the extensions for provisioning [COPS-PR]. This protocol supports multiple clients, each of which may provision policy for a specific policy domain such as QoS. The PRCs defined in this DiffServ QoS PIB are intended for use by the COPS-PR QoS client type. Furthemore, these PRCs are in addition to any other PIBs that may be defined for the QoS client type in the future, as well as the PRCs defined in the Framework PIB [FR-PIB] A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-diffserv-pib-02.txt Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-diffserv-pib-02.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-diffserv-pib-02.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <20001130114143.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-diffserv-pib-02.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-diffserv-pib-02.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <20001130114143.I-D@ietf.org> --OtherAccess-- --NextPart-- _______________________________________________ diffserv mailing list diffserv@ietf.org http://www1.ietf.org/mailman/listinfo/diffserv Archive: http://www2.ietf.org/mail-archive/working-groups/diffserv/current/maillist.html From diffserv-admin@ietf.org Fri Dec 1 08:11: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 SMTP id IAA20219 for ; Fri, 1 Dec 2000 08:11:38 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id HAA05928; Fri, 1 Dec 2000 07:45:53 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id HAA05897 for ; Fri, 1 Dec 2000 07:45:48 -0500 (EST) Received: from procyon.pmc-sierra.bc.ca (procyon.pmc-sierra.bc.ca [134.87.115.1]) by ietf.org (8.9.1a/8.9.1a) with SMTP id HAA06821 for ; Fri, 1 Dec 2000 07:45:46 -0500 (EST) Received: from bby1exi01.pmc-sierra.bc.ca (bby1exi01.pmc-sierra.bc.ca [216.241.231.251]) by procyon.pmc-sierra.bc.ca (6.6.6/6.6.6) with ESMTP id EAA01137; Fri, 1 Dec 2000 04:45:12 -0800 (PST) Received: by bby1exi01.pmc-sierra.bc.ca with Internet Mail Service (5.5.2650.21) id ; Fri, 1 Dec 2000 04:45:13 -0800 Message-ID: <9DC5E2ABE65BD54CA9088DA3194461D6010C9AAB@BBY1EXM01> From: Shahram Davari To: "'Brian E Carpenter'" Cc: Diff Serv Subject: RE: [Diffserv] Re: I-D ACTION:draft-ietf-diffserv-model-05.txt Date: Fri, 1 Dec 2000 04:45:05 -0800 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: multipart/mixed; boundary="----_=_NextPart_000_01C05B94.876FC370" Sender: diffserv-admin@ietf.org Errors-To: diffserv-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Diffserv Discussion List X-BeenThere: diffserv@ietf.org This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. ------_=_NextPart_000_01C05B94.876FC370 Content-Type: text/plain Hi Brian, I will wait for the authors to respond. But just for the record, after long discussions with the authors (specially with Fred Baker) it was agreed in version 2 that a simple TB is a TB that can't go negative and as a matter of fact according to my suggestion it was included in the main body of the draft and the negative TB (which is not compatible even with other IETF RFCs) was moved to the appendix (the relevant email is attached). Then suddenly without WG consensus the authors decided to move the negative TB to the main body and call it a simple TB and move the positive TB to the appendix A, in version 3. Then they kept it in version 4 and 5, and without directly answering my concerns rather stating a vague argument like you: "... believe that they considered your comments as well as previous discussion of these points in the WG before deciding which way to go." This kind of statement is not acceptable to me as a WG member, and I demand a valid technical reason that will have the WG consensus. Yours, Shahram Davari Systems Engineer Product Research Group PMC-Sierra, Inc. (Ottawa) Phone: (613) 271-4018 Fax: (613) 271-7007 > -----Original Message----- > From: Brian E Carpenter [mailto:brian@hursley.ibm.com] > Sent: Thursday, November 30, 2000 6:36 PM > To: Shahram Davari > Cc: Diff Serv > Subject: Re: [Diffserv] Re: I-D > ACTION:draft-ietf-diffserv-model-05.txt > > > Shahram, > > I will leave the authors to respond, but I believe that they > considered your > comments as well as previous discussion of these points in the WG > before deciding which way to go. > > Brian > > Shahram Davari wrote: > > > > Hi Brian, > > > > I had concerns regarding the negative token bucket, which > was addressed in version 2, but returned back as an open > issue in version 3 (which was the version discussed in > Pittsburgh), and was never addressed in version 4 and 5. I > would like them to be addressed before this draft goes forward. > > > > Thanks, > > -Shahram > > > > > -----Original Message----- > > > From: Brian E Carpenter [mailto:brian@hursley.ibm.com] > > > Sent: Thursday, November 30, 2000 6:07 PM > > > To: Diff Serv > > > Subject: [Diffserv] Re: I-D > ACTION:draft-ietf-diffserv-model-05.txt > > > > > > > > > Diffservers, > > > > > > We are hoping that this version will be last called very > soon after > > > the San Diego meeting. According to the discussion in Pittsburgh, > > > there are no open issues. This is labelled "Preliminary Authors' > > > Review DRAFT" because there wasn't time for all the authors to > > > approve the text before release. Thanks to Andrew Smith > for producing > > > this version. > > > > > > Brian Carpenter > > > diffserv co-chair > > > > > > Internet-Drafts@ietf.org wrote: > > > > > > > > A New Internet-Draft is available from the on-line > > > Internet-Drafts directories. > > > > This draft is a work item of the Differentiated Services > > > Working Group of the IETF. > > > > > > > > Title : An Informal Management Model for > > > Diffserv Routers > > > > *****Preliminary Authors' > Review DRAFT**** > > > > Author(s) : Y. Bernet, S. Blake, D. > Grossman, A. Smith > > > > Filename : draft-ietf-diffserv-model-05.txt > > > > Pages : 54 > > > > Date : 29-Nov-00 > > > > > > > > This memo proposes an informal management model of > Differentiated > > > > Services (Diffserv) routers for use in their management and > > > > configuration. This model defines functional datapath > > > elements (e.g. > > > > classifiers, meters, actions (e.g. marking, absolute > > > dropping, counting, > > > > multiplexing), algorithmic droppers, queues and schedulers. > > > It describes > > > > possible configuration parameters for these elements and > > > how they might > > > > be interconnected to realize the range of traffic > > > conditioning and per- > > > > hop behavior (PHB) functionalities described in the Diffserv > > > > Architecture [DSARCH]. > > > > > > > > A URL for this Internet-Draft is: > > > > > http://www.ietf.org/internet-drafts/draft-ietf-diffserv-model-05.txt > > > > > > _______________________________________________ > > > diffserv mailing list > > > diffserv@ietf.org > > > http://www1.ietf.org/mailman/listinfo/diffserv > > > Archive: > > > http://www2.ietf.org/mail-archive/working-groups/diffserv/curr > > ent/maillist.html > > _______________________________________________ > diffserv mailing list > diffserv@ietf.org > http://www1.ietf.org/mailman/listinfo/diffserv > Archive: > http://www2.ietf.org/mail-archive/working-groups/diffserv/curr ent/maillist.html ------_=_NextPart_000_01C05B94.876FC370 Content-Type: message/rfc822 Content-Description: RE: [Diffserv] Model Draft TB? Message-ID: <336ECDAFDF7DD311B9E30090277AEE4101B40669@nt-exchange-bby.pmc-sierra.bc.ca> From: Shahram Davari To: 'Fred Baker' , Shahram Davari Subject: RE: [Diffserv] Model Draft TB? Date: Thu, 29 Jun 2000 12:46:38 -0800 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: text/plain Hi Fred, Thanks for your kind response. I think the following paragraph in section 5: " The fact that data is organized into variable length packets introduces some uncertainty in this conformance decision. When used in a Scheduler, a leaky bucket releases a packet only when all of its bits would have been allowed: it does not borrow from future capacity. When used in a Meter, a token bucket accepts a packet if any of its bits would have been accepted and "borrows" any excess capacity required from that allotted to equivalently classified traffic in a previous or subsequent interval. Note that [SRTCM] and [TRTCM] insist on stricter behavior from a meter than the model here insists on." Needs to be changed to: " The fact that data is organized into variable length packets introduces some uncertainty in this conformance decision. When used in a Scheduler, a leaky bucket releases a packet only when all of its bits would have been allowed: it does not borrow from future capacity. When used in a Meter, a token bucket accepts a packet only if all of its bits would have been accepted and does not borrow excess capacity required from future capacity. Note that this is consistent with [SRTCM] and [TRTCM]." Regards, -Shahram >-----Original Message----- >From: Fred Baker [mailto:fred@cisco.com] >Sent: Thursday, June 29, 2000 3:31 PM >To: Shahram Davari >Subject: RE: [Diffserv] Model Draft TB? > > >At 09:03 AM 6/29/00 -0700, Shahram Davari wrote: >>But we should design it with valid data, and valid >justification and be >>consistent to other IETF documents and standards. > >No problem. Can you interact with the design and tell us what >we need to fix? > ------_=_NextPart_000_01C05B94.876FC370-- _______________________________________________ diffserv mailing list diffserv@ietf.org http://www1.ietf.org/mailman/listinfo/diffserv Archive: http://www2.ietf.org/mail-archive/working-groups/diffserv/current/maillist.html From diffserv-admin@ietf.org Fri Dec 1 10:27: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 SMTP id KAA20591 for ; Fri, 1 Dec 2000 10:27:17 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id KAA09270; Fri, 1 Dec 2000 10:00:40 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id KAA09239 for ; Fri, 1 Dec 2000 10:00:35 -0500 (EST) Received: from e21.nc.us.ibm.com (e21.nc.us.ibm.com [32.97.136.227]) by ietf.org (8.9.1a/8.9.1a) with SMTP id KAA19660 for ; Fri, 1 Dec 2000 10:00:35 -0500 (EST) Received: from southrelay02.raleigh.ibm.com (southrelay02.raleigh.ibm.com [9.37.3.209]) by e21.nc.us.ibm.com (8.9.3/8.9.3) with ESMTP id JAA40952; Fri, 1 Dec 2000 09:46:24 -0600 Received: from d04nm200.raleigh.ibm.com (d04nm200.raleigh.ibm.com [9.67.228.37]) by southrelay02.raleigh.ibm.com (8.8.8m3/NCO v4.95) with ESMTP id JAA168000; Fri, 1 Dec 2000 09:58:17 -0500 Importance: Normal Subject: Re: [Diffserv] DiffServ MIB -06: statistics To: "Kwok-Ho Chan" Cc: diffserv@ietf.org, abierman@cisco.com X-Mailer: Lotus Notes Release 5.0.3 (Intl) 21 March 2000 Message-ID: From: "Robert Moore" Date: Fri, 1 Dec 2000 10:02:35 -0500 X-MIMETrack: Serialize by Router on D04NM200/04/M/IBM(Release 5.0.3 (Intl)|21 March 2000) at 12/01/2000 09:58:40 AM 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 Kwok, No, I wasn't thinking of these objects as needing to go into the DiffServ Policy MIB at all. Rather, I was asking whether DiffServ should have a set of "ordinary" interface counters, just like many other protocols do. For implementations that supported these counters, no special configuration would be needed. The counters would just be there on each DiffServ- capable interface, available for a manager to read, or not read, as it chose. Andrew has sent me off in another direction on this question: to the RMON WG's DiffServ Monitoring MIB. Since DSCPs are visible in the packet headers, a probe-based approach is certainly possible for determining the distribution of DSCPs sent to or from a particular device via a particular interface. I think that we will probably end up putting a table of the form I suggested into our hosts. But I can understand that router vendors might prefer to have the performance penalty of what will ordinarily be an extra 64-way classification fall onto a probe rather than onto their router interfaces. Regards, Bob Bob Moore IBM Networking Software +1-919-254-4436 remoore@us.ibm.com "Kwok-Ho Chan" @ietf.org on 12/01/2000 05:49:56 AM Sent by: diffserv-admin@ietf.org To: Robert Moore/Raleigh/IBM@IBMUS cc: diffserv@ietf.org, "Kwok-Ho Chan" Subject: Re: [Diffserv] DiffServ MIB -06: statistics Bob: The DiffServ MIB is geared toward using COPS-PR or SNMPCONF for configuration/provisioning. Hence the setting up of the data path per interface using straight SNMP may not be as optimized but do-able. With use of COPS-PR and SNMPCONF for the setting up, all interfaces of the same Role/RoleCombination will need one and only one set of commands from the Management Server/Station, the duplication/cloning will be done at the Network Device, hence it may not look as bad. Hope this is sufficient to answer your concerns. If the addition you suggest is added to the DiffServ MIB, then this will need to be duplicated in the SNMPCONF DiffServ Policy MIB. Correct? Thanks! -- Kwok -- At 03:33 PM 11/29/00 -0500, Robert Moore wrote: >The approach to statistics in the DiffServ MIB, where >a set of counters is represented as a particular type of >Action element, is very general and very flexible. It >strikes me, though, that it makes some ordinary types of >statistics gathering *mighty* hard to set up. > >To take one example that our developers have asked about, >suppose I want byte and packet counts for packets that >come in / go out over an interface for each of the 64 >DSCP values. If I want these counts on an ingress >interface, I need to build something like this ahead of >any other DiffServ elements on the interface: > > +-----+ > | / |--->CountAct --\ > | / |--->CountAct ---\ > DataPathStart->|->-- |--->CountAct ----->NextElement > | \ |--->CountAct ---/ > | \ |--->CountAct --/ > +-----+ > 64-way 64-way > classifier fan-in > >This involves a whole lot of retrieving the various >NextFree objects, creating the rows in four tables, >and linking them up. Plus, there are those ominous >words before the diffServCountActTable, saying that >in any case, implementations either support counters >(at specific points in their datapaths?) or they >don't. > >The case of an egress interface looks essentially >the same, but with an additional oddity: the >classify/count/fan-in logic would need to sit >after the last scheduler, which is ordinarily >thought of as the last DiffServ element on the >interface. > >If we think that this particular set of statistics - >per-DSCP counts for an interface - are sufficiently >useful that they'll often be needed, they could be >explicitly addressed in the MIB. This would not >mean removing the existing CountAction objects, >which would still be useful for capturing data at >arbitrary points in a DiffServ processing path. >But a structure of the following sort could be >added to the MIB: > >+++++++++++++++++++++++++++++++++++++++++++++++++++++ >dscpStatsTable OBJECT-TYPE > SYNTAX SEQUENCE OF DscpStatsEntry > MAX-ACCESS not-accessible > STATUS current > DESCRIPTION > "." > > ::= { xxxObjects 1 } > >dscpStatsEntry OBJECT-TYPE > SYNTAX DscpStatsEntry > MAX-ACCESS not-accessible > STATUS current > DESCRIPTION > "." > > INDEX { ifNumber, > dscpStatsDirection, > dscpStatsDscp } > > ::= { dscpStatsTable 1 } > >DscpStatsEntry ::= SEQUENCE { > dscpStatsDirection IfDirection, > dscpStatsDscp Dscp, > dscpStatsPackets Counter32, > dscpStatsOctets Counter32, > dscpStatsHCPackets Counter64, > dscpStatsHCOctets Counter64, > dscpStatsDiscontinuityIndicator DateAndTime } >+++++++++++++++++++++++++++++++++++++++++++++++++++++ > >If it's going to be the case that implementations either >do or don't support these counters at this point in the >DiffServ processing on an interface, then why not make >it easy to get the data from those that do? > >Does anybody (besides me) think this would be a >worthwhile addition to the MIB? > >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://www2.ietf.org/mail-archive/working-groups/diffserv/current/maillist.h tml > _______________________________________________ diffserv mailing list diffserv@ietf.org http://www1.ietf.org/mailman/listinfo/diffserv Archive: http://www2.ietf.org/mail-archive/working-groups/diffserv/current/maillist.html _______________________________________________ diffserv mailing list diffserv@ietf.org http://www1.ietf.org/mailman/listinfo/diffserv Archive: http://www2.ietf.org/mail-archive/working-groups/diffserv/current/maillist.html From diffserv-admin@ietf.org Fri Dec 1 11:49: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 SMTP id LAA14732 for ; Fri, 1 Dec 2000 11:49:30 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id LAA10573; Fri, 1 Dec 2000 11:15:59 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id LAA10544 for ; Fri, 1 Dec 2000 11:15:53 -0500 (EST) Received: from chmls20.mediaone.net (chmls20.mediaone.net [24.147.1.156]) by ietf.org (8.9.1a/8.9.1a) with SMTP id LAA04783 for ; Fri, 1 Dec 2000 11:15:51 -0500 (EST) Received: from mediaone.net (h0001027441c5.ne.mediaone.net [24.128.61.165]) by chmls20.mediaone.net (8.8.7/8.8.7) with ESMTP id LAA05839; Fri, 1 Dec 2000 11:15:47 -0500 (EST) Message-ID: <3A27CEA9.E6A6B663@mediaone.net> Date: Fri, 01 Dec 2000 11:15:37 -0500 From: Jon Saperia Organization: JDS Consulting, Inc X-Mailer: Mozilla 4.7 [en] (X11; I; SunOS 5.8 sun4u) X-Accept-Language: en MIME-Version: 1.0 To: Robert Moore CC: Kwok-Ho Chan , diffserv@ietf.org, abierman@cisco.com, Jon Saperia Subject: Re: [Diffserv] DiffServ MIB -06: statistics References: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: diffserv-admin@ietf.org Errors-To: diffserv-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Diffserv Discussion List X-BeenThere: diffserv@ietf.org Content-Transfer-Encoding: 7bit > I think that we will probably end up putting a table of the > form I suggested into our hosts. But I can understand that > router vendors might prefer to have the performance penalty > of what will ordinarily be an extra 64-way classification > fall onto a probe rather than onto their router interfaces. Kwok, we may want to move this to some other list since this is not specific to 06. I agree with the observation that one might want policy level counters that are the aggregate of the queues used to deliver a service. One could add these as extensions to policy configuration objects as in the DiffServ Policy MIB (or other places). The information on how these queues work together is almost certainly not going to be available 'outside' the device that contains the queues. So while you can do some great things with a probe there are some things that will have to be counted inside the router. Just as we aggregate configuration operations we may aggregate the counters as well. /jon _______________________________________________ diffserv mailing list diffserv@ietf.org http://www1.ietf.org/mailman/listinfo/diffserv Archive: http://www2.ietf.org/mail-archive/working-groups/diffserv/current/maillist.html From diffserv-admin@ietf.org Fri Dec 1 13:17: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 SMTP id NAA08555 for ; Fri, 1 Dec 2000 13:16:58 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id MAA12735; Fri, 1 Dec 2000 12:49:20 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id MAA12714 for ; Fri, 1 Dec 2000 12:49:16 -0500 (EST) Received: from mailhub1.almaden.ibm.com (mailhub1.almaden.ibm.com [198.4.83.44]) by ietf.org (8.9.1a/8.9.1a) with SMTP id MAA01218 for ; Fri, 1 Dec 2000 12:49:15 -0500 (EST) Received: from maui.almaden.ibm.com (maui.almaden.ibm.com [9.1.24.92]) by mailhub1.almaden.ibm.com (8.8.8/8.8.8) with ESMTP id JAA28936; Fri, 1 Dec 2000 09:49:33 -0800 Received: from hursley.ibm.com (gsine02.us.sine.ibm.com [9.14.6.42]) by maui.almaden.ibm.com (AIX4.3/8.9.3/8.7) with ESMTP id JAA35800; Fri, 1 Dec 2000 09:48:40 -0800 Message-ID: <3A27E3B8.73824BF1@hursley.ibm.com> Date: Fri, 01 Dec 2000 11:45:28 -0600 From: Brian E Carpenter Organization: IBM X-Mailer: Mozilla 4.61 [en] (Win98; I) X-Accept-Language: en,fr MIME-Version: 1.0 To: Anna Charny CC: demir , "Joel M. Halpern" , diffserv@ietf.org Subject: Re: [Diffserv] EFRESOLVE definition in the presence of excessinput burstiness References: <4.3.2.7.2.20001126144043.025f8780@pilgrim.cisco.com> <4.3.2.7.2.20001201010751.028aa520@pilgrim.cisco.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: diffserv-admin@ietf.org Errors-To: diffserv-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Diffserv Discussion List X-BeenThere: diffserv@ietf.org Content-Transfer-Encoding: 7bit Let's not go there - AF is so totally different that will just confuse a discussion that is already complex enough. Brian Anna Charny wrote: > > At 05:14 PM 11/30/00 -0800, demir wrote: > >Anna, > > > > > However the statement we were making was that the definition of a per-hop > > > behavior should *not* be left undefined in any case, and especially when > > > you put together conformant EF devices. In fact, Diffserv Architecture > > > explicitly says that a PHB definition should describe the behavior when > > > input constraints are violated: > > > >What about AF PHB? You may say that for AF PHB when input constraints are > >violated (Note: we might have different definitions for input > >constraints. I assumed trafic input constraints), packets are > >dropped. During congestion, behavior might end up, even, dropping > >"in" packets. there is no constraint on how much packet will be dropped > >or whatever. If you are talking about input parameters to define the > >functions of PHB, in AF PHB, there is no constraint how you assign > >threshold values of RIO or whatever. From my understanding, what you state > >above is not valid to me. Or, is there a point that I am missing here? > > > > It seems to me that it is OK to drop the packets. If packets are *always* > dropped when the burst is exceeded, then the behavior is always defined and > this is not an issue. But *requiring* dropping may be excessively > restrictive and imposes implementation constraints that are quite > undesirable. We still need to say what happens when the burst is exceeded > but some or all excess packets are not dropped. Currently the behavior is > not defined in that case. > > Anna > > >Alper K. Demir > > --------------------------------------- > Anna Charny > Cisco Systems, Inc > 300 Apollo Drive > Chelmsford, MA 01824 > Tel. (978)-244-8172 > Fax (978)-244-8126 > > _______________________________________________ > diffserv mailing list > diffserv@ietf.org > http://www1.ietf.org/mailman/listinfo/diffserv > Archive: http://www2.ietf.org/mail-archive/working-groups/diffserv/current/maillist.html _______________________________________________ diffserv mailing list diffserv@ietf.org http://www1.ietf.org/mailman/listinfo/diffserv Archive: http://www2.ietf.org/mail-archive/working-groups/diffserv/current/maillist.html From diffserv-admin@ietf.org Fri Dec 1 15: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 SMTP id PAA07353 for ; Fri, 1 Dec 2000 15:00:34 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id OAA14302; Fri, 1 Dec 2000 14:32:15 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id OAA14275 for ; Fri, 1 Dec 2000 14:32:10 -0500 (EST) Received: from mta6.snfc21.pbi.net (mta6.snfc21.pbi.net [206.13.28.240]) by ietf.org (8.9.1a/8.9.1a) with SMTP id OAA02113 for ; Fri, 1 Dec 2000 14:32:08 -0500 (EST) Received: from pacbell.net ([206.170.1.129]) by mta6.snfc21.pbi.net (Sun Internet Mail Server sims.3.5.2000.01.05.12.18.p9) with ESMTP id <0G4W008WSK6A65@mta6.snfc21.pbi.net> for diffserv@ietf.org; Fri, 1 Dec 2000 10:47:00 -0800 (PST) Date: Fri, 01 Dec 2000 10:54:32 -0800 From: Andrew Smith Subject: Re: [Diffserv] draft-ietf-diffserv-model-04.txt - what does it mean To: Brian E Carpenter Cc: Robert Moore , diffserv Message-id: <3A27F3E8.10202@pacbell.net> MIME-version: 1.0 Content-type: text/plain; charset=us-ascii; format=flowed Content-transfer-encoding: 7bit User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; m18) Gecko/20001108 Netscape6/6.0 X-Accept-Language: en References: <3A26DE80.BFD20151@hursley.ibm.com> Content-Transfer-Encoding: 7bit Sender: diffserv-admin@ietf.org Errors-To: diffserv-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Diffserv Discussion List X-BeenThere: diffserv@ietf.org Content-Transfer-Encoding: 7bit Brian, I'm not sure that it is good enough to leave this as an implementation detail: it seems to me that this is needs to be declared as either (a) an invalid/incomplete configuration or (b) a valid configuration with well-defined results. We don't currently have any sort of catch-all "if any part of the DS configuration following along a particular datapath is currently invalid, then the classifier element that leads to this datapath is considered to be not-in-service" rule to handle (a) and I'm not sure how to phrase (b). But I do agree with Bob that we need to address the issue more clearly in the draft. Andrew Brian E Carpenter wrote: > Bob, > > I've always interpreted this phrase to mean that the packet > goes back into the data path it would be on if the router > knew nothing about diffserv. Whether that is the lowest > priority queue seems to be an implementation detail. > > Brian > > Robert Moore wrote: > >> Hi Kwok, >> >> I'll have to say that even with the -06 version of the MIB, >> I still can't say that I really understand how this works. >> Take the following example for an egress interface. The >> example isn't intended to be realistic -- just to illustrate >> my point with the smallest number of elements: >> >> +------+ +---------+ >> | ----|------>Q1(high)-->|Priority | >> DataPath |/ | |Scheduler|-->zeroDotZero >> Start--->|------|------>Q2(low)--->| | >> |\ | +---------+ >> | ----|--->zeroDotZero >> +------+ >> >> Clearly packets from the top branch of the classifier, >> coming from the higher priority queue, will be >> scheduled out ahead of packets from the middle branch, >> which has the lower priority queue. But how will packets >> from the bottom branch be scheduled out, relative to >> those from the top two branches? What does it mean for >> these packets to receive "no further DiffServ treatment," >> relative to packets from the other two branches, which >> do receive this treatment? >> >> I could make up an answer here: packets on the bottom >> branch are treated as if they were on a lowest priority >> queue serviced by this same Priority Scheduler. But I'd >> be more comfortable if there were something in either >> the MIB or the Informal Model that I could point to, >> implying that this answer is the correct one. >> >> Regards, >> Bob >> >> Bob Moore >> IBM Networking Software >> +1-919-254-4436 >> remoore@us.ibm.com >> >> "Kwok-Ho Chan" @ietf.org on 11/16/2000 12:02:58 >> PM >> >> Sent by: diffserv-admin@ietf.org >> >> To: Erez Bashan >> cc: diffserv >> Subject: Re: [Diffserv] draft-ietf-diffserv-model-04.txt - what does it >> mean "no further Diffserv treatment is performed" ? >> >> Meaning of "no further DiffServ treatment is performed", as quoted from >> DSMIB-05 section 3.1.1: >> "allow normal IP device processing", "Normal IP device processing >> will depend on the device, for example, this can be forwarding the packet." >> >> Is this sufficient? May be I should move this explanation to the >> RowPointer >> section (5.1), but that section maybe changed in a more dramatic way >> depending on the outcome of the "Instance Amplification" discussion thread. >> >> -- Kwok -- >> >> At 03:24 PM 11/16/00 +0200, Erez Bashan wrote: >> >>> In several places in the MIB (for example if the diffServMeterFailNext has >> >> a >> >>> value of "value of zeroDotZero") a scenario exists in which "no further >>> Diffserv treatment is performed" on certain traffic. >>> >>> What does it mean ? Is the packet dropped, or should it be handled by >>> another independent (??) mechanism in the router ? If it is to be dropped, >>> why isn't it says so explicitly ? >>> >>> Erez _______________________________________________ diffserv mailing list diffserv@ietf.org http://www1.ietf.org/mailman/listinfo/diffserv Archive: http://www2.ietf.org/mail-archive/working-groups/diffserv/current/maillist.html From diffserv-admin@ietf.org Fri Dec 1 15: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 SMTP id PAA07355 for ; Fri, 1 Dec 2000 15:00:34 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id OAA14272; Fri, 1 Dec 2000 14:32:08 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id OAA14240 for ; Fri, 1 Dec 2000 14:32:03 -0500 (EST) Received: from mta6.snfc21.pbi.net (mta6.snfc21.pbi.net [206.13.28.240]) by ietf.org (8.9.1a/8.9.1a) with SMTP id OAA02079 for ; Fri, 1 Dec 2000 14:32:01 -0500 (EST) Received: from pacbell.net ([206.170.1.129]) by mta6.snfc21.pbi.net (Sun Internet Mail Server sims.3.5.2000.01.05.12.18.p9) with ESMTP id <0G4W008UVJW0TD@mta6.snfc21.pbi.net> for diffserv@ietf.org; Fri, 1 Dec 2000 10:40:51 -0800 (PST) Date: Fri, 01 Dec 2000 10:48:21 -0800 From: Andrew Smith Subject: Re: [Diffserv] DiffServ MIB -06: statistics To: Robert Moore Cc: diffserv@ietf.org, abierman@cisco.com Message-id: <3A27F275.7040201@pacbell.net> MIME-version: 1.0 Content-type: text/plain; charset=us-ascii; format=flowed Content-transfer-encoding: 7bit User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; m18) Gecko/20001108 Netscape6/6.0 X-Accept-Language: en References: Content-Transfer-Encoding: 7bit Sender: diffserv-admin@ietf.org Errors-To: diffserv-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Diffserv Discussion List X-BeenThere: diffserv@ietf.org Content-Transfer-Encoding: 7bit Bob, Robert Moore wrote: > I think that we will probably end up putting a table of the > form I suggested into our hosts. But I can understand that > router vendors might prefer to have the performance penalty > of what will ordinarily be an extra 64-way classification > fall onto a probe rather than onto their router interfaces. I think it's wrong to think of DSMON (and RMON) as just something for "probes" to implement: these days, the only viable place to put such probes is often inside the router/switch. The vendors of such boxes do make value judgements as to how much or little RMON-like functionality to build in (and their customers, historically at least, always *want* more but are seldom willing to pay for it) e.g. in this case I think it quite likely that they might put in such counters for each DSCP that they are currently handling, even if they don't have them there for all DSCPs all of the time - any MIB for this purpose should reflect such implementation options to be useful (and the -06 DS MIB does allow this with the "Counter Action" elements). Andrew _______________________________________________ diffserv mailing list diffserv@ietf.org http://www1.ietf.org/mailman/listinfo/diffserv Archive: http://www2.ietf.org/mail-archive/working-groups/diffserv/current/maillist.html From diffserv-admin@ietf.org Fri Dec 1 16:26: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 SMTP id QAA26668 for ; Fri, 1 Dec 2000 16:26:55 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id PAA15892; Fri, 1 Dec 2000 15:57:14 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id PAA15860 for ; Fri, 1 Dec 2000 15:57:08 -0500 (EST) Received: from e2.ny.us.ibm.com (e2.ny.us.ibm.com [32.97.182.102]) by ietf.org (8.9.1a/8.9.1a) with SMTP id PAA20175 for ; Fri, 1 Dec 2000 15:57:08 -0500 (EST) Received: from southrelay02.raleigh.ibm.com (southrelay02.raleigh.ibm.com [9.37.3.209]) by e2.ny.us.ibm.com (8.9.3/8.9.3) with ESMTP id PAA189646 for ; Fri, 1 Dec 2000 15:55:59 -0500 Received: from d04nm200.raleigh.ibm.com (d04nm200.raleigh.ibm.com [9.67.228.37]) by southrelay02.raleigh.ibm.com (8.8.8m3/NCO v4.95) with ESMTP id PAA58506; Fri, 1 Dec 2000 15:53:40 -0500 Importance: Normal To: diffserv@ietf.org, policy@raleigh.ibm.com X-Mailer: Lotus Notes Release 5.0.3 (Intl) 21 March 2000 Message-ID: From: "Robert Moore" Date: Fri, 1 Dec 2000 15:57:43 -0500 X-MIMETrack: Serialize by Router on D04NM200/04/M/IBM(Release 5.0.3 (Intl)|21 March 2000) at 12/01/2000 03:54:01 PM MIME-Version: 1.0 Content-type: text/plain; charset=us-ascii Subject: [Diffserv] Modeling of algorithmic droppers and queues Sender: diffserv-admin@ietf.org Errors-To: diffserv-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Diffserv Discussion List X-BeenThere: diffserv@ietf.org After reading through the -05 Informal Model, and comparing it with the new -02 QDDIM, it appears that neither of us is quite there yet on modeling the relationship between an algorithmic dropper and a queue. There are (at least!) two ways of modeling these two elements, and both documents contain elements of both approaches. Option 1: an algorithmic dropper sits before its queue in the data path, and based on what it sees in the queue, it discards "packets that arrive at its input" (Informal Model, p. 27). This is what the Informal Model describes as the alternative it has chosen. It is the basis for the NextService association in QDDIM and the Next pointer in the -06 MIB, which show a progression from -to-AlgorithmicDropper-to-queue. Option 2: an algorithmic dropper sits beside its queue, outside the data path, and based on what it sees in the queue, it discards packets "from the head, tail, or other part of the associated queue" (Informal Model, p. 29). Figure 5 in the Informal Model shows this interpretation very clearly, and it's also represented in the QDDIM by the HeadTailDropQueueBinding association. If we look at the example TCB in section 8.2 of the informal model, we see that the droppers are all placed before their associated queues, as Option 1 requires. But they're also dropping from the tails of the queues, which, given the picture, isn't too much of a stretch: if the observed properties of the queue tell it to, the dropper drops a packet that it's holding, rather than putting it onto the tail of the queue. What would the picture look like if the dropping were from the head of one of the queues? We can't place the dropper after the queue -- both the Informal Model and the MIB explicitly rule this out. The only picture that works is the one for Option 2. But here the dropper is plainly not dropping a packet that "arrives at its input" -- it's dropping a packet from the head of the queue. I'm not sure what's the best way to clarify all of this. My inclination, though, would be to say that Option 2 is the right way to think of this relationship, with the *convention* that the chain of Next pointers / NextService associations always goes -->AlgorithmicDropper-->queue. I'm also wondering whether, in the QDDIM, we should have made HeadTailDropQueueBinding a subclass of NextService, This would embody the convention that I just described, without requiring a separate NextService association between the dropper and the queue, alongside the HeadTailDropQueueBinding. (This assumes that the queue that a HeadTailDropper monitors is always the same one from which it causes packets to be dropped -- I haven't seen anything to indicate that this is not the case.) 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://www2.ietf.org/mail-archive/working-groups/diffserv/current/maillist.html From diffserv-admin@ietf.org Fri Dec 1 16:28:52 2000 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with SMTP id QAA27056 for ; Fri, 1 Dec 2000 16:28:48 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id QAA16175; Fri, 1 Dec 2000 16:05:06 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id QAA16144 for ; Fri, 1 Dec 2000 16:05:00 -0500 (EST) Received: from mailhub1.almaden.ibm.com (mailhub1.almaden.ibm.com [198.4.83.44]) by ietf.org (8.9.1a/8.9.1a) with SMTP id QAA21998 for ; Fri, 1 Dec 2000 16:04:59 -0500 (EST) Received: from maui.almaden.ibm.com (maui.almaden.ibm.com [9.1.24.92]) by mailhub1.almaden.ibm.com (8.8.8/8.8.8) with ESMTP id NAA22506; Fri, 1 Dec 2000 13:05:18 -0800 Received: from hursley.ibm.com (gsine02.us.sine.ibm.com [9.14.6.42]) by maui.almaden.ibm.com (AIX4.3/8.9.3/8.7) with ESMTP id NAA24464; Fri, 1 Dec 2000 13:04:27 -0800 Message-ID: <3A281163.8ED9BB04@hursley.ibm.com> Date: Fri, 01 Dec 2000 15:00:19 -0600 From: Brian E Carpenter Organization: IBM X-Mailer: Mozilla 4.61 [en] (Win98; I) X-Accept-Language: en,fr MIME-Version: 1.0 To: Andrew Smith CC: Robert Moore , diffserv Subject: Re: [Diffserv] draft-ietf-diffserv-model-04.txt - what does it mean References: <3A26DE80.BFD20151@hursley.ibm.com> <3A27F3E8.10202@pacbell.net> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: diffserv-admin@ietf.org Errors-To: diffserv-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Diffserv Discussion List X-BeenThere: diffserv@ietf.org Content-Transfer-Encoding: 7bit Fair enough, we can clarify it, but am I right that it means that the packet is simply inserted into the data path as if diffserv didn't exist (which is presumably equivalent to treating it as BE)? Brian Andrew Smith wrote: > > Brian, > > I'm not sure that it is good enough to leave this as an implementation detail: > it seems to me that this is needs to be declared as either (a) an > invalid/incomplete configuration or (b) a valid configuration with well-defined > results. We don't currently have any sort of catch-all "if any part of the DS > configuration following along a particular datapath is currently invalid, then > the classifier element that leads to this datapath is considered to be > not-in-service" rule to handle (a) and I'm not sure how to phrase (b). But I do > agree with Bob that we need to address the issue more clearly in the draft. > > Andrew > > Brian E Carpenter wrote: > > > Bob, > > > > I've always interpreted this phrase to mean that the packet > > goes back into the data path it would be on if the router > > knew nothing about diffserv. Whether that is the lowest > > priority queue seems to be an implementation detail. > > > > Brian > > > > Robert Moore wrote: > > > >> Hi Kwok, > >> > >> I'll have to say that even with the -06 version of the MIB, > >> I still can't say that I really understand how this works. > >> Take the following example for an egress interface. The > >> example isn't intended to be realistic -- just to illustrate > >> my point with the smallest number of elements: > >> > >> +------+ +---------+ > >> | ----|------>Q1(high)-->|Priority | > >> DataPath |/ | |Scheduler|-->zeroDotZero > >> Start--->|------|------>Q2(low)--->| | > >> |\ | +---------+ > >> | ----|--->zeroDotZero > >> +------+ > >> > >> Clearly packets from the top branch of the classifier, > >> coming from the higher priority queue, will be > >> scheduled out ahead of packets from the middle branch, > >> which has the lower priority queue. But how will packets > >> from the bottom branch be scheduled out, relative to > >> those from the top two branches? What does it mean for > >> these packets to receive "no further DiffServ treatment," > >> relative to packets from the other two branches, which > >> do receive this treatment? > >> > >> I could make up an answer here: packets on the bottom > >> branch are treated as if they were on a lowest priority > >> queue serviced by this same Priority Scheduler. But I'd > >> be more comfortable if there were something in either > >> the MIB or the Informal Model that I could point to, > >> implying that this answer is the correct one. > >> > >> Regards, > >> Bob > >> > >> Bob Moore > >> IBM Networking Software > >> +1-919-254-4436 > >> remoore@us.ibm.com > >> > >> "Kwok-Ho Chan" @ietf.org on 11/16/2000 12:02:58 > >> PM > >> > >> Sent by: diffserv-admin@ietf.org > >> > >> To: Erez Bashan > >> cc: diffserv > >> Subject: Re: [Diffserv] draft-ietf-diffserv-model-04.txt - what does it > >> mean "no further Diffserv treatment is performed" ? > >> > >> Meaning of "no further DiffServ treatment is performed", as quoted from > >> DSMIB-05 section 3.1.1: > >> "allow normal IP device processing", "Normal IP device processing > >> will depend on the device, for example, this can be forwarding the packet." > >> > >> Is this sufficient? May be I should move this explanation to the > >> RowPointer > >> section (5.1), but that section maybe changed in a more dramatic way > >> depending on the outcome of the "Instance Amplification" discussion thread. > >> > >> -- Kwok -- > >> > >> At 03:24 PM 11/16/00 +0200, Erez Bashan wrote: > >> > >>> In several places in the MIB (for example if the diffServMeterFailNext has > >> > >> a > >> > >>> value of "value of zeroDotZero") a scenario exists in which "no further > >>> Diffserv treatment is performed" on certain traffic. > >>> > >>> What does it mean ? Is the packet dropped, or should it be handled by > >>> another independent (??) mechanism in the router ? If it is to be dropped, > >>> why isn't it says so explicitly ? > >>> > >>> Erez _______________________________________________ diffserv mailing list diffserv@ietf.org http://www1.ietf.org/mailman/listinfo/diffserv Archive: http://www2.ietf.org/mail-archive/working-groups/diffserv/current/maillist.html From diffserv-admin@ietf.org Fri Dec 1 17:06: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 SMTP id RAA03520 for ; Fri, 1 Dec 2000 17:06:38 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id QAA17503; Fri, 1 Dec 2000 16:38:20 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id QAA17475 for ; Fri, 1 Dec 2000 16:38:15 -0500 (EST) Received: from usc.edu (root@usc.edu [128.125.253.136]) by ietf.org (8.9.1a/8.9.1a) with SMTP id QAA28683 for ; Fri, 1 Dec 2000 16:38:14 -0500 (EST) Received: from aludra.usc.edu (demir@aludra.usc.edu [128.125.253.184]) by usc.edu (8.9.3.1/8.9.3/usc) with ESMTP id NAA00767; Fri, 1 Dec 2000 13:38:13 -0800 (PST) Received: from localhost (demir@localhost) by aludra.usc.edu (8.9.3.1/8.9.3/usc) with ESMTP id NAA07733; Fri, 1 Dec 2000 13:38:12 -0800 (PST) Date: Fri, 1 Dec 2000 13:38:11 -0800 (PST) From: demir To: Brian E Carpenter cc: diffserv@ietf.org Subject: Re: [Diffserv] EFRESOLVE definition in the presence of excessinput burstiness In-Reply-To: <3A27E3B8.73824BF1@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 Okay. As a side note, though, however a definition is defined, it should apply to all cases. What about the idea of using a much general EF PHB definition or the previous one that I already posted. This can be a new PHB as BOUND PHB :) bounded_vaule(i) < bound_value(i) and each PDB defines above functions. Anna can define for input output rate and burstiness and new proposal for its related PDB define as: bounded_value(i) = D(i) bound_value(i) = S*MTU/R+E(i) All discussions related to EF PHB disaapper, PDB discussions start :) Alper K. Demir On Fri, 1 Dec 2000, Brian E Carpenter wrote: > Let's not go there - AF is so totally different that will just > confuse a discussion that is already complex enough. > > Brian > > Anna Charny wrote: > > > > At 05:14 PM 11/30/00 -0800, demir wrote: > > >Anna, > > > > > > > However the statement we were making was that the definition of a per-hop > > > > behavior should *not* be left undefined in any case, and especially when > > > > you put together conformant EF devices. In fact, Diffserv Architecture > > > > explicitly says that a PHB definition should describe the behavior when > > > > input constraints are violated: > > > > > >What about AF PHB? You may say that for AF PHB when input constraints are > > >violated (Note: we might have different definitions for input > > >constraints. I assumed trafic input constraints), packets are > > >dropped. During congestion, behavior might end up, even, dropping > > >"in" packets. there is no constraint on how much packet will be dropped > > >or whatever. If you are talking about input parameters to define the > > >functions of PHB, in AF PHB, there is no constraint how you assign > > >threshold values of RIO or whatever. From my understanding, what you state > > >above is not valid to me. Or, is there a point that I am missing here? > > > > > > > It seems to me that it is OK to drop the packets. If packets are *always* > > dropped when the burst is exceeded, then the behavior is always defined and > > this is not an issue. But *requiring* dropping may be excessively > > restrictive and imposes implementation constraints that are quite > > undesirable. We still need to say what happens when the burst is exceeded > > but some or all excess packets are not dropped. Currently the behavior is > > not defined in that case. > > > > Anna > > > > >Alper K. Demir > > > > --------------------------------------- > > Anna Charny > > Cisco Systems, Inc > > 300 Apollo Drive > > Chelmsford, MA 01824 > > Tel. (978)-244-8172 > > Fax (978)-244-8126 > > > > _______________________________________________ > > diffserv mailing list > > diffserv@ietf.org > > http://www1.ietf.org/mailman/listinfo/diffserv > > Archive: http://www2.ietf.org/mail-archive/working-groups/diffserv/current/maillist.html > > _______________________________________________ > diffserv mailing list > diffserv@ietf.org > http://www1.ietf.org/mailman/listinfo/diffserv > Archive: http://www2.ietf.org/mail-archive/working-groups/diffserv/current/maillist.html > _______________________________________________ diffserv mailing list diffserv@ietf.org http://www1.ietf.org/mailman/listinfo/diffserv Archive: http://www2.ietf.org/mail-archive/working-groups/diffserv/current/maillist.html From diffserv-admin@ietf.org Fri Dec 1 18:41: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 SMTP id SAA02182 for ; Fri, 1 Dec 2000 18:41:14 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id SAA19596; Fri, 1 Dec 2000 18:14:10 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id SAA19565 for ; Fri, 1 Dec 2000 18:14:05 -0500 (EST) Received: from mailman.packetdesign.com (dns.PACKETDESIGN.NET [216.15.46.10]) by ietf.org (8.9.1a/8.9.1a) with SMTP id SAA23888; Fri, 1 Dec 2000 18:14:03 -0500 (EST) Received: from packetdesign.com (dhcp-168-0-13.packetdesign.com [192.168.0.13]) by mailman.packetdesign.com (8.11.0/8.11.0) with ESMTP id eB1NDXQ42431; Fri, 1 Dec 2000 15:13:34 -0800 (PST) (envelope-from nichols@packetdesign.com) Message-ID: <3A28332C.5F09DFDE@packetdesign.com> Date: Fri, 01 Dec 2000 15:24:28 -0800 From: Kathleen Nichols X-Mailer: Mozilla 4.73 [en] (X11; I; Linux 2.2.12 i386) X-Accept-Language: en MIME-Version: 1.0 To: agenda@ietf.org CC: diffserv@ietf.org Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Subject: [Diffserv] Diffserv WG agenda for San Diego IETF Sender: diffserv-admin@ietf.org Errors-To: diffserv-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Diffserv Discussion List X-BeenThere: diffserv@ietf.org Content-Transfer-Encoding: 7bit Diffserv WG Agenda Monday, December 11, 2000, 13:00-15:00 (5) Agenda bashing Status Updates (5) draft-ietf-diffserv-new-terms-03 (5) draft-ietf-diffserv-model-05 (5) draft-ietf-diffserv-pdb-def-01 Issue discussion (20) draft-ietf-diffserv-pib-02 (30) draft-ietf-diffserv-mib-06 (10) draft-ietf-diffserv-pdb-bh-00 In time remaining, the chairs will permit authors of drafts of interest to give pointers to their drafts or to seek other co-authors, by taking requests from the floor Tuesday, December 12, 2000, 15:45-16:45 This session will be entirely concerned with issues related to draft-ietf-diffserv-efresolve-00 and will be moderated by Brian Carpenter _______________________________________________ diffserv mailing list diffserv@ietf.org http://www1.ietf.org/mailman/listinfo/diffserv Archive: http://www2.ietf.org/mail-archive/working-groups/diffserv/current/maillist.html From diffserv-admin@ietf.org Fri Dec 1 23: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 SMTP id XAA25341 for ; Fri, 1 Dec 2000 23:10:34 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id WAA22112; Fri, 1 Dec 2000 22:50:25 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id WAA22083 for ; Fri, 1 Dec 2000 22:50:20 -0500 (EST) Received: from usc.edu (root@usc.edu [128.125.253.136]) by ietf.org (8.9.1a/8.9.1a) with SMTP id WAA22804 for ; Fri, 1 Dec 2000 22:50:18 -0500 (EST) Received: from aludra.usc.edu (demir@aludra.usc.edu [128.125.253.184]) by usc.edu (8.9.3.1/8.9.3/usc) with ESMTP id TAA08426; Fri, 1 Dec 2000 19:50:20 -0800 (PST) Received: from localhost (demir@localhost) by aludra.usc.edu (8.9.3.1/8.9.3/usc) with ESMTP id TAA11512; Fri, 1 Dec 2000 19:50:19 -0800 (PST) Date: Fri, 1 Dec 2000 19:50:19 -0800 (PST) From: demir To: Anna Charny cc: "Joel M. Halpern" , diffserv@ietf.org Subject: Re: [Diffserv] EFRESOLVE definition in the presence of excess input burstiness In-Reply-To: <4.3.2.7.2.20001201010751.028aa520@pilgrim.cisco.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: diffserv-admin@ietf.org Errors-To: diffserv-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Diffserv Discussion List X-BeenThere: diffserv@ietf.org > It seems to me that it is OK to drop the packets. If packets are *always* > dropped when the burst is exceeded, then the behavior is always defined and > this is not an issue. But *requiring* dropping may be excessively > restrictive and imposes implementation constraints that are quite > undesirable. We still need to say what happens when the burst is exceeded > but some or all excess packets are not dropped. Currently the behavior is > not defined in that case. I don't see any difference between the solution trying to be redifined for EF and and already defined AF PHB. However, EF PH behavior, somehow, trying to go beyond and delay with "PDB-dependent" (you say topology dependent) parameters. Let me put this way: In general: A_value_to_be_bounded_function(in parameters) < bound_function(in parameters) In AF PHB case: A reference given in the RFC of AF is RIO: bound_function uses max_threshold, and min_threshold and value_bounded_function is avg_queue in order to provide "assured service". There is nothing more on "topology-dependent" parameters. A PDB addresses this issues. In EF PHB case: i) you, Anna: input and output rate are bounded and bound values. Beyond that, in order to bound jitter, more input parameter is used. There are topology-dependent parameters + burstiness issues. It is beyond AF PHB. ii) EFRESOLVE: D(i) - E(i) (delay variance) is being bounded in order to bound jitter with toplogy-dependen parameters + burstiness issues. It is beyond AF PHB. Somehow, I have feeling that both i and ii are approaching to a problem from different directions and will have same solutions (It's just a feeling, I'm not claiming more or anything). I wonder why EF is going beyond. I'm sure if a PHB goes much beyond, It would be easier to build PDBs on top of this. Is this an "end-to-end" argument? Or am I completely in a wrong direction? Alper K. Demir _______________________________________________ diffserv mailing list diffserv@ietf.org http://www1.ietf.org/mailman/listinfo/diffserv Archive: http://www2.ietf.org/mail-archive/working-groups/diffserv/current/maillist.html From diffserv-admin@ietf.org Fri Dec 1 23:10: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 SMTP id XAA25340 for ; Fri, 1 Dec 2000 23:10:34 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id WAA22017; Fri, 1 Dec 2000 22:45:52 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id WAA21986 for ; Fri, 1 Dec 2000 22:45:48 -0500 (EST) Received: from hotmail.com (f3.law10.hotmail.com [64.4.15.3]) by ietf.org (8.9.1a/8.9.1a) with SMTP id WAA22227 for ; Fri, 1 Dec 2000 22:45:45 -0500 (EST) Received: from mail pickup service by hotmail.com with Microsoft SMTPSVC; Fri, 1 Dec 2000 19:45:47 -0800 Received: from 141.213.8.57 by lw10fd.law10.hotmail.msn.com with HTTP; Sat, 02 Dec 2000 03:45:47 GMT X-Originating-IP: [141.213.8.57] From: "Mohamed El Gendy" To: umjayara@unity.ncsu.edu, diffserv@ietf.org Subject: Re: [Diffserv] Doubts with my topology Date: Sat, 02 Dec 2000 05:45:47 +0200 Mime-Version: 1.0 Content-Type: text/plain; format=flowed Message-ID: X-OriginalArrivalTime: 02 Dec 2000 03:45:47.0452 (UTC) FILETIME=[5B225FC0:01C05C12] Sender: diffserv-admin@ietf.org Errors-To: diffserv-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Diffserv Discussion List X-BeenThere: diffserv@ietf.org Uma, What kind of NS Diffserv support you use. There are two known implementations for diffserv on ns-2, the one done by Sean Murphy and the one that was developed by the OpenIP group in Nortel Networks and both of them don't have the modules you had in your code!! Thanks. >From: Uma Jayaraman >To: diffserv@ietf.org >CC: Uma Maheswari Jayaraman >Subject: [Diffserv] Doubts with my topology >Date: Fri, 24 Nov 2000 20:30:35 -0500 (EST) > > >Hi, >The code for the topology drawn below just doesnt seem to work. It is >leaving copies of the packets in the queue. >Please help. >Uma > > >#------------------------------------------------------------------------------- ># UDP ># ------ ># | s1 |----------\ ># ------ 10 Mb \ 5 ms ># 5 ms \----------- 10 Mb -------- ># | diffserv|---------------| dest | ># UDP /----------- -------- ># ------ / ># | s2 |----------/ ># ------ 10 Mb ># 5 ms ># >#------------------------------------------------------------------------------- ># CREATING A NEW SIMULATOR OBJECT >set ns [new Simulator] > >$ns color 10 green >$ns color 11 yellow >$ns color 12 red > >#Defining constants for policer > >set cir0 1000000 >set cbs0 2000 >set pir0 2000000 >set pbs0 3000 >set rate0 3000000 > >set cir1 9000000 >set cbs1 2000 >set pir1 2000000 >set pbs1 3000 >set rate1 3000000 > >#Defining the default packet size [required for RED state variables >set packetSize 1000 >set testTime 10.0 > >set f [open out.tr w] >$ns trace-all $f > >set nf [open out.nam w] >$ns namtrace-all $nf > >proc finish {} { > global ns nf > $ns flush-trace > close $nf > exec nam out.nam & > exit 0 >} > >#Creating nodes for the topology >set s1 [$ns node] >set s2 [$ns node] >set diffserv [$ns node] >set dest [$ns node] > ># To define the links in the topology > >$ns simplex-link $s1 $diffserv 10Mb 5ms DropTail >$ns simplex-link $diffserv $s1 10Mb 5ms dsRED/edge > >$ns simplex-link $s2 $diffserv 10Mb 5ms DropTail >$ns simplex-link $diffserv $s2 10Mb 5ms dsRED/edge > >$ns simplex-link $dest $diffserv 10Mb 5ms DropTail >$ns simplex-link $diffserv $dest 10Mb 5ms dsRED/edge > >#Orienting the direction of the links >$ns duplex-link-op $s1 $diffserv orient down-right >$ns duplex-link-op $s2 $diffserv orient up-right >$ns duplex-link-op $diffserv $dest orient right > >$ns duplex-link-op $diffserv $dest queuePos 0.5 > >#Setting the handles to configure the four DiffServ queues >set qDS_S1 [[$ns link $diffserv $s1] queue] >set qDS_S2 [[$ns link $diffserv $s2] queue] >set qDS_De [[$ns link $diffserv $dest] queue] > >#Setting the DS RED parameters from DS to S1 >$qDS_S1 setSchedularMode PRI >$qDS_S1 meanPktSize $packetSize >$qDS_S1 set numQueues_ 3 >$qDS_S1 setNumPrec 1 >$qDS_S1 addPolicyEntry [$dest id] [$s1 id] trTCM 10 $cir0 $cbs0 $pir0 >$pbs0 >$qDS_S1 addPolicyEntry [$dest id] [$s2 id] trTCM 10 $cir1 $cbs1 $pir1 >$pbs1 >$qDS_S1 addPolicerEntry trTCM 10 11 12 >$qDS_S1 addPHBEntry 10 0 0 >$qDS_S1 addPHBEntry 11 1 0 >$qDS_S1 addPHBEntry 12 2 0 >$qDS_S1 configQ 0 0 20 40 0.02 >$qDS_S1 configQ 0 1 20 40 0.02 >$qDS_S1 configQ 0 2 20 40 0.02 > >#Setting the DS RED parameters from DS to S2 >$qDS_S2 setSchedularMode PRI >$qDS_S2 meanPktSize $packetSize >$qDS_S2 set numQueues_ 3 >$qDS_S2 setNumPrec 1 >$qDS_S2 addPolicyEntry [$dest id] [$s1 id] trTCM 10 $cir0 $cbs0 $pir0 >$pbs0 >$qDS_S2 addPolicyEntry [$dest id] [$s2 id] trTCM 10 $cir1 $cbs1 $pir1 >$pbs1 >$qDS_S2 addPolicerEntry trTCM 10 11 12 >$qDS_S2 addPHBEntry 10 0 0 >$qDS_S2 addPHBEntry 11 1 0 >$qDS_S2 addPHBEntry 12 2 0 >$qDS_S2 configQ 0 0 20 40 0.02 >$qDS_S2 configQ 1 0 20 40 0.02 >$qDS_S2 configQ 2 0 20 40 0.02 > ># Set DS RED parameters from DS to Destination >$qDS_De addQueueRate 0 3000000 >$qDS_De meanPktSize $packetSize >$qDS_De set numQueues_ 3 >$qDS_De setNumPrec 1 >$qDS_De addPolicyEntry [$s1 id] [$dest id] trTCM 10 $cir0 $cbs0 $pir0 >$pbs0 >$qDS_De addPolicyEntry [$s2 id] [$dest id] trTCM 10 $cir1 $cbs1 $pir1 >$pbs1 >$qDS_De addPolicerEntry trTCM 10 11 12 >$qDS_De addPHBEntry 10 0 0 >$qDS_De addPHBEntry 11 1 0 >$qDS_De addPHBEntry 12 2 0 >$qDS_De configQ 0 0 20 40 0.02 >$qDS_De configQ 1 0 20 40 0.02 >$qDS_De configQ 2 0 20 40 0.02 > ># Set up one CBR connection between source and the destination >set tcp0 [new Agent/UDP] >$ns attach-agent $s1 $tcp0 >set cbr0 [new Application/Traffic/CBR] >$cbr0 attach-agent $tcp0 >$cbr0 set packet_size_ $packetSize >$tcp0 set packetSize_ $packetSize >$cbr0 set rate_ $rate0 >set null0 [new Agent/Null] >$ns attach-agent $dest $null0 >$ns connect $tcp0 $null0 > >set udp1 [new Agent/UDP] >$ns attach-agent $s2 $udp1 >set cbr1 [new Application/Traffic/CBR] >$cbr1 attach-agent $udp1 >$cbr1 set packet_size_ $packetSize >$udp1 set packetSize_ $packetSize >$cbr1 set rate_ $rate1 >set null1 [new Agent/Null] >$ns attach-agent $dest $null1 >$ns connect $udp1 $null1 > ># Printing the policy table >#$qDS_S1 printPolicyTable >#$qDS_S2 printPolicyTable >#$qDS_S1 printPolicerTable >#$qDS_S2 printPolicerTable > >$ns at 0.0 "$cbr0 start" >$ns at 0.0 "$cbr1 start" >#$ns at 2.0 "$qDS_De printStats" >#$ns at 4.0 "$qDS_De printStats" >$ns at $testTime "$cbr0 stop" >$ns at $testTime "$cbr1 stop" >$ns at [expr $testTime + 1.0] "finish" > >$ns run > > >******************************* >Uma Jayaraman >Computer Engineering >North Carolina State University >2506,Avent Ferry Road, #201 >Raleigh, NC-27606 >(919)-828-3770 >umjayara@unity.ncsu.edu >******************************* > > >_______________________________________________ >diffserv mailing list >diffserv@ietf.org >http://www1.ietf.org/mailman/listinfo/diffserv >Archive: http://www-nrg.ee.lbl.gov/diff-serv-arch/ > _____________________________________________________________________________________ Get more from the Web. FREE MSN Explorer download : http://explorer.msn.com _______________________________________________ diffserv mailing list diffserv@ietf.org http://www1.ietf.org/mailman/listinfo/diffserv Archive: http://www2.ietf.org/mail-archive/working-groups/diffserv/current/maillist.html From diffserv-admin@ietf.org Sat Dec 2 18:27:31 2000 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with SMTP id SAA24233 for ; Sat, 2 Dec 2000 18:27:31 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id RAA08515; Sat, 2 Dec 2000 17:54:22 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id RAA08490 for ; Sat, 2 Dec 2000 17:54:19 -0500 (EST) Received: from mailhub1.almaden.ibm.com (mailhub1.almaden.ibm.com [198.4.83.44]) by ietf.org (8.9.1a/8.9.1a) with SMTP id RAA20493 for ; Sat, 2 Dec 2000 17:54:16 -0500 (EST) Received: from maui.almaden.ibm.com (maui.almaden.ibm.com [9.1.24.92]) by mailhub1.almaden.ibm.com (8.8.8/8.8.8) with ESMTP id OAA34802; Sat, 2 Dec 2000 14:54:15 -0800 Received: from hursley.ibm.com (gsine04.us.sine.ibm.com [9.14.6.44]) by maui.almaden.ibm.com (AIX4.3/8.9.3/8.7) with ESMTP id OAA09590; Sat, 2 Dec 2000 14:53:44 -0800 Message-ID: <3A297D50.DB550EAB@hursley.ibm.com> Date: Sat, 02 Dec 2000 16:53:04 -0600 From: Brian E Carpenter Organization: IBM X-Mailer: Mozilla 4.61 [en] (Win98; I) X-Accept-Language: en,fr MIME-Version: 1.0 To: demir CC: Anna Charny , "Joel M. Halpern" , diffserv@ietf.org Subject: Re: [Diffserv] EFRESOLVE definition in the presence of excess inputburstiness 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 EFRESOLVE defines a rate and a bound. I don't see any relationship to AF, which doesn't define either. Brian demir wrote: > > > It seems to me that it is OK to drop the packets. If packets are *always* > > dropped when the burst is exceeded, then the behavior is always defined and > > this is not an issue. But *requiring* dropping may be excessively > > restrictive and imposes implementation constraints that are quite > > undesirable. We still need to say what happens when the burst is exceeded > > but some or all excess packets are not dropped. Currently the behavior is > > not defined in that case. > > I don't see any difference between the solution trying to be redifined for > EF and and already defined AF PHB. However, EF PH behavior, somehow, > trying to go beyond and delay with "PDB-dependent" (you say topology > dependent) parameters. Let me put this way: > In general: > A_value_to_be_bounded_function(in parameters) < bound_function(in parameters) > > In AF PHB case: > A reference given in the RFC of AF is RIO: bound_function uses > max_threshold, and min_threshold and value_bounded_function is > avg_queue in order to provide "assured service". > > There is nothing more on "topology-dependent" parameters. A PDB addresses > this issues. > > In EF PHB case: > > i) you, Anna: input and output rate are bounded and bound values. > > Beyond that, in order to bound jitter, more input parameter is used. There > are topology-dependent parameters + burstiness issues. It is beyond AF > PHB. > > ii) EFRESOLVE: D(i) - E(i) (delay variance) is being bounded in order to > bound jitter with toplogy-dependen parameters + burstiness issues. > > It is beyond AF PHB. > Somehow, I have feeling that both i and ii are approaching to a problem > from different directions and will have same solutions (It's just a > feeling, I'm not claiming more or anything). > > I wonder why EF is going beyond. I'm sure if a PHB goes much beyond, It > would be easier to build PDBs on top of this. Is this an > "end-to-end" argument? > > Or am I completely in a wrong direction? > > Alper K. Demir > > _______________________________________________ > diffserv mailing list > diffserv@ietf.org > http://www1.ietf.org/mailman/listinfo/diffserv > Archive: http://www2.ietf.org/mail-archive/working-groups/diffserv/current/maillist.html _______________________________________________ diffserv mailing list diffserv@ietf.org http://www1.ietf.org/mailman/listinfo/diffserv Archive: http://www2.ietf.org/mail-archive/working-groups/diffserv/current/maillist.html From diffserv-admin@ietf.org Sun Dec 3 01:30: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 SMTP id BAA22468 for ; Sun, 3 Dec 2000 01:30:46 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id BAA12017; Sun, 3 Dec 2000 01:02:27 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id BAA11986 for ; Sun, 3 Dec 2000 01:02:22 -0500 (EST) Received: from usc.edu (root@usc.edu [128.125.253.136]) by ietf.org (8.9.1a/8.9.1a) with SMTP id BAA14473 for ; Sun, 3 Dec 2000 01:02:22 -0500 (EST) Received: from koh-sun016.usc.edu (demir@koh-sun016.usc.edu [128.125.5.124]) by usc.edu (8.9.3.1/8.9.3/usc) with ESMTP id WAA19903; Sat, 2 Dec 2000 22:02:21 -0800 (PST) Received: from localhost (demir@localhost) by koh-sun016.usc.edu (8.9.3.1/8.9.3/usc) with ESMTP id WAA01624; Sat, 2 Dec 2000 22:02:21 -0800 (PST) Date: Sat, 2 Dec 2000 22:02:20 -0800 (PST) From: demir To: Brian E Carpenter cc: Anna Charny , "Joel M. Halpern" , diffserv@ietf.org Subject: Re: [Diffserv] EFRESOLVE definition in the presence of excess inputburstiness In-Reply-To: <3A297D50.DB550EAB@hursley.ibm.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: diffserv-admin@ietf.org Errors-To: diffserv-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Diffserv Discussion List X-BeenThere: diffserv@ietf.org Brian, I see a relationship (of course there is no relationship what they define and what "parameters" and "basic building-blocs" (explained later) they use. Otherwise, they would be the same thing) I explained it step by step. My disaggrement with Anna was about "In fact, Diffserv Architecture explicitly says that a PHB definition should describe the behavior when input constraints are violated:"-Anna. I haven't seen such a constraint in any RFC. If there is, could you point it out to me? - First of all, there is no "arrival" rate constraint for AF (I assume we both are agree on this). Actually, there is no constraint other than constraints on how "queueing and discarding" is performed. In general, "queuing, queue management and scheduling" are the most "basic building blocks" where PHBs are built on top. ("rate" (input/output,configured input/output: max,min,avg, etc), "queue length" (max,min,avg,etc), "packet queue delay", MTU, "time" are among the parameters to support the "mechanisms" used to construct "basic building blocks" (What I mean is everything that can be calculated by a PHB itself- I am not sure about "delay variance" cause it may depend on the network topology). As both RED is a "well-known" queue management" mechanism used on "routers" to prevent" congestion collapse" based on a "congestion avoidance" algorithm and it is on the way to be standardized as an "active queue management" mechanism: AF PHB gives both RIO and RED as example "mechanisms" for AF PHB. I assume AF PHB is based on these facts in order to provide both "quantitative" and "qualitative" service guarantees for where PDBs may be responsible. - My point about the relationship is: What AF is trying to bound as a PHB is AVG_QUEUE_LENGTH using max and min threshold values as bounding parameters. In the first definition of EF (RFC-2598), what EF was trying to bound as a PHB was ARRIVAL_RATE using DEPARTURE_RATE as bounding parameter when measured over any time interval equal to or longer than the time it takes to send an output link MTU sized packet at the configured rate. I guess you accept "bounding a papameter/parameters" is a ralationship on a higher-level. What parameters they bound and what "mechanisms" they use will differ them. - My objection: There is no objection related to "rate" used to define "EF RESOLVE". However, there is an objection on a bound "delay variance". i) It is not known that if a PHB can be satisfied using "parameters" that are known by a PHB where "parameters" can be expressed by a PHB independent of network topology and a "parameter" can be calculated by a PHB itself. I have *strong* belief that "delay variance" on a hop is not one of them as "delay variance" depends on network-topology dependent "parameters" if it is expressed in the most efficient way (my intuition says it :) ii) How to express "burstiness" is still going on (I guess). - My result: A PHB should not use network-topology dependent parameters. It should be "blind" to that. PDBs may use them whenever they want :) - I am aware of the fact that EF PHB is trying to bound "delay variance". That's great. I hope someone would come up with a "genious" idea to do that. However, a PHB shouldn't use a topology-dependent parameter at all. Also, if there is no "current aggrement" on a parameter, it shouln't be defined in a PHB. It *always* can be defined in a PDB later. - "First, we want to start out by implementing a simple set of services, which are useful and easy to understand. At the same time, we should not embed these services into the mechanism, but should build a general mechanism that allows us to change the services as our experience matures."- D. Clark / J. Wroclawski, "An Approach to Service Allocation in the Internet" Alper K. Demir On Sat, 2 Dec 2000, Brian E Carpenter wrote: > EFRESOLVE defines a rate and a bound. I don't see any relationship > to AF, which doesn't define either. > > Brian > > demir wrote: > > > > > It seems to me that it is OK to drop the packets. If packets are *always* > > > dropped when the burst is exceeded, then the behavior is always defined and > > > this is not an issue. But *requiring* dropping may be excessively > > > restrictive and imposes implementation constraints that are quite > > > undesirable. We still need to say what happens when the burst is exceeded > > > but some or all excess packets are not dropped. Currently the behavior is > > > not defined in that case. > > > > I don't see any difference between the solution trying to be redifined for > > EF and and already defined AF PHB. However, EF PH behavior, somehow, > > trying to go beyond and delay with "PDB-dependent" (you say topology > > dependent) parameters. Let me put this way: > > In general: > > A_value_to_be_bounded_function(in parameters) < bound_function(in parameters) > > > > In AF PHB case: > > A reference given in the RFC of AF is RIO: bound_function uses > > max_threshold, and min_threshold and value_bounded_function is > > avg_queue in order to provide "assured service". > > > > There is nothing more on "topology-dependent" parameters. A PDB addresses > > this issues. > > > > In EF PHB case: > > > > i) you, Anna: input and output rate are bounded and bound values. > > > > Beyond that, in order to bound jitter, more input parameter is used. There > > are topology-dependent parameters + burstiness issues. It is beyond AF > > PHB. > > > > ii) EFRESOLVE: D(i) - E(i) (delay variance) is being bounded in order to > > bound jitter with toplogy-dependen parameters + burstiness issues. > > > > It is beyond AF PHB. > > Somehow, I have feeling that both i and ii are approaching to a problem > > from different directions and will have same solutions (It's just a > > feeling, I'm not claiming more or anything). > > > > I wonder why EF is going beyond. I'm sure if a PHB goes much beyond, It > > would be easier to build PDBs on top of this. Is this an > > "end-to-end" argument? > > > > Or am I completely in a wrong direction? > > > > Alper K. Demir > > > > _______________________________________________ > > diffserv mailing list > > diffserv@ietf.org > > http://www1.ietf.org/mailman/listinfo/diffserv > > Archive: http://www2.ietf.org/mail-archive/working-groups/diffserv/current/maillist.html > _______________________________________________ diffserv mailing list diffserv@ietf.org http://www1.ietf.org/mailman/listinfo/diffserv Archive: http://www2.ietf.org/mail-archive/working-groups/diffserv/current/maillist.html From diffserv-admin@ietf.org Sun Dec 3 02:01: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 SMTP id CAA07657 for ; Sun, 3 Dec 2000 02:01:16 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id BAA19859; Sun, 3 Dec 2000 01:35:04 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id BAA19832 for ; Sun, 3 Dec 2000 01:34:59 -0500 (EST) Received: from usc.edu (root@usc.edu [128.125.253.136]) by ietf.org (8.9.1a/8.9.1a) with SMTP id BAA24600 for ; Sun, 3 Dec 2000 01:34:58 -0500 (EST) Received: from koh-sun016.usc.edu (demir@koh-sun016.usc.edu [128.125.5.124]) by usc.edu (8.9.3.1/8.9.3/usc) with ESMTP id WAA26730; Sat, 2 Dec 2000 22:34:57 -0800 (PST) Received: from localhost (demir@localhost) by koh-sun016.usc.edu (8.9.3.1/8.9.3/usc) with ESMTP id WAA01680; Sat, 2 Dec 2000 22:34:57 -0800 (PST) Date: Sat, 2 Dec 2000 22:34:57 -0800 (PST) From: demir To: Brian E Carpenter cc: Anna Charny , "Joel M. Halpern" , diffserv@ietf.org Subject: Re: [Diffserv] EFRESOLVE definition in the presence of excess inputburstiness In-Reply-To: <3A297D50.DB550EAB@hursley.ibm.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: diffserv-admin@ietf.org Errors-To: diffserv-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Diffserv Discussion List X-BeenThere: diffserv@ietf.org Brian, As a note: I know that I am refering RIO as if it is a AF PHB (Actually, it is only known candidate to be used for AF PHB). It will not change the relationship that I gave in my previous email. In general, AF PHB is trying to provide different levels of "forwarding assurance". RIO achieves this by using RED where avg_queue is bounded with max and min threshold values. There may exist other mechanisms to achieve the goal of AF PHB. However, I don't think that they will achieve it without bounding any "parameter". Otherwise, it will result with "best-effort" service if related PDB doesn't take any action at the edge of the network. Moreover, you may claim that RED is a "congection avoidance" mechanism used in the "routers" for AF PHB. I think "congestion control and avoidance" are "concepts" that can be used in a QoS Architecture to provide levels of service. In AF PHB, it is described as "different levels of forwarding assurance". In order to give "different levels of forwarding assurance", one should define "different levels of drop". As "randomness" goes to "uniformity", "random drop" may result with "fair drop". That's how I see AF PHB. I assume this still keeps the relationship I gave in my previous email if you agree on it. Alper K. Demir On Sat, 2 Dec 2000, Brian E Carpenter wrote: > EFRESOLVE defines a rate and a bound. I don't see any relationship > to AF, which doesn't define either. > > Brian > > demir wrote: > > > > > It seems to me that it is OK to drop the packets. If packets are *always* > > > dropped when the burst is exceeded, then the behavior is always defined and > > > this is not an issue. But *requiring* dropping may be excessively > > > restrictive and imposes implementation constraints that are quite > > > undesirable. We still need to say what happens when the burst is exceeded > > > but some or all excess packets are not dropped. Currently the behavior is > > > not defined in that case. > > > > I don't see any difference between the solution trying to be redifined for > > EF and and already defined AF PHB. However, EF PH behavior, somehow, > > trying to go beyond and delay with "PDB-dependent" (you say topology > > dependent) parameters. Let me put this way: > > In general: > > A_value_to_be_bounded_function(in parameters) < bound_function(in parameters) > > > > In AF PHB case: > > A reference given in the RFC of AF is RIO: bound_function uses > > max_threshold, and min_threshold and value_bounded_function is > > avg_queue in order to provide "assured service". > > > > There is nothing more on "topology-dependent" parameters. A PDB addresses > > this issues. > > > > In EF PHB case: > > > > i) you, Anna: input and output rate are bounded and bound values. > > > > Beyond that, in order to bound jitter, more input parameter is used. There > > are topology-dependent parameters + burstiness issues. It is beyond AF > > PHB. > > > > ii) EFRESOLVE: D(i) - E(i) (delay variance) is being bounded in order to > > bound jitter with toplogy-dependen parameters + burstiness issues. > > > > It is beyond AF PHB. > > Somehow, I have feeling that both i and ii are approaching to a problem > > from different directions and will have same solutions (It's just a > > feeling, I'm not claiming more or anything). > > > > I wonder why EF is going beyond. I'm sure if a PHB goes much beyond, It > > would be easier to build PDBs on top of this. Is this an > > "end-to-end" argument? > > > > Or am I completely in a wrong direction? > > > > Alper K. Demir > > > > _______________________________________________ > > diffserv mailing list > > diffserv@ietf.org > > http://www1.ietf.org/mailman/listinfo/diffserv > > Archive: http://www2.ietf.org/mail-archive/working-groups/diffserv/current/maillist.html > > _______________________________________________ > diffserv mailing list > diffserv@ietf.org > http://www1.ietf.org/mailman/listinfo/diffserv > Archive: http://www2.ietf.org/mail-archive/working-groups/diffserv/current/maillist.html > _______________________________________________ diffserv mailing list diffserv@ietf.org http://www1.ietf.org/mailman/listinfo/diffserv Archive: http://www2.ietf.org/mail-archive/working-groups/diffserv/current/maillist.html From diffserv-admin@ietf.org Sun Dec 3 03:43: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 SMTP id DAA13725 for ; Sun, 3 Dec 2000 03:43:22 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id DAA21061; Sun, 3 Dec 2000 03:19:59 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id DAA21034 for ; Sun, 3 Dec 2000 03:19:55 -0500 (EST) Received: from usc.edu (root@usc.edu [128.125.253.136]) by ietf.org (8.9.1a/8.9.1a) with SMTP id DAA02265 for ; Sun, 3 Dec 2000 03:19:54 -0500 (EST) Received: from koh-sun016.usc.edu (demir@koh-sun016.usc.edu [128.125.5.124]) by usc.edu (8.9.3.1/8.9.3/usc) with ESMTP id AAA23777; Sun, 3 Dec 2000 00:19:53 -0800 (PST) Received: from localhost (demir@localhost) by koh-sun016.usc.edu (8.9.3.1/8.9.3/usc) with ESMTP id AAA01886; Sun, 3 Dec 2000 00:19:53 -0800 (PST) Date: Sun, 3 Dec 2000 00:19:53 -0800 (PST) From: demir To: Brian E Carpenter cc: diffserv@ietf.org In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Subject: [Diffserv] [EF PHB] A suggestion to support "Queuing and Discarding Behavior" for EF PHB Sender: diffserv-admin@ietf.org Errors-To: diffserv-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Diffserv Discussion List X-BeenThere: diffserv@ietf.org Hi, I have a simple suggestion to support "Queueing and Discarding Behavior" for EF PHB where "Queuing and Discarding" Behavior MAY be supported (something like defined in AF PHB) Someone may ask why?: because the range of services that can be supported can be wider. Someone may ask why do I need "congestion avaidance" for a EF PHB: First of all, it's not a service. If you don't want to deal with it 1) you don't have to implement it 2) If you implement it, but don't want to deal with it: min_threshold=max_threshold=buffer_size or if you have a power to disactivate it in your implementation, you can do it. 3) Trafic conditioners may fail. If input/output rate constraint is not chosen, and input rate becomes an important value, then "congestion collapse" might be a problem. Still, one can have a choice to deal with it or leave it out. 4) It is sad that EF PHB has only one DSCP and no "levels of forwarding assurance". If it did, there could have been much more range of services. Someone might say, it's AF PHB's job to do it: It is a forwarding assurance for EF packets where EF PHB constraints are performed. Someone might say it doesn't make much more sense to provide range of services on top of EF PHB: If it doesn't don't use it. If it does, use it. You are not required to do it. It's just a MAY. However, you never know what will happen in the future. If AF PHB is not too strict about the "drop levels" and "classes", it could have been a buildnig block for EF PHB with it's additional constraints with additional DSCPs. Again: - "First, we want to start out by implementing a simple set of services, which are useful and easy to understand. At the same time, we should not embed these services into the mechanism, but should build a general mechanism that allows us to change the services as our experience matures."- D. Clark / J. Wroclawski, "An Approach to Service Allocation in the Internet" Any comments? Alper K. Demir _______________________________________________ diffserv mailing list diffserv@ietf.org http://www1.ietf.org/mailman/listinfo/diffserv Archive: http://www2.ietf.org/mail-archive/working-groups/diffserv/current/maillist.html From diffserv-admin@ietf.org Sun Dec 3 06:50: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 SMTP id GAA20759 for ; Sun, 3 Dec 2000 06:50:19 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id GAA22612; Sun, 3 Dec 2000 06:21:49 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id GAA22581 for ; Sun, 3 Dec 2000 06:21:45 -0500 (EST) Received: from usc.edu (root@usc.edu [128.125.253.136]) by ietf.org (8.9.1a/8.9.1a) with SMTP id GAA12251 for ; Sun, 3 Dec 2000 06:21:42 -0500 (EST) Received: from koh-sun016.usc.edu (demir@koh-sun016.usc.edu [128.125.5.124]) by usc.edu (8.9.3.1/8.9.3/usc) with ESMTP id DAA15963; Sun, 3 Dec 2000 03:21:32 -0800 (PST) Received: from localhost (demir@localhost) by koh-sun016.usc.edu (8.9.3.1/8.9.3/usc) with ESMTP id DAA02700; Sun, 3 Dec 2000 03:21:27 -0800 (PST) Date: Sun, 3 Dec 2000 03:21:27 -0800 (PST) From: demir To: Brian E Carpenter cc: diffserv@ietf.org Subject: Re: [Diffserv] [EF PHB] A suggestion for EF PHB definition In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: diffserv-admin@ietf.org Errors-To: diffserv-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Diffserv Discussion List X-BeenThere: diffserv@ietf.org Hi, I think the EF PHB defined in RFC-2598 is perfectly fine. A PHB does not have to deal with "delay variance" bound that is topology dependent when it is trying to be defined in an "efficient" way. There is always a gap to define a new PHB when someone comes up with a "proof" that can provide "delay variance" bound using only non-topology dependent "parameters". Also a "parameter" should have a definition where it has a accepted definition. A PDB can have additional constraints such as the one defined in EF PHB: D(i) - E(i) < S*MTU/R As a PDB is build on top of a PHB, all topology dependent parameters (Diffserv domain topology) are welcome to be used and defined however the designer of PDB wants :) All PHBs and PDBs requiring "state" information in the core of the network should be excluded from Diffserv. I think Diffserv is "core-stateless" QoS architecture. It either doesn't keep any state at the core or "state" is carried through packets (this is not the architecture being defined by IETF's Diffserv. As far as I know CMU is working on it). I assume a "stateful" QoS architecture based on PHB and PDB building blocks can use "state" on PHBs and/or PDBs and/or carry the "state" information through network packets. I assume "stateless" QoS architectures might emerge when bandwidth is plentiful and a domain is "over-provisioned" and it is known that network traffic won't have any effect on the "over-provisioned" network. Otherwise, it will have only "best-effort" service. Any comment is appreciated. Alper K. Demir _______________________________________________ diffserv mailing list diffserv@ietf.org http://www1.ietf.org/mailman/listinfo/diffserv Archive: http://www2.ietf.org/mail-archive/working-groups/diffserv/current/maillist.html From diffserv-admin@ietf.org Sun Dec 3 09:25: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 SMTP id JAA07273 for ; Sun, 3 Dec 2000 09:25:06 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id JAA24059; Sun, 3 Dec 2000 09:00:06 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id JAA23994 for ; Sun, 3 Dec 2000 09:00:01 -0500 (EST) Received: from itc-eml2.lannet.com (at.lannet.com [194.90.94.231]) by ietf.org (8.9.1a/8.9.1a) with SMTP id IAA29065 for ; Sun, 3 Dec 2000 08:59:58 -0500 (EST) Received: by itc-eml2.lannet.com with Internet Mail Service (5.5.2650.21) id ; Sun, 3 Dec 2000 15:59:34 +0200 Message-ID: <15F58915DF84D311AC7D0090279AA6142341E0@itc-eml2.lannet.com> From: Dan Romascanu To: "'Robert Moore'" , Kwok-Ho Chan Cc: diffserv@ietf.org, abierman@cisco.com Subject: RE: [Diffserv] DiffServ MIB -06: statistics Date: Sun, 3 Dec 2000 15:59:33 +0200 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 > Andrew has sent me off in another direction on this question: > to the RMON WG's DiffServ Monitoring MIB. Since DSCPs are > visible in the packet headers, a probe-based approach is > certainly possible for determining the distribution of DSCPs > sent to or from a particular device via a particular > interface. > > I think that we will probably end up putting a table of the > form I suggested into our hosts. But I can understand that > router vendors might prefer to have the performance penalty > of what will ordinarily be an extra 64-way classification > fall onto a probe rather than onto their router interfaces. > Bob, There is no need to invent something new. This is exactly what the dssonStatsTable counters in the DS-MON MIB do, and they apply to the device interfaces via the RMON dataSource mechanism. In this case 'the probe is the diffserv host', or better say 'the probe is embedded within the diffserv host'. Regards, Dan > _______________________________________________ diffserv mailing list diffserv@ietf.org http://www1.ietf.org/mailman/listinfo/diffserv Archive: http://www2.ietf.org/mail-archive/working-groups/diffserv/current/maillist.html From diffserv-admin@ietf.org Sun Dec 3 14:17:21 2000 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with SMTP id OAA02711 for ; Sun, 3 Dec 2000 14:17:21 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id NAA26694; Sun, 3 Dec 2000 13:49:20 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id NAA26663 for ; Sun, 3 Dec 2000 13:49:16 -0500 (EST) Received: from seralph10.essex.ac.uk (seralph10.essex.ac.uk [155.245.240.160]) by ietf.org (8.9.1a/8.9.1a) with SMTP id NAA23497 for ; Sun, 3 Dec 2000 13:49:04 -0500 (EST) Received: from sernt12.essex.ac.uk ([155.245.240.181]) by seralph10.essex.ac.uk with esmtp (Exim 3.13 #1) id 142eCH-0001WJ-00 for diffserv@ietf.org; Sun, 03 Dec 2000 18:49:13 +0000 Received: by sernt12.essex.ac.uk with Internet Mail Service (5.5.2650.21) id ; Sun, 3 Dec 2000 18:47:05 -0000 Message-ID: <51884AFB9193D41192D90002B30A0F1A0128B832@sernt12.essex.ac.uk> From: "Flores Mosri, Alejandra" To: "'diffserv@ietf.org'" Date: Sun, 3 Dec 2000 18:47:04 -0000 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: text/plain; charset="iso-8859-1" Subject: [Diffserv] RTP and diffserv Sender: diffserv-admin@ietf.org Errors-To: diffserv-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Diffserv Discussion List X-BeenThere: diffserv@ietf.org Hello, I have read about RSVP and diffserv, but can anyone tell me if there is a draft about RTP (RTCP) and diffserv? Thanks in advance ______________________________________________ Alejandra Flores PhD Research Student Multimedia Communications Research Laboratory Department of Electronic Systems Engineering University of Essex United Kingdom e-mail: afloreb@essex.ac.uk tel.: +44 1206 872442 & +44 1206 872448 _______________________________________________ diffserv mailing list diffserv@ietf.org http://www1.ietf.org/mailman/listinfo/diffserv Archive: http://www2.ietf.org/mail-archive/working-groups/diffserv/current/maillist.html From diffserv-admin@ietf.org Mon Dec 4 00:51: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 SMTP id AAA12211 for ; Mon, 4 Dec 2000 00:51:06 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id AAA02295; Mon, 4 Dec 2000 00:13:12 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id AAA02264 for ; Mon, 4 Dec 2000 00:13:04 -0500 (EST) Received: from mta6.snfc21.pbi.net (mta6.snfc21.pbi.net [206.13.28.240]) by ietf.org (8.9.1a/8.9.1a) with SMTP id AAA04992 for ; Mon, 4 Dec 2000 00:13:03 -0500 (EST) Received: from allegronetworks.com ([206.170.1.243]) by mta6.snfc21.pbi.net (Sun Internet Mail Server sims.3.5.2000.01.05.12.18.p9) with ESMTP id <0G5100CW6276T2@mta6.snfc21.pbi.net> for diffserv@ietf.org; Sun, 3 Dec 2000 21:06:44 -0800 (PST) Date: Sun, 03 Dec 2000 21:14:34 -0800 From: Andrew Smith Subject: Re: [Diffserv] DiffServ MIB -06: statistics To: Dan Romascanu Cc: rmonmib , diffserv@ietf.org Message-id: <3A2B283A.9050300@allegronetworks.com> Organization: Allegro Networks MIME-version: 1.0 Content-type: text/plain; charset=us-ascii; format=flowed Content-transfer-encoding: 7bit User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; m18) Gecko/20001108 Netscape6/6.0 X-Accept-Language: en References: <15F58915DF84D311AC7D0090279AA6142341E0@itc-eml2.lannet.com> Content-Transfer-Encoding: 7bit Sender: diffserv-admin@ietf.org Errors-To: diffserv-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Diffserv Discussion List X-BeenThere: diffserv@ietf.org Content-Transfer-Encoding: 7bit Of course, that does beg the question as to why we are not using "dataSource" instead of "ifIndex" to index the diffserv MIB tables ... BTW, I assume that the diffserv WG will also run a last-call of the DSMON MIB since the "subject-matter experts" are supposedly on that list. Andrew Dan Romascanu wrote: >> Andrew has sent me off in another direction on this question: >> to the RMON WG's DiffServ Monitoring MIB. Since DSCPs are >> visible in the packet headers, a probe-based approach is >> certainly possible for determining the distribution of DSCPs >> sent to or from a particular device via a particular >> interface. >> >> I think that we will probably end up putting a table of the >> form I suggested into our hosts. But I can understand that >> router vendors might prefer to have the performance penalty >> of what will ordinarily be an extra 64-way classification >> fall onto a probe rather than onto their router interfaces. >> > > Bob, > > There is no need to invent something new. This is exactly what the > dssonStatsTable counters in the DS-MON MIB do, and they apply to the device > interfaces via the RMON dataSource mechanism. In this case 'the probe is the > diffserv host', or better say 'the probe is embedded within the diffserv > host'. > > Regards, > > Dan _______________________________________________ diffserv mailing list diffserv@ietf.org http://www1.ietf.org/mailman/listinfo/diffserv Archive: http://www2.ietf.org/mail-archive/working-groups/diffserv/current/maillist.html From diffserv-admin@ietf.org Mon Dec 4 00:51:08 2000 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with SMTP id AAA12224 for ; Mon, 4 Dec 2000 00:51:08 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id AAA02418; Mon, 4 Dec 2000 00:21:48 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id AAA02387 for ; Mon, 4 Dec 2000 00:21:43 -0500 (EST) Received: from rip.psg.com (exim@rip.psg.com [147.28.0.39]) by ietf.org (8.9.1a/8.9.1a) with SMTP id AAA05978 for ; Mon, 4 Dec 2000 00:21:43 -0500 (EST) Received: from randy by rip.psg.com with local (Exim 3.16 #1) id 142o3m-000O6r-00; Sun, 03 Dec 2000 21:21:06 -0800 From: Randy Bush MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit To: Andrew Smith Cc: snmpconf@snmp.com, diffserv References: <2413FED0DFE6D111B3F90008C7FA61FB0A4AE5E8@nl0006exch002u.nl.lucent.com> <3A2A9251.E8C87BF6@mediaone.net> <3A2B2693.7000800@allegronetworks.com> Message-Id: Date: Sun, 03 Dec 2000 21:21:06 -0800 Content-Transfer-Encoding: 7bit Subject: [Diffserv] Re: snmpconf FW: November Milestones Sender: diffserv-admin@ietf.org Errors-To: diffserv-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Diffserv Discussion List X-BeenThere: diffserv@ietf.org Content-Transfer-Encoding: 7bit [ operator hat only ] we do a LOT of reads, so many that we have to gang boxes to do them, and write tools to manage the poller array. if we were to do snmp config, i presume it would be FAR fewer operations than the polls and other gets. randy _______________________________________________ diffserv mailing list diffserv@ietf.org http://www1.ietf.org/mailman/listinfo/diffserv Archive: http://www2.ietf.org/mail-archive/working-groups/diffserv/current/maillist.html From diffserv-admin@ietf.org Mon Dec 4 01:07: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 SMTP id BAA16067 for ; Mon, 4 Dec 2000 01:07:33 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id AAA02972; Mon, 4 Dec 2000 00:41:16 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id AAA02942 for ; Mon, 4 Dec 2000 00:41:11 -0500 (EST) Received: from mta5.snfc21.pbi.net (mta5.snfc21.pbi.net [206.13.28.241]) by ietf.org (8.9.1a/8.9.1a) with SMTP id AAA10054 for ; Mon, 4 Dec 2000 00:41:11 -0500 (EST) Received: from allegronetworks.com ([206.170.1.243]) by mta5.snfc21.pbi.net (Sun Internet Mail Server sims.3.5.2000.01.05.12.18.p9) with ESMTP id <0G5100HVG1W9JN@mta5.snfc21.pbi.net> for diffserv@ietf.org; Sun, 3 Dec 2000 21:00:11 -0800 (PST) Date: Sun, 03 Dec 2000 21:07:31 -0800 From: Andrew Smith To: snmpconf@snmp.com, diffserv Cc: Jon Saperia , Randy Bush Message-id: <3A2B2693.7000800@allegronetworks.com> Organization: Allegro Networks MIME-version: 1.0 Content-type: text/plain; charset=us-ascii; format=flowed Content-transfer-encoding: 7bit User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; m18) Gecko/20001108 Netscape6/6.0 X-Accept-Language: en References: <2413FED0DFE6D111B3F90008C7FA61FB0A4AE5E8@nl0006exch002u.nl.lucent.com> <3A2A9251.E8C87BF6@mediaone.net> Content-Transfer-Encoding: 7bit Subject: [Diffserv] Re: snmpconf FW: November Milestones Sender: diffserv-admin@ietf.org Errors-To: diffserv-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Diffserv Discussion List X-BeenThere: diffserv@ietf.org Content-Transfer-Encoding: 7bit From a thread from the snmpconf WG: > Jon wrote: >> Configuration is the heart of management. To the extent MIB Documents >> are created in each of the different technology areas such as routing or >> differentiated services (which is the right place), they should be >> designed for full coverage including configuration. There is no excuse >> not to. > Randy wrote: > i do not intend to discourage those who wish to design for write from doing > so. but i am not sure i see a need to mandate it when doing so would cause > complexity or architectural change. and i believe that, and only that, was > the question (in the tewg) that [re]started this rathole. > > randy Randy's point is well made - I don't think it is a rathole - and is directly relevant to the MIB/PIB/snmpconf/DSMON discussions for diffserv management. In the various iterations of the diffserv MIB we have veered between extremes of optimise-for-read and optimise-for-configure without, I think, a clear idea of why. The -04 version tended towards the former whilst the latest incarnation (-06) veers back towards the latter in the interests of consistency with the PIB work and the "template" concept for the diffserv policy MIB (snmpconf WG). Should we treat these as valid reasons to sacrifice read performance or should we find another way to optimise opbjects for configuration e.g. by duplication (indexing of same information in multiple ways)? Right now, I believe the -06 MIB does cause additional complexity for reading. Andrew _______________________________________________ diffserv mailing list diffserv@ietf.org http://www1.ietf.org/mailman/listinfo/diffserv Archive: http://www2.ietf.org/mail-archive/working-groups/diffserv/current/maillist.html From diffserv-admin@ietf.org Mon Dec 4 01:49: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 SMTP id BAA01289 for ; Mon, 4 Dec 2000 01:49:07 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id BAA11106; Mon, 4 Dec 2000 01:25:26 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id BAA11075 for ; Mon, 4 Dec 2000 01:25:22 -0500 (EST) Received: from cisco.com (ups.cisco.com [171.69.18.21]) by ietf.org (8.9.1a/8.9.1a) with SMTP id BAA20627 for ; Mon, 4 Dec 2000 01:25:20 -0500 (EST) Received: (from kzm@localhost) by cisco.com (8.8.8/2.6/Cisco List Logging/8.8.8) id WAA18390; Sun, 3 Dec 2000 22:24:49 -0800 (PST) From: Keith McCloghrie Message-Id: <200012040624.WAA18390@cisco.com> Subject: Re: [Diffserv] DiffServ MIB -06: statistics To: andrew@allegronetworks.com (Andrew Smith) Date: Sun, 3 Dec 2000 22:24:49 -0800 (PST) Cc: dromasca@avaya.com (Dan Romascanu), rmonmib@cisco.com (rmonmib), diffserv@ietf.org In-Reply-To: <3A2B283A.9050300@allegronetworks.com> from "Andrew Smith" at Dec 03, 2000 09:14:34 PM X-Mailer: ELM [version 2.5 PL1] MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: diffserv-admin@ietf.org Errors-To: diffserv-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Diffserv Discussion List X-BeenThere: diffserv@ietf.org Content-Transfer-Encoding: 7bit > BTW, I assume that the diffserv WG will also run a last-call of the DSMON MIB > since the "subject-matter experts" are supposedly on that list. I doubt it: 1. the DSMON MIB is intended for a (logical) probe, rather than for a (logical) router. (That's not to say that an actual router can't perform both functions, but that's true of most RMON MIBs). 2. the DSMON MIB was submitted to the RMON WG only after the DiffServ WG chair said that it wasn't wanted in the DiffServ WG. 3. the DiffServ MIB already contains a (complicated) set of DiffServ counters for a router to implement, many of which are not appropriate for a (physical) probe to implement. Keith. _______________________________________________ diffserv mailing list diffserv@ietf.org http://www1.ietf.org/mailman/listinfo/diffserv Archive: http://www2.ietf.org/mail-archive/working-groups/diffserv/current/maillist.html From diffserv-admin@ietf.org Mon Dec 4 09:09: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 SMTP id JAA27871 for ; Mon, 4 Dec 2000 09:09:41 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id IAA16657; Mon, 4 Dec 2000 08:47:13 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id IAA16626 for ; Mon, 4 Dec 2000 08:47:08 -0500 (EST) Received: from chmls20.mediaone.net (chmls20.mediaone.net [24.147.1.156]) by ietf.org (8.9.1a/8.9.1a) with SMTP id IAA21795 for ; Mon, 4 Dec 2000 08:47:08 -0500 (EST) Received: from mediaone.net (h0001027441c5.ne.mediaone.net [24.128.61.165]) by chmls20.mediaone.net (8.8.7/8.8.7) with ESMTP id IAA29196; Mon, 4 Dec 2000 08:46:32 -0500 (EST) Message-ID: <3A2BA02D.1FA4582B@mediaone.net> Date: Mon, 04 Dec 2000 08:46:21 -0500 From: Jon Saperia Organization: JDS Consulting, Inc X-Mailer: Mozilla 4.7 [en] (X11; I; SunOS 5.8 sun4u) X-Accept-Language: en MIME-Version: 1.0 To: snmpconf@snmp.com CC: diffserv , Randy Bush References: <2413FED0DFE6D111B3F90008C7FA61FB0A4AE5E8@nl0006exch002u.nl.lucent.com> <3A2A9251.E8C87BF6@mediaone.net> <3A2B2693.7000800@allegronetworks.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Subject: [Diffserv] Re: snmpconf FW: November Milestones Sender: diffserv-admin@ietf.org Errors-To: diffserv-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Diffserv Discussion List X-BeenThere: diffserv@ietf.org Content-Transfer-Encoding: 7bit > Randy's point is well made - I don't think it is a rathole - and is directly > relevant to the MIB/PIB/snmpconf/DSMON discussions for diffserv management. In > the various iterations of the diffserv MIB we have veered between extremes of > optimise-for-read and optimise-for-configure without, I think, a clear idea of > why. The -04 version tended towards the former whilst the latest incarnation > (-06) veers back towards the latter in the interests of consistency with the PIB > work and the "template" concept for the diffserv policy MIB (snmpconf WG). > Should we treat these as valid reasons to sacrifice read performance or should > we find another way to optimise opbjects for configuration e.g. by duplication > (indexing of same information in multiple ways)? Right now, I believe the -06 > MIB does cause additional complexity for reading. > > Andrew > It is often the case that read only MIB documents are not well designed in a number of respects. Relevant to this discussion is that the indices are often created with implementation ease in mind. It is more difficult to implement a table with multiple indices (regardless of basic technology) than to use simple integer index values. This is true whether the objects are read only or read write. This poor design, while easy for software engineers, causes unnecessary data collection overhead since it is more difficult to 'scope' what you want to retrieve (Randy indirectly alluded to this in a previous post). In some cases, the design makes it quite difficult not mater how much data you collect to understand what it means in terms of the configuration. My view is that the additional complexity for configuration will pay off in terms of better quality data and less data movement. This is not to say -06 is just right, there are other who can better assess that. My point is that it is worth the work. /jon _______________________________________________ diffserv mailing list diffserv@ietf.org http://www1.ietf.org/mailman/listinfo/diffserv Archive: http://www2.ietf.org/mail-archive/working-groups/diffserv/current/maillist.html From diffserv-admin@ietf.org Mon Dec 4 10: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 SMTP id KAA19032 for ; Mon, 4 Dec 2000 10:16:47 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id JAA17738; Mon, 4 Dec 2000 09:53:44 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id JAA17716 for ; Mon, 4 Dec 2000 09:53:41 -0500 (EST) Received: from unknown (ts008d15.atl-ga.concentric.net [64.1.55.123]) by ietf.org (8.9.1a/8.9.1a) with SMTP id JAA11679 for ; Mon, 4 Dec 2000 09:53:39 -0500 (EST) From: To: Date: Mon, 4 Dec 2000 06:18:42 Message-Id: <109.460612.823015@> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Subject: [Diffserv] updated pricing Sender: diffserv-admin@ietf.org Errors-To: diffserv-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Diffserv Discussion List X-BeenThere: diffserv@ietf.org Content-Transfer-Encoding: 7bit Vortex Supplies Toner Supplies at discount prices Laser Printer Toner Cartridges Fax and Copier Cartridges Order now direct from the company that sells wholesale to your local retail stores and save up to 30% on your purchase. Order by phone:1-888-288-9043 Order by fax: 1-888-977-1577 *** E-mail removal line: 1-888-248-4930 *** Pay by check, credit card or Purchase Order. If your order is by check please leave your check number (Mail check when you receive merchandise) If your order is by credit card please leave your card number + expiration date If your order is by P.O. please leave your shipping/billing addresses and you Purchase Order number. Current Prices are as follows: Cartridges for Hewlett Packard printers: 4L,4p,1100 and series 2 cartridges are now $49 2p cartridges are $54 3si cartridges are $75 4000 and 2100 cartridges are $79 5000 and 8100 cartridges are $135 5p, 6p, 5mp and 6mp cartridges are $59 Cartridges for Apple printers Pro 600 or 16-600 cartridges are now $69 Laser writer select 300,320 and 360 cartridges are $69 Laser writer 300 and 320 cartridges are $54 Laser writer NT, 2nt, 2f, 2g and LS cartridges are $54 Laser writer personal 12-640 cartridges are $79 Cartridges for Hewlett Packard laser fax printers: Laser fax 500,700,5000,7000,fx1 and fx2 cartridges are now $59 Laser fax fx3 cartridges are $69 Our laser fax fx4 cartridges are $79 Cartridges for Lexmark and IBM printers Optra 4019 and 4029 are now $125 optra r,r+ and optra s cartridges are $135 optra e cartridges are $59 Our cartridges for canon copiers PC 3, 6re, 7 and 11 (A30) are now $69 PC 300,320,700,720 and 760 (E-40) are $89 90 day extended warranty included on all products. _______________________________________________ diffserv mailing list diffserv@ietf.org http://www1.ietf.org/mailman/listinfo/diffserv Archive: http://www2.ietf.org/mail-archive/working-groups/diffserv/current/maillist.html From diffserv-admin@ietf.org Mon Dec 4 14: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 SMTP id OAA11772 for ; Mon, 4 Dec 2000 14:49:02 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id OAA22749; Mon, 4 Dec 2000 14:22:26 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id OAA22721 for ; Mon, 4 Dec 2000 14:22:22 -0500 (EST) Received: from pmesmtp01.wcom.com (pmesmtp01.wcom.com [199.249.20.1]) by ietf.org (8.9.1a/8.9.1a) with SMTP id OAA05910 for ; Mon, 4 Dec 2000 14:22:20 -0500 (EST) Received: from CONVERSION-DAEMON by firewall.mcit.com (PMDF V5.2-32 #42256) id <0G5200E015QRRP@firewall.mcit.com> for diffserv@ietf.org; Mon, 4 Dec 2000 19:20:51 +0000 (GMT) Received: from pmismtp01.wcomnet.com ([166.38.62.36]) by firewall.mcit.com (PMDF V5.2-32 #42256) with ESMTP id <0G5200D965QROP@firewall.mcit.com> for diffserv@ietf.org; Mon, 04 Dec 2000 19:20:51 +0000 (GMT) Received: from CONVERSION-DAEMON by pmismtp01.wcomnet.com (PMDF V5.2-33 #42258) id <0G5200E015QQ3O@pmismtp01.wcomnet.com> for diffserv@ietf.org; Mon, 04 Dec 2000 19:20:50 +0000 (GMT) Received: from pmismtp01.wcomnet.com by pmismtp01.wcomnet.com (PMDF V5.2-33 #42258) with SMTP id <0G5200E015QI1R@pmismtp01.wcomnet.com> for diffserv@ietf.org; Mon, 04 Dec 2000 19:20:50 +0000 (GMT) Received: from omzexch006.mcit.com ([166.37.194.37]) by pmismtp01.wcomnet.com (PMDF V5.2-33 #42258) with ESMTP id <0G5200D2M5QH9A@pmismtp01.wcomnet.com> for diffserv@ietf.org; Mon, 04 Dec 2000 19:20:41 +0000 (GMT) Received: by omzexch006 with Internet Mail Service (5.5.2651.58) id ; Mon, 04 Dec 2000 19:20:41 +0000 Content-return: allowed Date: Mon, 04 Dec 2000 19:20:33 +0000 From: "Iliff, Tina" To: "'diffserv@ietf.org'" Message-id: <492EB4A3F68CD411ABE800508B69362E14B3A9@RIPEXCH002.wcomnet.com> MIME-version: 1.0 X-Mailer: Internet Mail Service (5.5.2651.58) Content-type: multipart/alternative; boundary="Boundary_(ID_kzlJ/SapuFvorF3NMBdXug)" Subject: [Diffserv] diffserv-pib-02 Sender: diffserv-admin@ietf.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. --Boundary_(ID_kzlJ/SapuFvorF3NMBdXug) Content-type: text/plain; charset=ISO-8859-1 List, After reading the latest diffserv PIB draft, diffserv-pib-02 I have the following issues/questions: 1. It seems contradictory that the qosIfClassificationCaps class provides the PEP with the flexibility to or not to support classification on ingress and the explanation of the qosClfrElementOrder attribute contains the following statement: "On a given interface, there must be a complete classifier in place at all times in the ingress direction. This means that there will always be one or more filters that match every possible pattern that could be presented in an incoming packet. There is no such requirement in the egress direction." It makes more sense to mandate a classifier on ingress since there needs to be some way of determining which packets should be treated by each specific datapath element configuration. Can someone please clarify. Recommend removing the possible value (i.e. inputIpClassification) from the qosIfClassificationCapsSpec. 2. qosIfSchedulingCaps: Please clarify the proposed use of the QueueSize and TotalQueueSize attributes given the new PIB structure(specifically the structure of the install classes). Thanks, Tina --Boundary_(ID_kzlJ/SapuFvorF3NMBdXug) Content-type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable diffserv-pib-02

List,

After reading the latest diffserv PIB = draft, diffserv-pib-02 I have the following issues/questions:

    1.  It seems contradictory that = the qosIfClassificationCaps class provides the PEP with the flexibility = to or not to support classification on ingress and the explanation of = the qosClfrElementOrder attribute contains the following = statement:  "On a given = interface, there must be a = complete  classifier  = in  place  at  all  times in   the = ingress direction.  This means that there will always be one or = more filters that match every possible pattern  that  could = be presented in an incoming packet.  There is no such requirement = in the egress direction."  It = makes more sense to mandate a classifier on ingress since there needs = to be some way of determining which packets should be treated by each = specific datapath element configuration.  Can someone please = clarify.  Recommend removing the possible value (i.e. = inputIpClassification) from the qosIfClassificationCapsSpec.

    1. qosIfSchedulingCaps:  Please clarify the proposed = use of the QueueSize and TotalQueueSize attributes given the new PIB = structure(specifically the structure of the install = classes).

    Thanks,
    Tina

--Boundary_(ID_kzlJ/SapuFvorF3NMBdXug)-- _______________________________________________ diffserv mailing list diffserv@ietf.org http://www1.ietf.org/mailman/listinfo/diffserv Archive: http://www2.ietf.org/mail-archive/working-groups/diffserv/current/maillist.html From diffserv-admin@ietf.org Mon Dec 4 14:56: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 SMTP id OAA13619 for ; Mon, 4 Dec 2000 14:56:05 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id OAA23121; Mon, 4 Dec 2000 14:35:25 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id OAA23081 for ; Mon, 4 Dec 2000 14:35:19 -0500 (EST) Received: from mta6.snfc21.pbi.net (mta6.snfc21.pbi.net [206.13.28.240]) by ietf.org (8.9.1a/8.9.1a) with SMTP id OAA08665 for ; Mon, 4 Dec 2000 14:35:16 -0500 (EST) Received: from allegronetworks.com ([206.170.1.5]) by mta6.snfc21.pbi.net (Sun Internet Mail Server sims.3.5.2000.01.05.12.18.p9) with ESMTP id <0G52000494KHZZ@mta6.snfc21.pbi.net> for diffserv@ietf.org; Mon, 4 Dec 2000 10:55:31 -0800 (PST) Date: Mon, 04 Dec 2000 11:03:22 -0800 From: Andrew Smith Subject: Re: [Diffserv] draft-ietf-diffserv-model-04.txt - what does it mean To: Brian E Carpenter Cc: diffserv Message-id: <3A2BEA7A.2080907@allegronetworks.com> Organization: Allegro Networks MIME-version: 1.0 Content-type: text/plain; charset=us-ascii; format=flowed Content-transfer-encoding: 7bit User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; m18) Gecko/20001108 Netscape6/6.0 X-Accept-Language: en References: <3A26DE80.BFD20151@hursley.ibm.com> <3A27F3E8.10202@pacbell.net> <3A281163.8ED9BB04@hursley.ibm.com> Content-Transfer-Encoding: 7bit Sender: diffserv-admin@ietf.org Errors-To: diffserv-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Diffserv Discussion List X-BeenThere: diffserv@ietf.org Content-Transfer-Encoding: 7bit You see, I don't believe in this thing called "best effort" when you get down to the details of the per-hop thing: we insist that all arriving traffic meets a complete classifier and is divided into classes. Each class gets a specific treatment (e.g. access to forwarding, buffering or scheduling resources) *in relation to all the other classes*. There is no "special case", "default" or "other" treatment - everything needs to be specified. You should be able to model a (2-port) non-diffserv router as a classifier that matches everything, followed by a FIFO queue that gets access to all the buffering in the box, served by a scheduler that gets 100% of the line bandwidth, whenever there is data to send i.e. I believe that there is no such, at this level of the model, as "as if diffserv didn't exist". Andrew Brian E Carpenter wrote: > Fair enough, we can clarify it, but am I right that it means > that the packet is simply inserted into the data path as if > diffserv didn't exist (which is presumably equivalent to > treating it as BE)? > > Brian > > Andrew Smith wrote: > >> Brian, >> >> I'm not sure that it is good enough to leave this as an implementation detail: >> it seems to me that this is needs to be declared as either (a) an >> invalid/incomplete configuration or (b) a valid configuration with well-defined >> results. We don't currently have any sort of catch-all "if any part of the DS >> configuration following along a particular datapath is currently invalid, then >> the classifier element that leads to this datapath is considered to be >> not-in-service" rule to handle (a) and I'm not sure how to phrase (b). But I do >> agree with Bob that we need to address the issue more clearly in the draft. >> >> Andrew >> >> Brian E Carpenter wrote: >> >> >>> Bob, >>> >>> I've always interpreted this phrase to mean that the packet >>> goes back into the data path it would be on if the router >>> knew nothing about diffserv. Whether that is the lowest >>> priority queue seems to be an implementation detail. >>> >>> Brian >>> >>> Robert Moore wrote: >>> >>> >>>> Hi Kwok, >>>> >>>> I'll have to say that even with the -06 version of the MIB, >>>> I still can't say that I really understand how this works. >>>> Take the following example for an egress interface. The >>>> example isn't intended to be realistic -- just to illustrate >>>> my point with the smallest number of elements: >>>> >>>> +------+ +---------+ >>>> | ----|------>Q1(high)-->|Priority | >>>> DataPath |/ | |Scheduler|-->zeroDotZero >>>> Start--->|------|------>Q2(low)--->| | >>>> |\ | +---------+ >>>> | ----|--->zeroDotZero >>>> +------+ >>>> >>>> Clearly packets from the top branch of the classifier, >>>> coming from the higher priority queue, will be >>>> scheduled out ahead of packets from the middle branch, >>>> which has the lower priority queue. But how will packets >>>> from the bottom branch be scheduled out, relative to >>>> those from the top two branches? What does it mean for >>>> these packets to receive "no further DiffServ treatment," >>>> relative to packets from the other two branches, which >>>> do receive this treatment? >>>> >>>> I could make up an answer here: packets on the bottom >>>> branch are treated as if they were on a lowest priority >>>> queue serviced by this same Priority Scheduler. But I'd >>>> be more comfortable if there were something in either >>>> the MIB or the Informal Model that I could point to, >>>> implying that this answer is the correct one. >>>> >>>> Regards, >>>> Bob >>>> >>>> Bob Moore >>>> IBM Networking Software >>>> +1-919-254-4436 >>>> remoore@us.ibm.com >>>> >>>> "Kwok-Ho Chan" @ietf.org on 11/16/2000 12:02:58 >>>> PM >>>> >>>> Sent by: diffserv-admin@ietf.org >>>> >>>> To: Erez Bashan >>>> cc: diffserv >>>> Subject: Re: [Diffserv] draft-ietf-diffserv-model-04.txt - what does it >>>> mean "no further Diffserv treatment is performed" ? >>>> >>>> Meaning of "no further DiffServ treatment is performed", as quoted from >>>> DSMIB-05 section 3.1.1: >>>> "allow normal IP device processing", "Normal IP device processing >>>> will depend on the device, for example, this can be forwarding the packet." >>>> >>>> Is this sufficient? May be I should move this explanation to the >>>> RowPointer >>>> section (5.1), but that section maybe changed in a more dramatic way >>>> depending on the outcome of the "Instance Amplification" discussion thread. >>>> >>>> -- Kwok -- >>>> >>>> At 03:24 PM 11/16/00 +0200, Erez Bashan wrote: >>>> >>>> >>>>> In several places in the MIB (for example if the diffServMeterFailNext has >>>> >>>> a >>>> >>>> >>>>> value of "value of zeroDotZero") a scenario exists in which "no further >>>>> Diffserv treatment is performed" on certain traffic. >>>>> >>>>> What does it mean ? Is the packet dropped, or should it be handled by >>>>> another independent (??) mechanism in the router ? If it is to be dropped, >>>>> why isn't it says so explicitly ? >>>>> >>>>> Erez >>>> > > _______________________________________________ > diffserv mailing list > diffserv@ietf.org > http://www1.ietf.org/mailman/listinfo/diffserv > Archive: http://www2.ietf.org/mail-archive/working-groups/diffserv/current/maillist.html _______________________________________________ diffserv mailing list diffserv@ietf.org http://www1.ietf.org/mailman/listinfo/diffserv Archive: http://www2.ietf.org/mail-archive/working-groups/diffserv/current/maillist.html From diffserv-admin@ietf.org Mon Dec 4 14:57: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 SMTP id OAA13867 for ; Mon, 4 Dec 2000 14:57:08 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id OAA23152; Mon, 4 Dec 2000 14:35:31 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id OAA23089 for ; Mon, 4 Dec 2000 14:35:23 -0500 (EST) Received: from mta6.snfc21.pbi.net (mta6.snfc21.pbi.net [206.13.28.240]) by ietf.org (8.9.1a/8.9.1a) with SMTP id OAA08666 for ; Mon, 4 Dec 2000 14:35:16 -0500 (EST) Received: from allegronetworks.com ([206.170.1.5]) by mta6.snfc21.pbi.net (Sun Internet Mail Server sims.3.5.2000.01.05.12.18.p9) with ESMTP id <0G52000SU4K0WR@mta6.snfc21.pbi.net> for diffserv@ietf.org; Mon, 4 Dec 2000 10:55:19 -0800 (PST) Date: Mon, 04 Dec 2000 11:03:05 -0800 From: Andrew Smith Subject: Re: [Diffserv] Re: I-D ACTION:draft-ietf-diffserv-model-05.txt To: Shahram Davari Cc: diffserv@ietf.org Message-id: <3A2BEA69.5090700@allegronetworks.com> Organization: Allegro Networks MIME-version: 1.0 Content-type: text/plain; charset=us-ascii; format=flowed Content-transfer-encoding: 7bit User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; m18) Gecko/20001108 Netscape6/6.0 X-Accept-Language: en References: <9DC5E2ABE65BD54CA9088DA3194461D6010C9AA6@BBY1EXM01> Content-Transfer-Encoding: 7bit Sender: diffserv-admin@ietf.org Errors-To: diffserv-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Diffserv Discussion List X-BeenThere: diffserv@ietf.org Content-Transfer-Encoding: 7bit Shahram, My apologies on missing the "If T(t-) - C = 0" typo (again). I fixed the other typo there but not this one that you have repeatedly pointed out - will do so next time. On the other issues, I'm not sure you are raising anything new that Fred and Steve have not responded to already - I suggest you sit down with them, and maybe with Brian also, next week to discuss it again. Andrew (editor) Shahram Davari wrote: > Hi Andrew, > > I raised a number of issues many times during the course of this draft, but I haven't seen them being addressed. Last email that I sent was regarding version -04 of the draft, which was left un-answered. So I urge you to take some time to address my concerns about this draft. > > Here is a brief: > > 1) First of all the following typo is still in Appendix A of the draft despite being stated before: > > "If T(t-) - C = 0, the packet conforms and T(t) = T(t-) - C. Otherwise, > the packet does not conform and T(t) = T(t-)." > > Must be changed to: > > "If T(t-) - C >= 0, the packet conforms and T(t) = T(t-) - C. Otherwise, > the packet does not conform and T(t) = T(t-)." > > 2) I believe after a heavy discussion, the authors agreed that a simple token bucket is not a token bucket that its counts can go negative, and it was corrected in version -02, but I see it come back again in the future versions. > > Let me explain again what the problem is: > > A) Nobody (at least that I know) uses this kind of TB. > B) A TB which can go negative has many disadvantages, which are not mentioned in the draft at all. First of all it is more likely to drop small TCP ACK/SYN packets than a normal TB (i.e., a positive one). The reason is that when the TB count is negative it does not accept any packet, however small they may be until the count goes positive. Secondly it has granularity problem. By that I mean for example if one wants to restrict the burst to MTU, then the TB depth must be set to 1-bit. And if you do that you can't basically accept any back to back packets at all, no matter how small they are. > C) The same behavior that a negative TB of size B is looking after, could be constructed using a normal TB (the one that can't go negative) that has a size equal to B+MTU. By using a normal TB of bigger size, still the average rate will remain the same and you also won't have the problems that I mentioned in the bullet above and the problems of strict TB as mentioned in the draft won't exist any more. In other words a strict TB of bigger size will behave as a loose TB. > > 3) The first bullet of the disadvantages of strict TB is void, because the authors themselves have given the solution to it. Basically everybody knows that the TB depth must be greater than or equal to MTU. By comparison the problem with the negative TB could be said to be that you can't set the burst size to any value smaller than MTU. > > 4) Page 49 talks about the options that exist, if the size of the arriving packet exceeds the TB count. First of all if bullet 2 is talking about strict TBs, it is wrong. Because if you read SRTCM and TRTCM, you will see that in them if a packet is not accepted it does not cause any tokens to be added to the TB, while bullet 2 suggests that: "remembering that the token bucket size must be added to the TB variable rather than simply setting it "full". Also SRTCM and TRTCM always add token till the TB is full. If the second bullet is not talking about the strict TB, then why is it omitted from that list? > > > So here is my suggestion: > > 1)Let's add the disadvantages of the loose TB. > 2)let's mention that you could achieve the loose TB performance using the strict TB with a larger size. > 3)Let's either correct bullet 2 page 49, or add a new bullet that has strict TB as another option. > 4)Let's also mention the structure of strict TB in section 5.1.3. > 5)If possible I suggest changing the name form loose and strict to negative and positive respectively. The reason is that as I mentioned you could always achieve a loose performance by increasing the bucket depth of a strict TB. > > Thanks for you consideration. > > Shahram Davari > Systems Engineer > Product Research Group > PMC-Sierra, Inc. (Ottawa) > Phone: (613) 271-4018 > Fax: (613) 271-7007 > > > > > >> -----Original Message----- >> From: Andrew Smith [mailto:ah_smith@pacbell.net] >> Sent: Thursday, November 30, 2000 3:38 PM >> To: diffserv@ietf.org >> Subject: [Diffserv] Re: I-D ACTION:draft-ietf-diffserv-model-05.txt >> >> >> Please excuse the "*****Preliminary Authors' Review >> DRAFT****" legend in this >> draft - I forgot to remove it before submitting: this is, >> AFAIK, the current >> consensus of the authors and reflects most of the comments >> received up to this >> point. There are still a couple of open issues that I'll list >> in a separate message. >> >> Andrew Smith >> (editor of this draft) >> >> >> Internet-Drafts@ietf.org wrote: >> >> >>> A New Internet-Draft is available from the on-line >> >> Internet-Drafts directories. >> >>> This draft is a work item of the Differentiated Services >> >> Working Group of the IETF. >> >>> Title : An Informal Management Model for >> >> Diffserv Routers >> >>> *****Preliminary Authors' Review DRAFT**** >>> Author(s) : Y. Bernet, S. Blake, D. Grossman, A. Smith >>> Filename : draft-ietf-diffserv-model-05.txt >>> Pages : 54 >>> Date : 29-Nov-00 >>> >>> This memo proposes an informal management model of Differentiated >>> Services (Diffserv) routers for use in their management and >>> configuration. This model defines functional datapath >> >> elements (e.g. >> >>> classifiers, meters, actions (e.g. marking, absolute >> >> dropping, counting, >> >>> multiplexing), algorithmic droppers, queues and schedulers. >> >> It describes >> >>> possible configuration parameters for these elements and >> >> how they might >> >>> be interconnected to realize the range of traffic >> >> conditioning and per- >> >>> hop behavior (PHB) functionalities described in the Diffserv >>> Architecture [DSARCH]. >>> >>> A URL for this Internet-Draft is: >>> http://www.ietf.org/internet-drafts/draft-ietf-diffserv-model-05.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-05.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-05.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. >>> draft-ietf-diffserv-model-05.txt >>> >>> Content-Type: >>> >>> Message/External-body >> >> >> -- >> ****************************************************************** >> Andrew Smith tel: +1 415 345 1627 >> 1001 Chestnut St. fax: +1 415 345 1827 >> San Francisco, CA 94109, USA email: ah_smith@pacbell.net >> ****************************************************************** >> >> >> _______________________________________________ >> diffserv mailing list >> diffserv@ietf.org >> http://www1.ietf.org/mailman/listinfo/diffserv >> Archive: >> http://www2.ietf.org/mail-archive/working-groups/diffserv/curr > > ent/maillist.html _______________________________________________ diffserv mailing list diffserv@ietf.org http://www1.ietf.org/mailman/listinfo/diffserv Archive: http://www2.ietf.org/mail-archive/working-groups/diffserv/current/maillist.html From diffserv-admin@ietf.org Mon Dec 4 15:14:18 2000 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with SMTP id PAA18191 for ; Mon, 4 Dec 2000 15:14:18 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id OAA23603; Mon, 4 Dec 2000 14:52:09 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id OAA23581 for ; Mon, 4 Dec 2000 14:52:06 -0500 (EST) Received: from motgate.mot.com (motgate.mot.com [129.188.136.100]) by ietf.org (8.9.1a/8.9.1a) with SMTP id OAA12448 for ; Mon, 4 Dec 2000 14:52:04 -0500 (EST) Received: [from pobox2.mot.com (pobox2.mot.com [136.182.15.8]) by motgate.mot.com (motgate 2.1) with ESMTP id MAA20363; Mon, 4 Dec 2000 12:51:53 -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 MAA09996; Mon, 4 Dec 2000 12:51:53 -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 OAA01332; Mon, 4 Dec 2000 14:51:52 -0500 (EST) Message-Id: <200012041951.OAA01332@noah.dma.isg.mot.com> X-Mailer: exmh version 1.6.7 5/3/96 To: Andrew Smith cc: Brian E Carpenter , diffserv Subject: Re: [Diffserv] draft-ietf-diffserv-model-04.txt - what does it mean In-reply-to: Your message of "Mon, 04 Dec 2000 11:03:22 EST." <3A2BEA7A.2080907@allegronetworks.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Mon, 04 Dec 2000 14:51:49 -0500 From: Dan Grossman Sender: diffserv-admin@ietf.org Errors-To: diffserv-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Diffserv Discussion List X-BeenThere: diffserv@ietf.org > You see, I don't believe in this thing called "best effort" when you get down to > the details of the per-hop thing: we insist that all arriving traffic meets a > complete classifier and is divided into classes. Each class gets a specific > treatment (e.g. access to forwarding, buffering or scheduling resources) *in > relation to all the other classes*. There is no "special case", "default" or > "other" treatment - everything needs to be specified. You should be able to > model a (2-port) non-diffserv router as a classifier that matches everything, > followed by a FIFO queue that gets access to all the buffering in the box, > served by a scheduler that gets 100% of the line bandwidth, whenever there is > data to send i.e. I believe that there is no such, at this level of the model, > as "as if diffserv didn't exist". > > Andrew > What he said. :-) Except that treatment can be absolute, as well as in relation to all other classes. And that one can apply the label "best effort" to a classifier that matches everything, followed by a FIFO that gets access to all the buffering that's left after the other classes, followed by a scheduler that gets whatever transmission opportunities are left after all the other classes have been satisfied. _______________________________________________ diffserv mailing list diffserv@ietf.org http://www1.ietf.org/mailman/listinfo/diffserv Archive: http://www2.ietf.org/mail-archive/working-groups/diffserv/current/maillist.html From diffserv-admin@ietf.org Mon Dec 4 15:15: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 SMTP id PAA18599 for ; Mon, 4 Dec 2000 15:15:32 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id OAA23401; Mon, 4 Dec 2000 14:44:14 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id OAA23371 for ; Mon, 4 Dec 2000 14:44:10 -0500 (EST) Received: from procyon.pmc-sierra.bc.ca (procyon.pmc-sierra.bc.ca [134.87.115.1]) by ietf.org (8.9.1a/8.9.1a) with SMTP id OAA10639 for ; Mon, 4 Dec 2000 14:44:04 -0500 (EST) Received: from bby1exi01.pmc-sierra.bc.ca (bby1exi01.pmc-sierra.bc.ca [216.241.231.251]) by procyon.pmc-sierra.bc.ca (6.6.6/6.6.6) with ESMTP id LAA10666 for ; Mon, 4 Dec 2000 11:43:32 -0800 (PST) Received: by bby1exi01.pmc-sierra.bc.ca with Internet Mail Service (5.5.2650.21) id ; Mon, 4 Dec 2000 11:43:32 -0800 Message-ID: <9DC5E2ABE65BD54CA9088DA3194461D6012FF0A7@BBY1EXM01> From: Sylvain Gingras To: "'diffserv@ietf.org'" Subject: RE: [Diffserv] Re: I-D ACTION:draft-ietf-diffserv-model-05.txt (o n Metering) Date: Mon, 4 Dec 2000 11:43:25 -0800 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 Regarding the discussion of the 'loose' and 'strict' token buckets, I was also surprised at the unexplained and gradual shift away from the conventional 'strict' token bucket policer in the latest versions of the text. With all due respect to the authors who produced an admirable draft, I do seem to perceive a certain bias (intentional or not) in the presentation of the two models. This is particularly apparent in the discussion and definitions of token buckets in Appendix A. 1) Statements such as "Some find the behavior of a 'loose' token bucket unacceptable, as it is significantly different than the token bucket description for ATM and for Frame Relay" belittle the reasoning of those who may prefer the 'strict' model as being simply based on unwillingness to accept a model that is different to what they are used to in ATM and Frame Relay. I presume that the people referred to don't "find the behavior of a 'loose' token bucket unacceptable, but rather are thinking of applications where the 'strict' token bucket is more convenient for some reasons. Such reasons, which should be mentioned, include the fact that bits cannot be borrowed beyond the capacity of real-life buffers and beyond the bandwidth of real-life links. And therefore, in some applications (eg: when the policed flows must be aggregated and satisfy the constraints of a given buffer size and link rate) it may be more appropriate to use the 'strict' model with appropriately configured parameters rather than using the 'loose' model and having difficulties in setting the parameters in a way that guarantees that the buffer space won't be exceeded (eg: if all the policed flows are heavily borrowing at the same time). In such a case, the 'burst-size' parameter of the 'loose' policer may require to be set so small that the policer becomes unfair to small packets who don't get to benefit from the significant 'borrowing capacity' that the larger packets enjoy. 2) The text goes on to list "three characteristics" [read flaws] "which are important to keep in mind". The first two of those take half a page to tell us the obvious and well known requirement that the bucket size must be set to a value greater than MTU. A single sentence saying so would save time and keep the focus on the real issues. It should be noted that the same argument applies in a similar way to the 'loose' model when the burst-size is set to 1 bit. In this case the natural jitter in the network also conspires against the algorithm, as a packet arriving slightly earlier than it should is rejected due to the token count not having yet reached the positive territory. In fact, a more meaningful comparison of the two models would compare them when the 'bucket-size' parameter of the 'strict' model is configured to have MTU tokens above that of the corresponding parameter of the 'loose' model. 3) As for the third characteristic, I fail to see why this one would not apply to the 'loose' model. The fact that the 'loose' model provides a greater 'burst tolerance' for the same value of the 'bucket-size' parameter doesn't change much to the fact that a policing scheme is only reasonable when the policed flow is being shaped by some means which attempts to satisfy it's conformance requirements (by the use of a shaper or some feedback mechanism, such as that of TCP). As I see it, the difference in 'burst tolerance' between the two models are in the order of a single MTU, so I would much appreciate a more insightful description of why the loose model is more appropriate for 'TCP'. Despite the above criticism, I do however agree that the 'loose' model may provide some advantages in certain implementations. Diff-Serv'ers may be interested in looking at the the following laid-open Patent Application : Kathleen Nichols, Nortel Networks, "Method and Apparatus for Providing Differentiated Services" Patent No: WO0030307 for a good example of how the 'loose' model can be used to elegantly implement a meter-shaper (email me if you want a copy). Sincerely, Sylvain Gingras Senior Product Development Engineer PMC-Sierra Inc. Burnaby, BC _______________________________________________ diffserv mailing list diffserv@ietf.org http://www1.ietf.org/mailman/listinfo/diffserv Archive: http://www2.ietf.org/mail-archive/working-groups/diffserv/current/maillist.html From diffserv-admin@ietf.org Mon Dec 4 16:01: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 SMTP id QAA28634 for ; Mon, 4 Dec 2000 16:01:25 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id PAA25060; Mon, 4 Dec 2000 15:41:32 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id PAA24956 for ; Mon, 4 Dec 2000 15:41:24 -0500 (EST) Received: from ns.fmmo.ca (fm-listproc@www.fmmo.ca [207.253.160.156]) by ietf.org (8.9.1a/8.9.1a) with SMTP id PAA23589 for ; Mon, 4 Dec 2000 15:41:21 -0500 (EST) Received: from localhost (fm-listproc@localhost) by ns.fmmo.ca (8.9.3/8.9.3) with ESMTP id PAA19535; Mon, 4 Dec 2000 15:51:03 -0500 Date: Mon, 4 Dec 2000 15:51:02 -0500 (EST) From: fm-listproc To: Sylvain Gingras cc: "'diffserv@ietf.org'" Subject: RE: [Diffserv] Re: I-D ACTION:draft-ietf-diffserv-model-05.txt (o n Metering) In-Reply-To: <9DC5E2ABE65BD54CA9088DA3194461D6012FF0A7@BBY1EXM01> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: diffserv-admin@ietf.org Errors-To: diffserv-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Diffserv Discussion List X-BeenThere: diffserv@ietf.org Sylvain, J'aimerais une copie du brevet de Mme Nichols, -=Francois=- On Mon, 4 Dec 2000, Sylvain Gingras wrote: > Regarding the discussion of the 'loose' and 'strict' token buckets, I was also > surprised at the unexplained and gradual shift away from the conventional 'strict' > token bucket policer in the latest versions of the text. > > With all due respect to the authors who produced an admirable draft, I do seem to > perceive a certain bias (intentional or not) in the presentation of the two models. > This is particularly apparent in the discussion and definitions of token buckets in Appendix A. > > 1) Statements such as "Some find the behavior of a 'loose' token bucket unacceptable, as > it is significantly different than the token bucket description for ATM and for Frame Relay" > belittle the reasoning of those who may prefer the 'strict' model as being simply based on > unwillingness to accept a model that is different to what they are used to in ATM and Frame Relay. > I presume that the people referred to don't "find the behavior of a 'loose' token bucket unacceptable, > but rather are thinking of applications where the 'strict' token bucket is more convenient for some > reasons. > > Such reasons, which should be mentioned, include the fact that bits cannot be borrowed beyond > the capacity of real-life buffers and beyond the bandwidth of real-life links. And therefore, > in some applications (eg: when the policed flows must be aggregated and satisfy the > constraints of a given buffer size and link rate) it may be more appropriate to use the 'strict' model > with appropriately configured parameters rather than using the 'loose' model and having > difficulties in setting the parameters in a way that guarantees that the buffer space won't be exceeded > (eg: if all the policed flows are heavily borrowing at the same time). > In such a case, the 'burst-size' parameter of the 'loose' policer may require to be set so small > that the policer becomes unfair to small packets who don't get to benefit from the significant > 'borrowing capacity' that the larger packets enjoy. > > 2) The text goes on to list "three characteristics" [read flaws] "which are important to keep > in mind". The first two of those take half a page to tell us the obvious and well known > requirement that the bucket size must be set to a value greater than MTU. > A single sentence saying so would save time and keep the focus on the real issues. > > It should be noted that the same argument applies in a similar way to the 'loose' > model when the burst-size is set to 1 bit. In this case the natural jitter in the network > also conspires against the algorithm, as a packet arriving slightly earlier than it should > is rejected due to the token count not having yet reached the positive territory. > In fact, a more meaningful comparison of the two models would compare them > when the 'bucket-size' parameter of the 'strict' model is configured to have MTU tokens > above that of the corresponding parameter of the 'loose' model. > > 3) As for the third characteristic, I fail to see why this one would not apply to the 'loose' > model. The fact that the 'loose' model provides a greater 'burst tolerance' for the same > value of the 'bucket-size' parameter doesn't change much to the fact that a policing scheme > is only reasonable when the policed flow is being shaped by some means which attempts > to satisfy it's conformance requirements (by the use of a shaper or some feedback mechanism, > such as that of TCP). As I see it, the difference in 'burst tolerance' between the two models > are in the order of a single MTU, so I would much appreciate a more insightful description of > why the loose model is more appropriate for 'TCP'. > > > Despite the above criticism, I do however agree that the 'loose' model may provide some > advantages in certain implementations. Diff-Serv'ers may be interested in looking at the > the following laid-open Patent Application : > Kathleen Nichols, Nortel Networks, "Method and Apparatus for Providing Differentiated Services" > Patent No: WO0030307 > for a good example of how the 'loose' model can be used to elegantly implement a meter-shaper > (email me if you want a copy). > > > Sincerely, > > Sylvain Gingras > Senior Product Development Engineer > PMC-Sierra Inc. > Burnaby, BC > > > > > _______________________________________________ > diffserv mailing list > diffserv@ietf.org > http://www1.ietf.org/mailman/listinfo/diffserv > Archive: http://www2.ietf.org/mail-archive/working-groups/diffserv/current/maillist.html > _______________________________________________ diffserv mailing list diffserv@ietf.org http://www1.ietf.org/mailman/listinfo/diffserv Archive: http://www2.ietf.org/mail-archive/working-groups/diffserv/current/maillist.html From diffserv-admin@ietf.org Mon Dec 4 16:45: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 SMTP id QAA10447 for ; Mon, 4 Dec 2000 16:45:15 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id QAA25809; Mon, 4 Dec 2000 16:24:21 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id QAA25778 for ; Mon, 4 Dec 2000 16:24:14 -0500 (EST) Received: from mailhub1.almaden.ibm.com (mailhub1.almaden.ibm.com [198.4.83.44]) by ietf.org (8.9.1a/8.9.1a) with SMTP id QAA04025 for ; Mon, 4 Dec 2000 16:24:13 -0500 (EST) Received: from maui.almaden.ibm.com (maui.almaden.ibm.com [9.1.24.92]) by mailhub1.almaden.ibm.com (8.8.8/8.8.8) with ESMTP id NAA06002; Mon, 4 Dec 2000 13:23:37 -0800 Received: from hursley.ibm.com (ss8.pok.socks.ibm.com [9.14.3.73]) by maui.almaden.ibm.com (AIX4.3/8.9.3/8.7) with ESMTP id NAA09584; Mon, 4 Dec 2000 13:23:42 -0800 Message-ID: <3A2BD901.FE5F9B4F@hursley.ibm.com> Date: Mon, 04 Dec 2000 11:48:49 -0600 From: Brian E Carpenter Organization: IBM X-Mailer: Mozilla 4.61 [en] (Win98; I) X-Accept-Language: en,fr MIME-Version: 1.0 To: demir CC: diffserv@ietf.org References: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Subject: [Diffserv] Re: [EF PHB] A suggestion to support "Queuing and Discarding Behavior"for EF PHB Sender: diffserv-admin@ietf.org Errors-To: diffserv-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Diffserv Discussion List X-BeenThere: diffserv@ietf.org Content-Transfer-Encoding: 7bit This is a fundamental change to the EF PHB and I don't think we have seen any evidence of a widespread desire for that; all that is on the table is repairing a defect in 2598. Brian demir wrote: > > Hi, > I have a simple suggestion to support "Queueing and Discarding > Behavior" for EF PHB where "Queuing and Discarding" Behavior MAY be > supported (something like defined in AF PHB) > Someone may ask why?: because the range of services that can be supported > can be wider. > Someone may ask why do I need "congestion avaidance" for a EF PHB: First > of all, it's not a service. If you don't want to deal with it 1) you don't > have to implement it 2) If you implement it, but don't want to deal with > it: min_threshold=max_threshold=buffer_size or if you have a power to > disactivate it in your implementation, you can do it. > 3) Trafic conditioners may fail. If input/output rate constraint is not > chosen, and input rate becomes an important value, then "congestion > collapse" might be a problem. Still, one can have a choice to deal with it > or leave it out. 4) It is sad that EF PHB has only one DSCP and no "levels > of forwarding assurance". If it did, there could have been much more range > of services. Someone might say, it's AF PHB's job to do it: It is a > forwarding assurance for EF packets where EF PHB constraints are > performed. > > Someone might say it doesn't make much more sense to provide range of > services on top of EF PHB: If it doesn't don't use it. If it does, use > it. You are not required to do it. It's just a MAY. However, you never > know what will happen in the future. If AF PHB is not too strict about > the "drop levels" and "classes", it could have been a buildnig block for > EF PHB with it's additional constraints with additional DSCPs. > > Again: > - "First, we want to start out by implementing a simple set of > services, which are useful and easy to understand. At the same time, > we should not embed these services into the mechanism, but should > build a general mechanism that allows us to change the services as > our experience matures."- D. Clark / J. Wroclawski, "An Approach to > Service Allocation in the Internet" > > Any comments? > > Alper K. Demir _______________________________________________ diffserv mailing list diffserv@ietf.org http://www1.ietf.org/mailman/listinfo/diffserv Archive: http://www2.ietf.org/mail-archive/working-groups/diffserv/current/maillist.html From diffserv-admin@ietf.org Mon Dec 4 16:45:27 2000 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with SMTP id QAA10522 for ; Mon, 4 Dec 2000 16:45:27 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id QAA25853; Mon, 4 Dec 2000 16:24:34 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id QAA25813 for ; Mon, 4 Dec 2000 16:24:25 -0500 (EST) Received: from mailhub1.almaden.ibm.com (mailhub1.almaden.ibm.com [198.4.83.44]) by ietf.org (8.9.1a/8.9.1a) with SMTP id QAA04097 for ; Mon, 4 Dec 2000 16:24:23 -0500 (EST) Received: from maui.almaden.ibm.com (maui.almaden.ibm.com [9.1.24.92]) by mailhub1.almaden.ibm.com (8.8.8/8.8.8) with ESMTP id NAA31622; Mon, 4 Dec 2000 13:23:47 -0800 Received: from hursley.ibm.com (ss8.pok.socks.ibm.com [9.14.3.73]) by maui.almaden.ibm.com (AIX4.3/8.9.3/8.7) with ESMTP id NAA35824; Mon, 4 Dec 2000 13:23:51 -0800 Message-ID: <3A2BDA16.F1D8BB2C@hursley.ibm.com> Date: Mon, 04 Dec 2000 11:53:26 -0600 From: Brian E Carpenter Organization: IBM X-Mailer: Mozilla 4.61 [en] (Win98; I) X-Accept-Language: en,fr MIME-Version: 1.0 To: Keith McCloghrie CC: Andrew Smith , Dan Romascanu , rmonmib , diffserv@ietf.org Subject: Re: [Diffserv] DiffServ MIB -06: statistics References: <200012040624.WAA18390@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 Well, the IESG has developed a nasty habit of asking for cross-checks between WGs with overlapping interests. Can you give us the draft name for the DSMON MIB so that diffservers can check it out right away? Thanks Brian Keith McCloghrie wrote: > > > BTW, I assume that the diffserv WG will also run a last-call of the DSMON MIB > > since the "subject-matter experts" are supposedly on that list. > > I doubt it: > > 1. the DSMON MIB is intended for a (logical) probe, rather than for a > (logical) router. (That's not to say that an actual router can't > perform both functions, but that's true of most RMON MIBs). > > 2. the DSMON MIB was submitted to the RMON WG only after the DiffServ WG > chair said that it wasn't wanted in the DiffServ WG. > > 3. the DiffServ MIB already contains a (complicated) set of DiffServ > counters for a router to implement, many of which are not appropriate > for a (physical) probe to implement. > > Keith. > > _______________________________________________ > diffserv mailing list > diffserv@ietf.org > http://www1.ietf.org/mailman/listinfo/diffserv > Archive: http://www2.ietf.org/mail-archive/working-groups/diffserv/current/maillist.html _______________________________________________ diffserv mailing list diffserv@ietf.org http://www1.ietf.org/mailman/listinfo/diffserv Archive: http://www2.ietf.org/mail-archive/working-groups/diffserv/current/maillist.html From diffserv-admin@ietf.org Mon Dec 4 16:46: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 SMTP id QAA10864 for ; Mon, 4 Dec 2000 16:46:13 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id QAA25890; Mon, 4 Dec 2000 16:24:46 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id QAA25855 for ; Mon, 4 Dec 2000 16:24:38 -0500 (EST) Received: from mailhub1.almaden.ibm.com (mailhub1.almaden.ibm.com [198.4.83.44]) by ietf.org (8.9.1a/8.9.1a) with SMTP id QAA04171 for ; Mon, 4 Dec 2000 16:24:37 -0500 (EST) Received: from maui.almaden.ibm.com (maui.almaden.ibm.com [9.1.24.92]) by mailhub1.almaden.ibm.com (8.8.8/8.8.8) with ESMTP id NAA06050; Mon, 4 Dec 2000 13:24:01 -0800 Received: from hursley.ibm.com (ss8.pok.socks.ibm.com [9.14.3.73]) by maui.almaden.ibm.com (AIX4.3/8.9.3/8.7) with ESMTP id NAA27458; Mon, 4 Dec 2000 13:24:06 -0800 Message-ID: <3A2BDAE6.6C9287E7@hursley.ibm.com> Date: Mon, 04 Dec 2000 11:56:54 -0600 From: Brian E Carpenter Organization: IBM X-Mailer: Mozilla 4.61 [en] (Win98; I) X-Accept-Language: en,fr MIME-Version: 1.0 To: "Flores Mosri, Alejandra" CC: "'diffserv@ietf.org'" Subject: Re: [Diffserv] RTP and diffserv References: <51884AFB9193D41192D90002B30A0F1A0128B832@sernt12.essex.ac.uk> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: diffserv-admin@ietf.org Errors-To: diffserv-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Diffserv Discussion List X-BeenThere: diffserv@ietf.org Content-Transfer-Encoding: 7bit I'm not aware of one. Brian "Flores Mosri, Alejandra" wrote: > > Hello, > > I have read about RSVP and diffserv, but can anyone tell me if there is a > draft about RTP (RTCP) and diffserv? > > Thanks in advance > > ______________________________________________ > Alejandra Flores > PhD Research Student > Multimedia Communications Research Laboratory > Department of Electronic Systems Engineering > University of Essex > United Kingdom > e-mail: afloreb@essex.ac.uk > tel.: +44 1206 872442 & +44 1206 872448 > > _______________________________________________ > diffserv mailing list > diffserv@ietf.org > http://www1.ietf.org/mailman/listinfo/diffserv > Archive: http://www2.ietf.org/mail-archive/working-groups/diffserv/current/maillist.html _______________________________________________ diffserv mailing list diffserv@ietf.org http://www1.ietf.org/mailman/listinfo/diffserv Archive: http://www2.ietf.org/mail-archive/working-groups/diffserv/current/maillist.html From diffserv-admin@ietf.org Mon Dec 4 16:46: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 SMTP id QAA10924 for ; Mon, 4 Dec 2000 16:46:20 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id QAA25945; Mon, 4 Dec 2000 16:25:18 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id QAA25914 for ; Mon, 4 Dec 2000 16:25:13 -0500 (EST) Received: from mailhub1.almaden.ibm.com (mailhub1.almaden.ibm.com [198.4.83.44]) by ietf.org (8.9.1a/8.9.1a) with SMTP id QAA04358 for ; Mon, 4 Dec 2000 16:25:12 -0500 (EST) Received: from maui.almaden.ibm.com (maui.almaden.ibm.com [9.1.24.92]) by mailhub1.almaden.ibm.com (8.8.8/8.8.8) with ESMTP id NAA39316; Mon, 4 Dec 2000 13:23:55 -0800 Received: from hursley.ibm.com (ss8.pok.socks.ibm.com [9.14.3.73]) by maui.almaden.ibm.com (AIX4.3/8.9.3/8.7) with ESMTP id NAA24704; Mon, 4 Dec 2000 13:23:59 -0800 Message-ID: <3A2BDAAE.F0490485@hursley.ibm.com> Date: Mon, 04 Dec 2000 11:55:58 -0600 From: Brian E Carpenter Organization: IBM X-Mailer: Mozilla 4.61 [en] (Win98; I) X-Accept-Language: en,fr MIME-Version: 1.0 To: Andrew Smith CC: snmpconf@snmp.com, diffserv , Jon Saperia , Randy Bush Subject: Re: [Diffserv] Re: snmpconf FW: November Milestones References: <2413FED0DFE6D111B3F90008C7FA61FB0A4AE5E8@nl0006exch002u.nl.lucent.com> <3A2A9251.E8C87BF6@mediaone.net> <3A2B2693.7000800@allegronetworks.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: diffserv-admin@ietf.org Errors-To: diffserv-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Diffserv Discussion List X-BeenThere: diffserv@ietf.org Content-Transfer-Encoding: 7bit Andrew Smith wrote: > > From a thread from the snmpconf WG: > > Jon wrote: > >> Configuration is the heart of management. To the extent MIB Documents > >> are created in each of the different technology areas such as routing or > >> differentiated services (which is the right place), they should be > >> designed for full coverage including configuration. There is no excuse > >> not to. > > > Randy wrote: > > i do not intend to discourage those who wish to design for write from doing > > so. but i am not sure i see a need to mandate it when doing so would cause > > complexity or architectural change. and i believe that, and only that, was > > the question (in the tewg) that [re]started this rathole. > > > > randy > > Randy's point is well made - I don't think it is a rathole - and is directly > relevant to the MIB/PIB/snmpconf/DSMON discussions for diffserv management. In > the various iterations of the diffserv MIB we have veered between extremes of > optimise-for-read and optimise-for-configure without, I think, a clear idea of > why. The -04 version tended towards the former whilst the latest incarnation > (-06) veers back towards the latter in the interests of consistency with the PIB > work and the "template" concept for the diffserv policy MIB (snmpconf WG). > Should we treat these as valid reasons to sacrifice read performance or should > we find another way to optimise opbjects for configuration e.g. by duplication > (indexing of same information in multiple ways)? Right now, I believe the -06 > MIB does cause additional complexity for reading. Personal opinion: this is a tough call but my computer scientist instincts are for the consistency argument, i.e. the present approach. Brian _______________________________________________ diffserv mailing list diffserv@ietf.org http://www1.ietf.org/mailman/listinfo/diffserv Archive: http://www2.ietf.org/mail-archive/working-groups/diffserv/current/maillist.html From diffserv-admin@ietf.org Mon Dec 4 16:46:36 2000 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with SMTP id QAA10994 for ; Mon, 4 Dec 2000 16:46:31 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id QAA25775; Mon, 4 Dec 2000 16:24:13 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id QAA25743 for ; Mon, 4 Dec 2000 16:24:08 -0500 (EST) Received: from mailhub1.almaden.ibm.com (mailhub1.almaden.ibm.com [198.4.83.44]) by ietf.org (8.9.1a/8.9.1a) with SMTP id QAA03987 for ; Mon, 4 Dec 2000 16:24:07 -0500 (EST) Received: from maui.almaden.ibm.com (maui.almaden.ibm.com [9.1.24.92]) by mailhub1.almaden.ibm.com (8.8.8/8.8.8) with ESMTP id NAA31078; Mon, 4 Dec 2000 13:23:31 -0800 Received: from hursley.ibm.com (ss8.pok.socks.ibm.com [9.14.3.73]) by maui.almaden.ibm.com (AIX4.3/8.9.3/8.7) with ESMTP id NAA27450; Mon, 4 Dec 2000 13:23:36 -0800 Message-ID: <3A2BD87A.D3769361@hursley.ibm.com> Date: Mon, 04 Dec 2000 11:46:34 -0600 From: Brian E Carpenter Organization: IBM X-Mailer: Mozilla 4.61 [en] (Win98; I) X-Accept-Language: en,fr MIME-Version: 1.0 To: demir CC: diffserv@ietf.org Subject: Re: [Diffserv] EFRESOLVE definition in the presence of excess inputburstiness 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 You might want to check guideline G4 in RFC 2475. But please let's not distract attention from EF by discussing AF at this time. Thanks Brian demir wrote: > > Brian, > I see a relationship (of course there is no relationship what they > define and what "parameters" and "basic building-blocs" (explained > later) they use. Otherwise, they would be the same thing) I explained it > step by step. > My disaggrement with Anna was about "In fact, Diffserv Architecture > explicitly says that a PHB definition should describe the behavior when > input constraints are violated:"-Anna. > I haven't seen such a constraint in any RFC. If there is, could you point > it out to me? ... _______________________________________________ diffserv mailing list diffserv@ietf.org http://www1.ietf.org/mailman/listinfo/diffserv Archive: http://www2.ietf.org/mail-archive/working-groups/diffserv/current/maillist.html From diffserv-admin@ietf.org Mon Dec 4 17:27: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 SMTP id RAA26988 for ; Mon, 4 Dec 2000 17:27:52 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id RAA27575; Mon, 4 Dec 2000 17:04:58 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id RAA27547 for ; Mon, 4 Dec 2000 17:04:54 -0500 (EST) Received: from cisco.com (ups.cisco.com [171.69.18.21]) by ietf.org (8.9.1a/8.9.1a) with SMTP id RAA16934 for ; Mon, 4 Dec 2000 17:04:53 -0500 (EST) Received: (from kzm@localhost) by cisco.com (8.8.8/2.6/Cisco List Logging/8.8.8) id OAA05268; Mon, 4 Dec 2000 14:04:20 -0800 (PST) From: Keith McCloghrie Message-Id: <200012042204.OAA05268@cisco.com> Subject: Re: [Diffserv] DiffServ MIB -06: statistics To: brian@hursley.ibm.com (Brian E Carpenter) Date: Mon, 4 Dec 2000 14:04:20 -0800 (PST) Cc: kzm@cisco.com (Keith McCloghrie), andrew@allegronetworks.com (Andrew Smith), dromasca@avaya.com (Dan Romascanu), rmonmib@cisco.com (rmonmib), diffserv@ietf.org In-Reply-To: <3A2BDA16.F1D8BB2C@hursley.ibm.com> from "Brian E Carpenter" at Dec 04, 2000 11:53:26 AM X-Mailer: ELM [version 2.5 PL1] MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: diffserv-admin@ietf.org Errors-To: diffserv-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Diffserv Discussion List X-BeenThere: diffserv@ietf.org Content-Transfer-Encoding: 7bit > Well, the IESG has developed a nasty habit of asking for cross-checks > between WGs with overlapping interests. Can you give us the draft name for > the DSMON MIB so that diffservers can check it out right away? draft-ietf-rmonmib-dsmon-mib-03.txt Keith. > Thanks > > Brian > > Keith McCloghrie wrote: > > > > > BTW, I assume that the diffserv WG will also run a last-call of the DSMON MIB > > > since the "subject-matter experts" are supposedly on that list. > > > > I doubt it: > > > > 1. the DSMON MIB is intended for a (logical) probe, rather than for a > > (logical) router. (That's not to say that an actual router can't > > perform both functions, but that's true of most RMON MIBs). > > > > 2. the DSMON MIB was submitted to the RMON WG only after the DiffServ WG > > chair said that it wasn't wanted in the DiffServ WG. > > > > 3. the DiffServ MIB already contains a (complicated) set of DiffServ > > counters for a router to implement, many of which are not appropriate > > for a (physical) probe to implement. > > > > Keith. > > > > _______________________________________________ > > diffserv mailing list > > diffserv@ietf.org > > http://www1.ietf.org/mailman/listinfo/diffserv > > Archive: http://www2.ietf.org/mail-archive/working-groups/diffserv/current/maillist.html > > > _______________________________________________ diffserv mailing list diffserv@ietf.org http://www1.ietf.org/mailman/listinfo/diffserv Archive: http://www2.ietf.org/mail-archive/working-groups/diffserv/current/maillist.html From diffserv-admin@ietf.org Mon Dec 4 17:53: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 SMTP id RAA06133 for ; Mon, 4 Dec 2000 17:53:21 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id RAA28281; Mon, 4 Dec 2000 17:33:43 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id RAA28258 for ; Mon, 4 Dec 2000 17:33:39 -0500 (EST) Received: from usc.edu (root@usc.edu [128.125.253.136]) by ietf.org (8.9.1a/8.9.1a) with SMTP id RAA28927 for ; Mon, 4 Dec 2000 17:33:37 -0500 (EST) Received: from aludra.usc.edu (demir@aludra.usc.edu [128.125.253.184]) by usc.edu (8.9.3.1/8.9.3/usc) with ESMTP id OAA04882; Mon, 4 Dec 2000 14:33:36 -0800 (PST) Received: from localhost (demir@localhost) by aludra.usc.edu (8.9.3.1/8.9.3/usc) with ESMTP id OAA08385; Mon, 4 Dec 2000 14:33:35 -0800 (PST) Date: Mon, 4 Dec 2000 14:33:35 -0800 (PST) From: demir To: Brian E Carpenter cc: diffserv@ietf.org In-Reply-To: <3A2BD901.FE5F9B4F@hursley.ibm.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Subject: [Diffserv] Re: [EF PHB] A suggestion to support "Queuing and Discarding Behavior"for EF PHB Sender: diffserv-admin@ietf.org Errors-To: diffserv-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Diffserv Discussion List X-BeenThere: diffserv@ietf.org Brian, I agree that this is a fundamental change. However, it is a MAY and will not affect the table. I assume "repairing a defect" should also consider "repairing failures" (trafic conditioners) and "service range". What I am suggestion is a more general mechanism which is a super set of current one. Alper K. Demir On Mon, 4 Dec 2000, Brian E Carpenter wrote: > This is a fundamental change to the EF PHB and I don't think > we have seen any evidence of a widespread desire for that; all > that is on the table is repairing a defect in 2598. > > Brian > > demir wrote: > > > > Hi, > > I have a simple suggestion to support "Queueing and Discarding > > Behavior" for EF PHB where "Queuing and Discarding" Behavior MAY be > > supported (something like defined in AF PHB) > > Someone may ask why?: because the range of services that can be supported > > can be wider. > > Someone may ask why do I need "congestion avaidance" for a EF PHB: First > > of all, it's not a service. If you don't want to deal with it 1) you don't > > have to implement it 2) If you implement it, but don't want to deal with > > it: min_threshold=max_threshold=buffer_size or if you have a power to > > disactivate it in your implementation, you can do it. > > 3) Trafic conditioners may fail. If input/output rate constraint is not > > chosen, and input rate becomes an important value, then "congestion > > collapse" might be a problem. Still, one can have a choice to deal with it > > or leave it out. 4) It is sad that EF PHB has only one DSCP and no "levels > > of forwarding assurance". If it did, there could have been much more range > > of services. Someone might say, it's AF PHB's job to do it: It is a > > forwarding assurance for EF packets where EF PHB constraints are > > performed. > > > > Someone might say it doesn't make much more sense to provide range of > > services on top of EF PHB: If it doesn't don't use it. If it does, use > > it. You are not required to do it. It's just a MAY. However, you never > > know what will happen in the future. If AF PHB is not too strict about > > the "drop levels" and "classes", it could have been a buildnig block for > > EF PHB with it's additional constraints with additional DSCPs. > > > > Again: > > - "First, we want to start out by implementing a simple set of > > services, which are useful and easy to understand. At the same time, > > we should not embed these services into the mechanism, but should > > build a general mechanism that allows us to change the services as > > our experience matures."- D. Clark / J. Wroclawski, "An Approach to > > Service Allocation in the Internet" > > > > Any comments? > > > > Alper K. Demir > > _______________________________________________ diffserv mailing list diffserv@ietf.org http://www1.ietf.org/mailman/listinfo/diffserv Archive: http://www2.ietf.org/mail-archive/working-groups/diffserv/current/maillist.html From diffserv-admin@ietf.org Mon Dec 4 18:08: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 SMTP id SAA10987 for ; Mon, 4 Dec 2000 18:08:12 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id RAA28457; Mon, 4 Dec 2000 17:41:30 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id RAA28427 for ; Mon, 4 Dec 2000 17:41:25 -0500 (EST) Received: from uniwest1.redstonecom.com ([199.105.223.130]) by ietf.org (8.9.1a/8.9.1a) with SMTP id RAA01489 for ; Mon, 4 Dec 2000 17:41:24 -0500 (EST) Received: by uniwest1.redstonecom.com with Internet Mail Service (5.5.2650.21) id ; Mon, 4 Dec 2000 17:40:56 -0500 Message-ID: <49FF5C6DDBD8D311BBBD009027DE980C010C4351@uniwest1.redstonecom.com> From: "Lemaire, Tom" To: "'Andrew Smith'" Cc: diffserv Subject: RE: [Diffserv] draft-ietf-diffserv-model-04.txt - what does it me an Date: Mon, 4 Dec 2000 17:40:55 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: text/plain; charset="iso-8859-1" Sender: diffserv-admin@ietf.org Errors-To: diffserv-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Diffserv Discussion List X-BeenThere: diffserv@ietf.org It is desirable to have everything specified, but an ISP transitioning from a one class world to a multi-class world will appreciate well-defined handling of the cases where (1) packets are not explicitly classified into a traffic class on the ingress side of the box, and (2) bandwidth/buffers for a given class are not explicitly allocated on the egress side of the box. You can specify that such conditions must not exist, but when they inevitably arise due to customers incrementally configuring/deploying diffserv, it would be helpful if the specs make the behavior well-defined. One way to do this is by designating one traffic class as the 'default' class. There are other ways, but leaving the behavior undefined just means that implementations will vary. Tom Lemaire Unisphere Networks -----Original Message----- From: Andrew Smith [mailto:andrew@allegronetworks.com] Sent: Monday, December 04, 2000 2:03 PM To: Brian E Carpenter Cc: diffserv Subject: Re: [Diffserv] draft-ietf-diffserv-model-04.txt - what does it mean You see, I don't believe in this thing called "best effort" when you get down to the details of the per-hop thing: we insist that all arriving traffic meets a complete classifier and is divided into classes. Each class gets a specific treatment (e.g. access to forwarding, buffering or scheduling resources) *in relation to all the other classes*. There is no "special case", "default" or "other" treatment - everything needs to be specified. You should be able to model a (2-port) non-diffserv router as a classifier that matches everything, followed by a FIFO queue that gets access to all the buffering in the box, served by a scheduler that gets 100% of the line bandwidth, whenever there is data to send i.e. I believe that there is no such, at this level of the model, as "as if diffserv didn't exist". Andrew Brian E Carpenter wrote: > Fair enough, we can clarify it, but am I right that it means > that the packet is simply inserted into the data path as if > diffserv didn't exist (which is presumably equivalent to > treating it as BE)? > > Brian > > Andrew Smith wrote: > >> Brian, >> >> I'm not sure that it is good enough to leave this as an implementation detail: >> it seems to me that this is needs to be declared as either (a) an >> invalid/incomplete configuration or (b) a valid configuration with well-defined >> results. We don't currently have any sort of catch-all "if any part of the DS >> configuration following along a particular datapath is currently invalid, then >> the classifier element that leads to this datapath is considered to be >> not-in-service" rule to handle (a) and I'm not sure how to phrase (b). But I do >> agree with Bob that we need to address the issue more clearly in the draft. >> >> Andrew >> >> Brian E Carpenter wrote: >> >> >>> Bob, >>> >>> I've always interpreted this phrase to mean that the packet >>> goes back into the data path it would be on if the router >>> knew nothing about diffserv. Whether that is the lowest >>> priority queue seems to be an implementation detail. >>> >>> Brian >>> >>> Robert Moore wrote: >>> >>> >>>> Hi Kwok, >>>> >>>> I'll have to say that even with the -06 version of the MIB, >>>> I still can't say that I really understand how this works. >>>> Take the following example for an egress interface. The >>>> example isn't intended to be realistic -- just to illustrate >>>> my point with the smallest number of elements: >>>> >>>> +------+ +---------+ >>>> | ----|------>Q1(high)-->|Priority | >>>> DataPath |/ | |Scheduler|-->zeroDotZero >>>> Start--->|------|------>Q2(low)--->| | >>>> |\ | +---------+ >>>> | ----|--->zeroDotZero >>>> +------+ >>>> >>>> Clearly packets from the top branch of the classifier, >>>> coming from the higher priority queue, will be >>>> scheduled out ahead of packets from the middle branch, >>>> which has the lower priority queue. But how will packets >>>> from the bottom branch be scheduled out, relative to >>>> those from the top two branches? What does it mean for >>>> these packets to receive "no further DiffServ treatment," >>>> relative to packets from the other two branches, which >>>> do receive this treatment? >>>> >>>> I could make up an answer here: packets on the bottom >>>> branch are treated as if they were on a lowest priority >>>> queue serviced by this same Priority Scheduler. But I'd >>>> be more comfortable if there were something in either >>>> the MIB or the Informal Model that I could point to, >>>> implying that this answer is the correct one. >>>> >>>> Regards, >>>> Bob >>>> >>>> Bob Moore >>>> IBM Networking Software >>>> +1-919-254-4436 >>>> remoore@us.ibm.com >>>> >>>> "Kwok-Ho Chan" @ietf.org on 11/16/2000 12:02:58 >>>> PM >>>> >>>> Sent by: diffserv-admin@ietf.org >>>> >>>> To: Erez Bashan >>>> cc: diffserv >>>> Subject: Re: [Diffserv] draft-ietf-diffserv-model-04.txt - what does it >>>> mean "no further Diffserv treatment is performed" ? >>>> >>>> Meaning of "no further DiffServ treatment is performed", as quoted from >>>> DSMIB-05 section 3.1.1: >>>> "allow normal IP device processing", "Normal IP device processing >>>> will depend on the device, for example, this can be forwarding the packet." >>>> >>>> Is this sufficient? May be I should move this explanation to the >>>> RowPointer >>>> section (5.1), but that section maybe changed in a more dramatic way >>>> depending on the outcome of the "Instance Amplification" discussion thread. >>>> >>>> -- Kwok -- >>>> >>>> At 03:24 PM 11/16/00 +0200, Erez Bashan wrote: >>>> >>>> >>>>> In several places in the MIB (for example if the diffServMeterFailNext has >>>> >>>> a >>>> >>>> >>>>> value of "value of zeroDotZero") a scenario exists in which "no further >>>>> Diffserv treatment is performed" on certain traffic. >>>>> >>>>> What does it mean ? Is the packet dropped, or should it be handled by >>>>> another independent (??) mechanism in the router ? If it is to be dropped, >>>>> why isn't it says so explicitly ? >>>>> >>>>> Erez >>>> > > _______________________________________________ > diffserv mailing list > diffserv@ietf.org > http://www1.ietf.org/mailman/listinfo/diffserv > Archive: http://www2.ietf.org/mail-archive/working-groups/diffserv/current/maillist.h tml _______________________________________________ diffserv mailing list diffserv@ietf.org http://www1.ietf.org/mailman/listinfo/diffserv Archive: http://www2.ietf.org/mail-archive/working-groups/diffserv/current/maillist.h tml _______________________________________________ diffserv mailing list diffserv@ietf.org http://www1.ietf.org/mailman/listinfo/diffserv Archive: http://www2.ietf.org/mail-archive/working-groups/diffserv/current/maillist.html From diffserv-admin@ietf.org Mon Dec 4 18:41: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 SMTP id SAA21539 for ; Mon, 4 Dec 2000 18:41:36 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id SAA29411; Mon, 4 Dec 2000 18:15:49 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id SAA29380 for ; Mon, 4 Dec 2000 18:15:44 -0500 (EST) Received: from usc.edu (root@usc.edu [128.125.253.136]) by ietf.org (8.9.1a/8.9.1a) with SMTP id SAA13087 for ; Mon, 4 Dec 2000 18:15:41 -0500 (EST) Received: from aludra.usc.edu (demir@aludra.usc.edu [128.125.253.184]) by usc.edu (8.9.3.1/8.9.3/usc) with ESMTP id PAA20393; Mon, 4 Dec 2000 15:15:43 -0800 (PST) Received: from localhost (demir@localhost) by aludra.usc.edu (8.9.3.1/8.9.3/usc) with ESMTP id PAA22751; Mon, 4 Dec 2000 15:15:42 -0800 (PST) Date: Mon, 4 Dec 2000 15:15:42 -0800 (PST) From: demir To: Brian E Carpenter cc: diffserv@ietf.org Subject: Re: [Diffserv] EFRESOLVE definition in the presence of excess inputburstiness In-Reply-To: <3A2BD87A.D3769361@hursley.ibm.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: diffserv-admin@ietf.org Errors-To: diffserv-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Diffserv Discussion List X-BeenThere: diffserv@ietf.org Brian, I didn't know that discussions are on per problem basis. I am pointing out a "PHB" definition issue. I am talking about a problem of the current architecture (where some MAYs won't have any effect on the current): - "First, we want to start out by implementing a simple set of services, which are useful and easy to understand. At the same time, we should not embed these services into the mechanism, but should build a general mechanism that allows us to change the services as our experience matures."- D. Clark / J. Wroclawski, "An Approach to Service Allocation in the Internet" It seems to me that G4 along with other guideslines are restrictive. Services (expected) are being embedded into the PHB mechanisms. You may say that that's how we designed. In that case, I can't say more than: Some MAYs won't have any effect on the current architecture. They will provide more "generality". The "beauty" of Diffserv Architecture is "It is scalable and the architecture defined supports qualitative services" (I am not saying that scalability and qualitative services are unique to Diffserv Architecture). Let's not embed services into the mechanisms. EFRESOLVE is one of them. That's how I see it. Our experience will mature. That's why PDBs are defined (that's what I thought). Alper K. Demir On Mon, 4 Dec 2000, Brian E Carpenter wrote: > You might want to check guideline G4 in RFC 2475. But please let's > not distract attention from EF by discussing AF at this time. > > Thanks > Brian > > demir wrote: > > > > Brian, > > I see a relationship (of course there is no relationship what they > > define and what "parameters" and "basic building-blocs" (explained > > later) they use. Otherwise, they would be the same thing) I explained it > > step by step. > > My disaggrement with Anna was about "In fact, Diffserv Architecture > > explicitly says that a PHB definition should describe the behavior when > > input constraints are violated:"-Anna. > > I haven't seen such a constraint in any RFC. If there is, could you point > > it out to me? > ... > > _______________________________________________ diffserv mailing list diffserv@ietf.org http://www1.ietf.org/mailman/listinfo/diffserv Archive: http://www2.ietf.org/mail-archive/working-groups/diffserv/current/maillist.html From diffserv-admin@ietf.org Tue Dec 5 08:12: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 SMTP id IAA10199 for ; Tue, 5 Dec 2000 08:12:52 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id HAA15339; Tue, 5 Dec 2000 07:46:22 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id HAA15308 for ; Tue, 5 Dec 2000 07:46:18 -0500 (EST) Received: from EXCHANGE.kerenix.com (pop04-1-ras1-p82.barak.net.il [212.150.1.82] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with SMTP id HAA02342 for ; Tue, 5 Dec 2000 07:46:08 -0500 (EST) Received: by EXCHANGE.kerenix.com with Internet Mail Service (5.5.2650.21) id ; Tue, 5 Dec 2000 14:45:45 +0200 Message-ID: <2B15221907365C468941FDFC02C87769CE7C@EXCHANGE.kerenix.com> From: Vadim Suraev To: "'diffserv@ietf.org'" Date: Tue, 5 Dec 2000 14:45:44 +0200 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: text/plain; charset="iso-8859-1" Subject: [Diffserv] AF PHB question Sender: diffserv-admin@ietf.org Errors-To: diffserv-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Diffserv Discussion List X-BeenThere: diffserv@ietf.org Hi, DiffServers. Is there any draft, specifies the formula for percentage of permitted packet loss inside of AF PHB under normal conditions (no rate exceeding), AF is not preempted by other PHB ? I suppose, if EF PHB specifies formula for EF conformance (EFRESOLV), should AF specify such formula for AF conformance ? Thanks. KereniX Data-Aware Optical NetworksTM ---------------------------------------------------------------------------- ------ Vadim Suraev http://www.kerenix.com Phone: +972-3-9222077 x739 Mobile: 972-53-568711 Fax: +972-3-9216769 vadim_suraev@kerenix.com 8 Hashiloach St., POB 10053, Petach-Tikva 49001 ISRAEL ---------------------------------------------------------------------------- ------ _______________________________________________ diffserv mailing list diffserv@ietf.org http://www1.ietf.org/mailman/listinfo/diffserv Archive: http://www2.ietf.org/mail-archive/working-groups/diffserv/current/maillist.html From diffserv-admin@ietf.org Tue Dec 5 11:29: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 SMTP id LAA01706 for ; Tue, 5 Dec 2000 11:29:42 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id LAA17847; Tue, 5 Dec 2000 11:04:38 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id LAA17816 for ; Tue, 5 Dec 2000 11:04:34 -0500 (EST) Received: from pmesmtp01.wcom.com (pmesmtp01.wcom.com [199.249.20.1]) by ietf.org (8.9.1a/8.9.1a) with SMTP id LAA25804 for ; Tue, 5 Dec 2000 11:04:30 -0500 (EST) Received: from CONVERSION-DAEMON by firewall.mcit.com (PMDF V5.2-32 #42256) id <0G5300C01R9RGP@firewall.mcit.com> for diffserv@ietf.org; Tue, 5 Dec 2000 16:03:27 +0000 (GMT) Received: from pmismtp01.wcomnet.com ([166.38.62.36]) by firewall.mcit.com (PMDF V5.2-32 #42256) with ESMTP id <0G5300B9JR9Q64@firewall.mcit.com> for diffserv@ietf.org; Tue, 05 Dec 2000 16:03:27 +0000 (GMT) Received: from CONVERSION-DAEMON by pmismtp01.wcomnet.com (PMDF V5.2-33 #42258) id <0G5300201R9Q74@pmismtp01.wcomnet.com> for diffserv@ietf.org; Tue, 05 Dec 2000 16:03:26 +0000 (GMT) Received: from pmismtp01.wcomnet.com by pmismtp01.wcomnet.com (PMDF V5.2-33 #42258) with SMTP id <0G5300201R9E2R@pmismtp01.wcomnet.com> for diffserv@ietf.org; Tue, 05 Dec 2000 16:03:26 +0000 (GMT) Received: from omzexch006.mcit.com ([166.37.194.37]) by pmismtp01.wcomnet.com (PMDF V5.2-33 #42258) with ESMTP id <0G53000QBR8YUD@pmismtp01.wcomnet.com> for diffserv@ietf.org; Tue, 05 Dec 2000 16:02:58 +0000 (GMT) Received: by omzexch006 with Internet Mail Service (5.5.2651.58) id ; Tue, 05 Dec 2000 16:02:57 +0000 Content-return: allowed Date: Tue, 05 Dec 2000 16:02:51 +0000 From: "Iliff, Tina" To: "Iliff, Tina" , "'diffserv@ietf.org'" Message-id: <492EB4A3F68CD411ABE800508B69362E14B3AD@RIPEXCH002.wcomnet.com> MIME-version: 1.0 X-Mailer: Internet Mail Service (5.5.2651.58) Content-type: multipart/alternative; boundary="Boundary_(ID_pl/g+P/8IMYN/s4RL4R3qw)" Subject: [Diffserv] RE: diffserv-pib-02 Sender: diffserv-admin@ietf.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. --Boundary_(ID_pl/g+P/8IMYN/s4RL4R3qw) Content-type: text/plain; charset=ISO-8859-1 All, I withdraw my second question below since after given more thought I realized a use for the values. Thank you Tina Iliff -----Original Message----- From: Iliff, Tina Sent: Monday, December 04, 2000 1:21 PM To: 'diffserv@ietf.org' Subject: diffserv-pib-02 List, After reading the latest diffserv PIB draft, diffserv-pib-02 I have the following issues/questions: 1. It seems contradictory that the qosIfClassificationCaps class provides the PEP with the flexibility to or not to support classification on ingress and the explanation of the qosClfrElementOrder attribute contains the following statement: "On a given interface, there must be a complete classifier in place at all times in the ingress direction. This means that there will always be one or more filters that match every possible pattern that could be presented in an incoming packet. There is no such requirement in the egress direction." It makes more sense to mandate a classifier on ingress since there needs to be some way of determining which packets should be treated by each specific datapath element configuration. Can someone please clarify? Recommend removing the possible value (i.e. inputIpClassification) from the qosIfClassificationCapsSpec. 2. qosIfSchedulingCaps: Please clarify the proposed use of the QueueSize and TotalQueueSize attributes given the new PIB structure(specifically the structure of the install classes). Thanks, Tina --Boundary_(ID_pl/g+P/8IMYN/s4RL4R3qw) Content-type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable RE: diffserv-pib-02

All,

I withdraw my second question below = since after given more thought I realized a use for the values.

Thank you
Tina Iliff


      -----Original = Message-----
      From:   Iliff, Tina =
      Sent:   Monday, December 04, 2000 1:21 PM
      To:     'diffserv@ietf.org'
      Subject:       = diffserv-pib-02

      List,

      After reading the latest diffserv PIB = draft, diffserv-pib-02 I have the following issues/questions:

        1.  It seems contradictory that = the qosIfClassificationCaps class provides the PEP with the flexibility = to or not to support classification on ingress and the explanation of = the qosClfrElementOrder attribute contains the following = statement:  "On a given interface, there must be a complete  = classifier  in  place  at  all  times = in   the ingress direction.  This means that there will = always be one or more filters that match every possible pattern  = that  could be presented in an incoming packet.  There is no = such requirement in the egress direction."  It makes more sense to = mandate a classifier on ingress since there needs to be some way of = determining which packets should be treated by each specific datapath = element configuration.  Can someone please clarify?  Recommend removing the possible value (i.e. = inputIpClassification) from the qosIfClassificationCapsSpec.

        1. qosIfSchedulingCaps:  Please clarify the proposed = use of the QueueSize and TotalQueueSize attributes given the new PIB = structure(specifically the structure of the install = classes).

        Thanks,
        Tina

--Boundary_(ID_pl/g+P/8IMYN/s4RL4R3qw)-- _______________________________________________ diffserv mailing list diffserv@ietf.org http://www1.ietf.org/mailman/listinfo/diffserv Archive: http://www2.ietf.org/mail-archive/working-groups/diffserv/current/maillist.html From diffserv-admin@ietf.org Tue Dec 5 11:56: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 SMTP id LAA09411 for ; Tue, 5 Dec 2000 11:56:36 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id LAA18420; Tue, 5 Dec 2000 11:33:45 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id LAA18317 for ; Tue, 5 Dec 2000 11:33:38 -0500 (EST) Received: from dgesmtp01.wcom.com (dgesmtp01.wcom.com [199.249.16.16]) by ietf.org (8.9.1a/8.9.1a) with SMTP id LAA02577 for ; Tue, 5 Dec 2000 11:33:36 -0500 (EST) Received: from CONVERSION-DAEMON by firewall.mcit.com (PMDF V5.2-33 #42260) id <0G5300E01S017I@firewall.mcit.com> for diffserv@ietf.org; Tue, 5 Dec 2000 16:19:13 +0000 (GMT) Received: from pmismtp04.wcomnet.com ([166.38.62.39]) by firewall.mcit.com (PMDF V5.2-33 #42260) with ESMTP id <0G53008OYS00AW@firewall.mcit.com> for diffserv@ietf.org; Tue, 05 Dec 2000 16:19:13 +0000 (GMT) Received: from CONVERSION-DAEMON by pmismtp04.wcomnet.com (PMDF V5.2-33 #42258) id <0G5300J01RSKKD@pmismtp04.wcomnet.com> for diffserv@ietf.org; Tue, 05 Dec 2000 16:14:45 +0000 (GMT) Received: from pmismtp04.wcomnet.com by pmismtp04.wcomnet.com (PMDF V5.2-33 #42258) with SMTP id <0G5300I01RPMZK@pmismtp04.wcomnet.com> for diffserv@ietf.org; Tue, 05 Dec 2000 16:14:43 +0000 (GMT) Received: from omzexch007.mcit.com ([166.37.194.38]) by pmismtp04.wcomnet.com (PMDF V5.2-33 #42258) with ESMTP id <0G5300HITRPAHX@pmismtp04.wcomnet.com> for diffserv@ietf.org; Tue, 05 Dec 2000 16:12:47 +0000 (GMT) Received: by omzexch007 with Internet Mail Service (5.5.2651.58) id ; Tue, 05 Dec 2000 16:17:13 +0000 Content-return: allowed Date: Tue, 05 Dec 2000 16:17:10 +0000 From: "Iliff, Tina" To: "'diffserv@ietf.org'" Cc: "Rawlins, Diana" Message-id: <492EB4A3F68CD411ABE800508B69362E14B3AF@RIPEXCH002.wcomnet.com> MIME-version: 1.0 X-Mailer: Internet Mail Service (5.5.2651.58) Content-type: multipart/alternative; boundary="Boundary_(ID_MWHd2PIWWYE4A6bGbKvggA)" Subject: [Diffserv] diffserv-pib-02 notify classes: MaxThresholds Sender: diffserv-admin@ietf.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. --Boundary_(ID_MWHd2PIWWYE4A6bGbKvggA) Content-type: text/plain; charset=ISO-8859-1 All, The explanation for the qosIfSchedulingCapsMaxThresholds attribute states that it must have a value of greater than or equal to 1. I disagree due to the fact that the PEP can specify that it does not support dropping with the qosIfMeteringCapsSpec attribute. If it specifies that it does not support dropping, then the value of qosIfSchedulingCapsMaxThresholds should be 0 or NULL to be consistent and meaningful. Please comment. Thank you, Tina Iliff --Boundary_(ID_MWHd2PIWWYE4A6bGbKvggA) Content-type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable diffserv-pib-02 notify classes: MaxThresholds

All,

The explanation for the = qosIfSchedulingCapsMaxThresholds attribute states that it must have a = value of greater than or equal to 1.  I disagree due to the fact = that the PEP can specify that it does not support dropping with the = qosIfMeteringCapsSpec attribute.  If it specifies that it does not = support dropping, then the value of qosIfSchedulingCapsMaxThresholds should be 0 or NULL to be consistent and = meaningful.  Please comment.

Thank you,
Tina Iliff

--Boundary_(ID_MWHd2PIWWYE4A6bGbKvggA)-- _______________________________________________ diffserv mailing list diffserv@ietf.org http://www1.ietf.org/mailman/listinfo/diffserv Archive: http://www2.ietf.org/mail-archive/working-groups/diffserv/current/maillist.html From diffserv-admin@ietf.org Tue Dec 5 12:45: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 SMTP id MAA21552 for ; Tue, 5 Dec 2000 12:45:34 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id MAA19411; Tue, 5 Dec 2000 12:21:36 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id MAA19365 for ; Tue, 5 Dec 2000 12:21:31 -0500 (EST) Received: from e23.nc.us.ibm.com (e23.nc.us.ibm.com [32.97.136.229]) by ietf.org (8.9.1a/8.9.1a) with SMTP id MAA17405 for ; Tue, 5 Dec 2000 12:21:29 -0500 (EST) Received: from southrelay02.raleigh.ibm.com (southrelay02.raleigh.ibm.com [9.37.3.209]) by e23.nc.us.ibm.com (8.9.3/8.9.3) with ESMTP id MAA35310 for ; Tue, 5 Dec 2000 12:18:45 -0600 Received: from d04nm200.raleigh.ibm.com (d04nm200.raleigh.ibm.com [9.67.228.37]) by southrelay02.raleigh.ibm.com (8.8.8m3/NCO v4.95) with ESMTP id MAA118802; Tue, 5 Dec 2000 12:21:02 -0500 Importance: Normal To: "'diffserv@ietf.org'" , policy@raleigh.ibm.com X-Mailer: Lotus Notes Release 5.0.3 (Intl) 21 March 2000 Message-ID: From: "Robert Moore" Date: Tue, 5 Dec 2000 12:25:30 -0500 X-MIMETrack: Serialize by Router on D04NM200/04/M/IBM(Release 5.0.3 (Intl)|21 March 2000) at 12/05/2000 12:21:28 PM MIME-Version: 1.0 Content-type: text/plain; charset=us-ascii Subject: [Diffserv] DSCP marking versus DSCP remarking Sender: diffserv-admin@ietf.org Errors-To: diffserv-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Diffserv Discussion List X-BeenThere: diffserv@ietf.org In the DiffServ Informal Model, MIB, and PIB, there is a distinction drawn between a marker that marks unmarked packets, and one that remarks packets that had been marked previously. This distinction appears most clearly in section 6.1 of the Informal Model. The MIB and the PIB make it implicitly, by importing the terms "mark" and "remark" from the Informal Model. This distinction presupposes that among the packets coming into a marker, some can be identified as already marked, and others can be identified as unmarked. I don't believe that this is the case. In QDDIM, we have come down squarely on the side that says there is no such thing as an unmarked packet, and thus no distinction between packet marking and packet remarking. Every packet has one of 64 values, decimal 0 - 63, in the DSCP field. Each of these values, including 0, is a legitimate DSCP. So a DSCP marker always takes in a packet that is already marked with a DSCP, and marks (or remarks - which word we choose isn't important) the packet with another DSCP, which may or may not be the same DSCP as the one the packet had when it came into the marker. Based on this view, we removed from the MarkerService class in QDDIM a boolean property CanRemark, which said whether a marker was allowed to mark all packets, or only packets that were not already marked when they got to it. This is *almost* just a question of wordsmithing in the three diffserv WG documents. But not quite. If there is actual disagreement in the WG about whether there is such a thing as an unmarked packet, that is, a packet that's not marked with any DSCP, then the question should be discussed until the WG reaches a consensus one way or the other. Does everybody agree with the QDDIM team that there is no such thing as a packet unmarked with any DSCP? 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://www2.ietf.org/mail-archive/working-groups/diffserv/current/maillist.html From diffserv-admin@ietf.org Tue Dec 5 15:21: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 SMTP id PAA10331 for ; Tue, 5 Dec 2000 15:21:39 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id OAA22432; Tue, 5 Dec 2000 14:53:38 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id OAA22398 for ; Tue, 5 Dec 2000 14:53:34 -0500 (EST) Received: from baucis.sc.intel.com (baucis.sc.intel.com [143.183.152.22]) by ietf.org (8.9.1a/8.9.1a) with SMTP id OAA01608 for ; Tue, 5 Dec 2000 14:53:33 -0500 (EST) Received: from SMTP (fmsmsxvs03-1.fm.intel.com [132.233.42.203]) by baucis.sc.intel.com (8.9.1a+p1/8.9.1/d: relay.m4,v 1.33 2000/11/21 19:27:27 smothers Exp $) with SMTP id TAA27721; Tue, 5 Dec 2000 19:53:28 GMT Received: from fmsmsx19.fm.intel.com ([132.233.48.19]) by 132.233.48.203 (Norton AntiVirus for Internet Email Gateways 1.0) ; Tue, 05 Dec 2000 19:53:27 0000 (GMT) Received: by fmsmsx19.fm.intel.com with Internet Mail Service (5.5.2650.21) id ; Tue, 5 Dec 2000 11:53:25 -0800 Message-ID: <4148FEAAD879D311AC5700A0C969E890572FA5@orsmsx35.jf.intel.com> From: "Hahn, Scott" To: "'Iliff, Tina'" , "'diffserv@ietf.org'" Cc: "Rawlins, Diana" Subject: RE: [Diffserv] diffserv-pib-02 notify classes: MaxThresholds Date: Tue, 5 Dec 2000 11:51:45 -0800 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: text/plain; charset="iso-8859-1" Sender: diffserv-admin@ietf.org Errors-To: diffserv-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Diffserv Discussion List X-BeenThere: diffserv@ietf.org I would agree that the attribute should allow for a 0 value. We will make the change on the next rev of the draft. -----Original Message----- From: Iliff, Tina [mailto:Tina.Iliff@WCOM.Com] Sent: Tuesday, December 05, 2000 8:17 AM To: 'diffserv@ietf.org' Cc: Rawlins, Diana Subject: [Diffserv] diffserv-pib-02 notify classes: MaxThresholds All, The explanation for the qosIfSchedulingCapsMaxThresholds attribute states that it must have a value of greater than or equal to 1. I disagree due to the fact that the PEP can specify that it does not support dropping with the qosIfMeteringCapsSpec attribute. If it specifies that it does not support dropping, then the value of qosIfSchedulingCapsMaxThresholds should be 0 or NULL to be consistent and meaningful. Please comment. Thank you, Tina Iliff _______________________________________________ diffserv mailing list diffserv@ietf.org http://www1.ietf.org/mailman/listinfo/diffserv Archive: http://www2.ietf.org/mail-archive/working-groups/diffserv/current/maillist.html From diffserv-admin@ietf.org Tue Dec 5 15:29:16 2000 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with SMTP id PAA12746 for ; Tue, 5 Dec 2000 15:29:16 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id PAA22823; Tue, 5 Dec 2000 15:00:27 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id PAA22785 for ; Tue, 5 Dec 2000 15:00:23 -0500 (EST) Received: from e21.nc.us.ibm.com (e21.nc.us.ibm.com [32.97.136.227]) by ietf.org (8.9.1a/8.9.1a) with SMTP id PAA03514 for ; Tue, 5 Dec 2000 15:00:20 -0500 (EST) Received: from southrelay02.raleigh.ibm.com (southrelay02.raleigh.ibm.com [9.37.3.209]) by e21.nc.us.ibm.com (8.9.3/8.9.3) with ESMTP id OAA37726 for ; Tue, 5 Dec 2000 14:57:30 -0600 Received: from d04nm200.raleigh.ibm.com (d04nm200.raleigh.ibm.com [9.67.228.37]) by southrelay02.raleigh.ibm.com (8.8.8m3/NCO v4.95) with ESMTP id OAA57182 for ; Tue, 5 Dec 2000 14:59:51 -0500 Importance: Normal To: "'diffserv@ietf.org'" X-Mailer: Lotus Notes Release 5.0.3 (Intl) 21 March 2000 Message-ID: From: "Robert Moore" Date: Tue, 5 Dec 2000 15:04:19 -0500 X-MIMETrack: Serialize by Router on D04NM200/04/M/IBM(Release 5.0.3 (Intl)|21 March 2000) at 12/05/2000 03:00:17 PM MIME-Version: 1.0 Content-type: text/plain; charset=us-ascii Subject: [Diffserv] Degree of detail in 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 Here is the DiffServ MIB's text describing the DSCP Mark Action Table: 3.4.1. DSCP Mark Action Table This Action is applied to traffic in order to mark it with a Diffserv Codepoint (DSCP) value, specified in the diffServDscpMarkActTable. Other marking actions might be specified elsewhere - these are outside the scope of this MIB. And here is the text from QDDIM describing the property in a DSCP marker that holds the DSCP value: 4.4.16.1 The Property DSCPValue This property is an unsigned 8-bit integer, representing a value to be used for marking the DSCP within the DS field in an IPv4 or IPv6 packet header. Since the DSCP consists of 6 bits, the values for this property are limited to the range 0..63. When the DSCP is marked, the remaining two bit in the DS field are left unchanged. Clearly there is an additional detail in the QDDIM version: the statement that the remaining two bits are left unchanged. (The range limitation 0..63 is handled in the MIB by the Dscp Textual Convention (-1 | 0..63), combined with the description text for the object, saying that the value -1 is not allowed.) In the ordinary Policy Framework treatment ("ordinary" based on one partially completed example of PCIM and PCLS, but never mind that:-), this level of detail would be documented in the Information Model (QDDIM in this case), and then incorporated by reference into the Data Models (the MIB and the PIB) derived from it. But in this case the Data Models are much more mature, and thus closer to completion, than the QDDIM. The only remaining alternatives are either not to have the detail at all in the MIB and PIB, or else to copy the QDDIM text into them. I vote for copying the text in, because of past history of cases in which "everybody knows what that means" being exposed as cases in which different people "know" different things. I don't have a complete list, but I'm sure this is not the only instance where the QDDIM has more detail than the two diffserv Data Models. 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://www2.ietf.org/mail-archive/working-groups/diffserv/current/maillist.html From diffserv-admin@ietf.org Tue Dec 5 15:36: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 SMTP id PAA13773 for ; Tue, 5 Dec 2000 15:35:58 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id PAA23221; Tue, 5 Dec 2000 15:13:12 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id PAA23191 for ; Tue, 5 Dec 2000 15:13:08 -0500 (EST) Received: from mailman.packetdesign.com (dns.PACKETDESIGN.NET [216.15.46.10]) by ietf.org (8.9.1a/8.9.1a) with SMTP id PAA07571 for ; Tue, 5 Dec 2000 15:13:06 -0500 (EST) Received: from packetdesign.com (dhcp-168-0-13.packetdesign.com [192.168.0.13]) by mailman.packetdesign.com (8.11.0/8.11.0) with ESMTP id eB5KCWQ82936; Tue, 5 Dec 2000 12:12:32 -0800 (PST) (envelope-from nichols@packetdesign.com) Message-ID: <3A2D4EE0.EBFEAE43@packetdesign.com> Date: Tue, 05 Dec 2000 12:24:00 -0800 From: Kathleen Nichols X-Mailer: Mozilla 4.73 [en] (X11; I; Linux 2.2.12 i386) X-Accept-Language: en MIME-Version: 1.0 To: Robert Moore CC: "'diffserv@ietf.org'" , policy@raleigh.ibm.com Subject: Re: [Diffserv] DSCP marking versus DSCP remarking 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 Robert Moore wrote: > ... > > This is *almost* just a question of wordsmithing in the > three diffserv WG documents. But not quite. If there is > actual disagreement in the WG about whether there is such > a thing as an unmarked packet, that is, a packet that's > not marked with any DSCP, then the question should be > discussed until the WG reaches a consensus one way or the > other. Does everybody agree with the QDDIM team that > there is no such thing as a packet unmarked with any DSCP? > With my WG co-chair hat OFF, I agree that we should just have a "marker" as a primitive element. I would not phrase this as saying "there is no such thing as a packet unmarked with any DSCP". If someone chooses to use that phrase to describe packets marked with an unknown, illegal, or unverified DSCP, it should not have any architectural effect. Kathie _______________________________________________ diffserv mailing list diffserv@ietf.org http://www1.ietf.org/mailman/listinfo/diffserv Archive: http://www2.ietf.org/mail-archive/working-groups/diffserv/current/maillist.html From diffserv-admin@ietf.org Tue Dec 5 15:36: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 SMTP id PAA13872 for ; Tue, 5 Dec 2000 15:36:45 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id PAA23327; Tue, 5 Dec 2000 15:15:10 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id PAA23252 for ; Tue, 5 Dec 2000 15:15:03 -0500 (EST) Received: from mta5.snfc21.pbi.net (mta5.snfc21.pbi.net [206.13.28.241]) by ietf.org (8.9.1a/8.9.1a) with SMTP id PAA08195 for ; Tue, 5 Dec 2000 15:15:01 -0500 (EST) Received: from allegronetworks.com ([207.214.220.6]) by mta5.snfc21.pbi.net (Sun Internet Mail Server sims.3.5.2000.01.05.12.18.p9) with ESMTP id <0G5400ER82DS0Q@mta5.snfc21.pbi.net> for diffserv@ietf.org; Tue, 5 Dec 2000 12:03:30 -0800 (PST) Date: Tue, 05 Dec 2000 12:11:05 -0800 From: Andrew Smith To: diffserv Message-id: <3A2D4BD9.5010509@allegronetworks.com> Organization: Allegro Networks MIME-version: 1.0 Content-type: text/plain; charset=us-ascii; format=flowed Content-transfer-encoding: 7bit User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; m18) Gecko/20001108 Netscape6/6.0 X-Accept-Language: en Content-Transfer-Encoding: 7bit Subject: [Diffserv] Model draft - model for algorithmic droppers Sender: diffserv-admin@ietf.org Errors-To: diffserv-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Diffserv Discussion List X-BeenThere: diffserv@ietf.org Content-Transfer-Encoding: 7bit This is a proposal for a solution to the first issue in my previous message. Ref: http://www.ietf.org/internet-drafts/draft-ietf-diffserv-model-05.txt 1. Model for Algorithmic Droppers The current figure 5 was put in at the last minute for draft-04 but I don't think it is as intuitive as the one I'd earlier proposed. In particular, the current figure 5 shows an AD as something that sits on the side of a main datapath performing its job by influencing a queue. I prefer the formulation that places an AD in-line, either before or after a queue: keeping it as is leads to quite a few awkward fixups and explanations throughout the document (this is the only case where we have an element "on the side of" a datapath so there are a bunch of "exception" cases to describe it). My original depiction of an AD doing tail-drop was: +------------------+ +-----------+ | +-------+ | 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 For head-drop the AD would be placed after the FIFO queue in the model. However, this simplified picture has a couple of shortcomings: a) it cannot represent "middle drop" or "drop a random packet from the FIFO" scenarios. b) it cannot easily be extended to do things other than "drop" e.g. to do something like ECN marking you would have to duplicate the AD with a different type of element (i.e. create an "Algorithmic Marker" element), rather than extending the base element type. Note: this is outside current scope. Someone (was it Walter or Grenville?) proposed that the "correct" solution here is to explode the AD element into its component parts: i) a packet selector algorithm that indicates on which packet we are going to act (the one we're adding to the tail? one chosen at random from within the queue? the one at the head of the queue?). ii) a trigger algorithm: whether we are actually going to do anything to the packet (this is where the R in "RED" comes in: you select Random packets for dropping by running a probability algorithm on the packet you are just adding to the tail of the queue). iii) an action e.g. "drop it", "ECN-mark it" (this could re-use the "Action" elements from elsewhere in the Model) iv) optional smoothing function(s) - could be 1 or n per-queue, could be 1 or m per-dropper. Suggest we leave this outside the discussion for now. My proposal would be that we: - explode the AD, somewhat more explicitly than we do now, into the above blocks. - keep the Algorithmic Dropper element but give it some internal structure in the draft's text (explicitly endorsing a substructure that is just implicit in the figure right now). - describe only head- and tail- packet selection, by examples and in figure (i.e. put the AD element back "in-line" in the data path: element placed either before or after the FIFO queue to indicate head or tail). - describe only "apply probability algorithm" trigger by example. - allow for external Action element ("drop it" as the only example). - keep the smoothing function stuff external. The example diagram (for a tail dropper), replacing current figure 5, would then be: +----------------+ +-----------+ | +-------+ | n |smoothing | | |trigger|<------/--|function(s)| | |alg. | | |(optional) | | +-------+ | +-----------+ | | | ^ | v | |Depth Input | +-------+ no | ------------+ to next ---------->|action |-----------> |x|x|x|x|-------> | | ? | | ------------+ e.g. Scheduler | +-------+ | FIFO +------|---------+ Algorithmic |yes Dropper v +------+ |Next |e.g. AbsDrop,Mark |Action| +------+ This still leaves the problem of the name: everybody seems to complain about "Algorithmic Dropper" but nobody has/had a better name. And now it can do things other than Drop. How about "Algorithmic", "Algorithmic Element", "Algorithmic Trigger", "Trigger Condition", "Trigger Element" or "Trigger Action"? Vote early and often (assuming you like the proposed revision of course). Andrew Smith (editor of this draft) _______________________________________________ diffserv mailing list diffserv@ietf.org http://www1.ietf.org/mailman/listinfo/diffserv Archive: http://www2.ietf.org/mail-archive/working-groups/diffserv/current/maillist.html From diffserv-admin@ietf.org Tue Dec 5 15:37: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 SMTP id PAA13999 for ; Tue, 5 Dec 2000 15:37:41 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id PAA23381; Tue, 5 Dec 2000 15:15:20 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id PAA23272 for ; Tue, 5 Dec 2000 15:15:04 -0500 (EST) Received: from mta5.snfc21.pbi.net (mta5.snfc21.pbi.net [206.13.28.241]) by ietf.org (8.9.1a/8.9.1a) with SMTP id PAA08202 for ; Tue, 5 Dec 2000 15:15:02 -0500 (EST) Received: from allegronetworks.com ([207.214.220.6]) by mta5.snfc21.pbi.net (Sun Internet Mail Server sims.3.5.2000.01.05.12.18.p9) with ESMTP id <0G5400DFW2DXLU@mta5.snfc21.pbi.net> for diffserv@ietf.org; Tue, 5 Dec 2000 12:03:34 -0800 (PST) Date: Tue, 05 Dec 2000 12:11:09 -0800 From: Andrew Smith To: diffserv Cc: Robert Moore/Raleigh/IBM Message-id: <3A2D4BDD.2030908@allegronetworks.com> Organization: Allegro Networks MIME-version: 1.0 Content-type: text/plain; charset=us-ascii; format=flowed Content-transfer-encoding: 7bit User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; m18) Gecko/20001108 Netscape6/6.0 X-Accept-Language: en Content-Transfer-Encoding: 7bit Subject: [Diffserv] Model draft - sharing elements on multiple interfaces Sender: diffserv-admin@ietf.org Errors-To: diffserv-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 a proposal for a solution to the second issue in my earlier message Ref: http://www.ietf.org/internet-drafts/draft-ietf-diffserv-model-05.txt 2. Sharing of elements amongst multiple interfaces. Bob Moore has made a good point: right now the model describes everything that happens to a packet as it arrives on ingress to *an* interface, then it goes through a routing core, then it describes what happens on egress from *an* interface. The problem is that there are very valid scenarios (and implementation architectures too, although that's not really our problem here) where you want traffic streams from multiple ingress interfaces to receive shared processing before they get to the switch fabric. Ditto for a stream on egress to receive some diffserv processing before being split out to its final egress interface. This is a fairly fundamental ommission and I don't think it can be tackled by hand-waving. So we should choose whether to support it explicitly or not. To support it, I think we need a modified top-level diagram that shows that you may repeat the routing core and subsequent "interface" blocks multiple times. The current figure 2 implies that you may have only one "ingress interface block" and one "egress interface block" per interface (the blocks are the dotted boxes in the figure). I believe we would need an additional "routing core" of some sort in between the first per-interface block and any subsequent shared-multi-interface block in order to express the interconnections (similar for egress). Do we then need arbitrary concatenations of such blocks or does 2 on ingress and 2 on egress of each suffice? I'm too lazy to draw the real picture right now (a real ASCII-art challenge to do it in only 72 columns) but it's something like this: right now we have one direction, the top half, of figure 2 as: -> I -> core -> E -> The proposal would be to modify this to something like: -> I -+-> I -> core -> E -+-> E -> | | -> I -+ +-> E -> Where "I" represents an Ingress block and "E" represents an Egress block. And you could represent the merge/split functions as additional routing cores (albeit simplified ones, still out of scope for this model: maybe this would be a use for those under-utilised Multiplexor and Demultiplexor elements but they'd have to be redefined so that their scope could span multiple interfaces - right now all elements are implicitly instantiated per-interface in this model). [I don't know if this solves Bob's issue or not - hopefully he'll let us know.] Andrew Smith (editor of this draft) _______________________________________________ diffserv mailing list diffserv@ietf.org http://www1.ietf.org/mailman/listinfo/diffserv Archive: http://www2.ietf.org/mail-archive/working-groups/diffserv/current/maillist.html From diffserv-admin@ietf.org Tue Dec 5 15:39: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 SMTP id PAA14233 for ; Tue, 5 Dec 2000 15:39:27 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id PAA23352; Tue, 5 Dec 2000 15:15:14 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id PAA23259 for ; Tue, 5 Dec 2000 15:15:03 -0500 (EST) Received: from mta5.snfc21.pbi.net (mta5.snfc21.pbi.net [206.13.28.241]) by ietf.org (8.9.1a/8.9.1a) with SMTP id PAA08198 for ; Tue, 5 Dec 2000 15:15:02 -0500 (EST) Received: from allegronetworks.com ([207.214.220.6]) by mta5.snfc21.pbi.net (Sun Internet Mail Server sims.3.5.2000.01.05.12.18.p9) with ESMTP id <0G5400G962DLJN@mta5.snfc21.pbi.net> for diffserv@ietf.org; Tue, 5 Dec 2000 12:03:23 -0800 (PST) Date: Tue, 05 Dec 2000 12:10:56 -0800 From: Andrew Smith To: diffserv Message-id: <3A2D4BD0.8040205@allegronetworks.com> Organization: Allegro Networks MIME-version: 1.0 Content-type: text/plain; charset=us-ascii; format=flowed Content-transfer-encoding: 7bit User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; m18) Gecko/20001108 Netscape6/6.0 X-Accept-Language: en Content-Transfer-Encoding: 7bit Subject: [Diffserv] Model draft - open issues list Sender: diffserv-admin@ietf.org Errors-To: diffserv-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Diffserv Discussion List X-BeenThere: diffserv@ietf.org Content-Transfer-Encoding: 7bit I think there are 3 open issues (2 technical, 1 editorial) with the current draft (I've put names at the end of each description for people who I know care about this issue). I'll offer some proposals for 1 and 2 in separate messages. 1. Section 7.1.3 Model for Algorithmic Droppers (Andrew, Grenville, Walter) The current figure 5 was put in at the last minute for draft-04 but I don't think it is as intuitive as the one I'd earlier proposed. In particular, the current figure 5 shows an AD as something that sits on the side of a main datapath performing its job by influencing a queue. I prefer the formulation that places an AD in-line, either before or after a queue: keeping it as is leads to quite a few awkward fixups and explanations throughout the document (this is the only case where we have an element "on the side of" a datapath so there are a bunch of "exception" cases to describe it). 2. Section 3.2 Sharing of elements amongst multiple interfaces (Bob, Walter) Bob Moore has made a good point: right now the model describes everything that happens to a packet as it arrives on ingress to *an* interface, then it goes through a routing core, then it describes what happens on egress from *an* interface. The problem is that there are very valid scenarios (and implementation architectures too, although that's not really our problem here) where you want traffic streams from multiple ingress interfaces to receive shared processing before they get to the switch fabric. Ditto for a stream on egress to receive some diffserv processing before being split out to its final egress interface. This is a fairly fundamental ommission and I don't think it can be tackled by hand-waving. So we should choose whether to support it explicitly or not. 3. Section 11 - dangling references to in-progress drafts. I propose to eliminate these if I cannot get a promise from some other WG chair that they will be completed in the same time-frame as this draft (i.e. submission to IESG within next 3-4 weeks). (John W, Eric, Brian, Kathie, Ed, Joel) _______________________________________________ diffserv mailing list diffserv@ietf.org http://www1.ietf.org/mailman/listinfo/diffserv Archive: http://www2.ietf.org/mail-archive/working-groups/diffserv/current/maillist.html From diffserv-admin@ietf.org Tue Dec 5 16:32: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 SMTP id QAA20864 for ; Tue, 5 Dec 2000 16:32:26 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id PAA24520; Tue, 5 Dec 2000 15:54:38 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id PAA24491 for ; Tue, 5 Dec 2000 15:54:33 -0500 (EST) Received: from diablo.cisco.com (diablo.cisco.com [171.68.224.210]) by ietf.org (8.9.1a/8.9.1a) with SMTP id PAA16217 for ; Tue, 5 Dec 2000 15:54:31 -0500 (EST) Received: from jschnizl1-pc (jschnizl-isdn1.cisco.com [171.68.12.74]) by diablo.cisco.com (8.8.6 (PHNE_14041)/CISCO.SERVER.1.2) with SMTP id MAA10253; Tue, 5 Dec 2000 12:53:27 -0800 (PST) Message-Id: <4.1.20001205151421.00b6c3a0@diablo.cisco.com> X-Sender: jschnizl@diablo.cisco.com X-Mailer: QUALCOMM Windows Eudora Pro Version 4.1 Date: Tue, 05 Dec 2000 15:53:34 -0500 To: demir , Brian E Carpenter From: John Schnizlein Subject: Re: [Diffserv] EFRESOLVE definition in the presence of excess inputburstiness Cc: diffserv@ietf.org In-Reply-To: References: <3A2BD87A.D3769361@hursley.ibm.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: diffserv-admin@ietf.org Errors-To: diffserv-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Diffserv Discussion List X-BeenThere: diffserv@ietf.org Alper, Quoting from the int-serv approach does not justify applying this approach to the (intentionally different) diff-serv approach. Diffserv chose to define a small set of mechanisms first, not services. My impression was that there was an implicit agreement to risk whether or not (or just how) useful services could be built from them. It seems to me that your choices are to accept the diffserv approach or find a rough consensus to change the strategy of the working group. At 03:15 PM 12/04/2000 -0800, demir wrote: >... I am pointing out a "PHB" definition issue. >I am talking about a problem of the current architecture >(where some MAYs won't have any effect on the current): > >- "First, we want to start out by implementing a simple set of > services, which are useful and easy to understand. At the same time, > we should not embed these services into the mechanism, but should > build a general mechanism that allows us to change the services as > our experience matures."- D. Clark / J. Wroclawski, "An Approach to > Service Allocation in the Internet" > >It seems to me that G4 along with other guideslines are >restrictive. Services (expected) are being embedded into the PHB >mechanisms. It may very well be that the EF PHB should specify that bursts larger than what an individual hop can accommodate must be dropped. The reason this is not specified is because people might think it requires implementing the meter to measure this in core devices that can be guaranteed through the configuration of the domain that they never get too large a burst. Saying that the result of too large a burst is not defined seems to me an adequate compliance with (informational) RFC 2475. We should not imply that burst meters are required on the inputs of the core ("interior nodes"). John _______________________________________________ diffserv mailing list diffserv@ietf.org http://www1.ietf.org/mailman/listinfo/diffserv Archive: http://www2.ietf.org/mail-archive/working-groups/diffserv/current/maillist.html From diffserv-admin@ietf.org Tue Dec 5 16:32: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 SMTP id QAA20923 for ; Tue, 5 Dec 2000 16:32:48 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id PAA24557; Tue, 5 Dec 2000 15:55:31 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id PAA24526 for ; Tue, 5 Dec 2000 15:55:26 -0500 (EST) Received: from cisco.com (ups.cisco.com [171.69.18.21]) by ietf.org (8.9.1a/8.9.1a) with SMTP id PAA16326 for ; Tue, 5 Dec 2000 15:55:24 -0500 (EST) Received: (from kzm@localhost) by cisco.com (8.8.8/2.6/Cisco List Logging/8.8.8) id MAA05204; Tue, 5 Dec 2000 12:54:50 -0800 (PST) From: Keith McCloghrie Message-Id: <200012052054.MAA05204@cisco.com> Subject: Re: [Diffserv] Model draft - sharing elements on multiple interfaces To: andrew@allegronetworks.com (Andrew Smith) Date: Tue, 5 Dec 2000 12:54:50 -0800 (PST) Cc: diffserv@ietf.org (diffserv), remoore@us.ibm.com (Robert Moore/Raleigh/IBM) In-Reply-To: <3A2D4BDD.2030908@allegronetworks.com> from "Andrew Smith" at Dec 05, 2000 12:11:09 PM X-Mailer: ELM [version 2.5 PL1] MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: diffserv-admin@ietf.org Errors-To: diffserv-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Diffserv Discussion List X-BeenThere: diffserv@ietf.org Content-Transfer-Encoding: 7bit I think the DiffServ MIB is only just use-able at the moment due to its surfeit of complexity, and I suggest that incorporating the below into the model and thus reflecting it into the MIB will push the MIB over the "cliff" to become of no use to anybody. Keith. > This is a proposal for a solution to the second issue in my earlier message > Ref: http://www.ietf.org/internet-drafts/draft-ietf-diffserv-model-05.txt > > 2. Sharing of elements amongst multiple interfaces. > > Bob Moore has made a good point: right now the model describes everything that > happens to a packet as it arrives on ingress to *an* interface, then it goes > through a routing core, then it describes what happens on egress from *an* > interface. The problem is that there are very valid scenarios (and > implementation architectures too, although that's not really our problem here) > where you want traffic streams from multiple ingress interfaces to receive > shared processing before they get to the switch fabric. Ditto for a stream on > egress to receive some diffserv processing before being split out to its final > egress interface. This is a fairly fundamental ommission and I don't think it > can be tackled by hand-waving. So we should choose whether to support it > explicitly or not. > > To support it, I think we need a modified top-level diagram that shows that you > may repeat the routing core and subsequent "interface" blocks multiple times. > The current figure 2 implies that you may have only one "ingress interface > block" and one "egress interface block" per interface (the blocks are the dotted > boxes in the figure). I believe we would need an additional "routing core" of > some sort in between the first per-interface block and any subsequent > shared-multi-interface block in order to express the interconnections (similar > for egress). Do we then need arbitrary concatenations of such blocks or does 2 > on ingress and 2 on egress of each suffice? > > I'm too lazy to draw the real picture right now (a real ASCII-art challenge to > do it in only 72 columns) but it's something like this: right now we have one > direction, the top half, of figure 2 as: > > -> I -> core -> E -> > > The proposal would be to modify this to something like: > > -> I -+-> I -> core -> E -+-> E -> > | | > -> I -+ +-> E -> > > Where "I" represents an Ingress block and "E" represents an Egress block. And > you could represent the merge/split functions as additional routing cores > (albeit simplified ones, still out of scope for this model: maybe this would be > a use for those under-utilised Multiplexor and Demultiplexor elements but they'd > have to be redefined so that their scope could span multiple interfaces - right > now all elements are implicitly instantiated per-interface in this model). > > [I don't know if this solves Bob's issue or not - hopefully he'll let us know.] > > Andrew Smith > (editor of this draft) > > > _______________________________________________ > diffserv mailing list > diffserv@ietf.org > http://www1.ietf.org/mailman/listinfo/diffserv > Archive: http://www2.ietf.org/mail-archive/working-groups/diffserv/current/maillist.html > > _______________________________________________ diffserv mailing list diffserv@ietf.org http://www1.ietf.org/mailman/listinfo/diffserv Archive: http://www2.ietf.org/mail-archive/working-groups/diffserv/current/maillist.html From diffserv-admin@ietf.org Tue Dec 5 16:58: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 SMTP id QAA24101 for ; Tue, 5 Dec 2000 16:58:13 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id QAA25190; Tue, 5 Dec 2000 16:24:03 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id QAA25161 for ; Tue, 5 Dec 2000 16:23:59 -0500 (EST) Received: from e23.nc.us.ibm.com (e23.nc.us.ibm.com [32.97.136.229]) by ietf.org (8.9.1a/8.9.1a) with SMTP id QAA19766 for ; Tue, 5 Dec 2000 16:23:57 -0500 (EST) Received: from southrelay02.raleigh.ibm.com (southrelay02.raleigh.ibm.com [9.37.3.209]) by e23.nc.us.ibm.com (8.9.3/8.9.3) with ESMTP id QAA49426; Tue, 5 Dec 2000 16:21:08 -0600 Received: from d04nm200.raleigh.ibm.com (d04nm200.raleigh.ibm.com [9.67.228.37]) by southrelay02.raleigh.ibm.com (8.8.8m3/NCO v4.95) with ESMTP id QAA80714; Tue, 5 Dec 2000 16:23:25 -0500 Importance: Normal Subject: Re: [Diffserv] Model draft - sharing elements on multiple interfaces To: Keith McCloghrie Cc: andrew@allegronetworks.com (Andrew Smith), diffserv@ietf.org (diffserv) X-Mailer: Lotus Notes Release 5.0.3 (Intl) 21 March 2000 Message-ID: From: "Robert Moore" Date: Tue, 5 Dec 2000 16:27:53 -0500 X-MIMETrack: Serialize by Router on D04NM200/04/M/IBM(Release 5.0.3 (Intl)|21 March 2000) at 12/05/2000 04:23:51 PM 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 Keith, I'm not sure what you're arguing for here. At least on the ingress side, sharing an element (say a Classifier) between two ingress interfaces amounts to having the dataPathStart pointers for two entries in the dataPathTable point to the same entry in the diffServClassifier table. Are you saying that the MIB currently rules this out? If so, I've missed it. Or are you saying that while the MIB doesn't currently rule it out, it should be changed so that it does? It's a little harder to describe for egress, but I think the idea would be that two Data Paths start out together, but then somehow diverge before they're done. I'm not sure exactly how to express this in terms of the Next pointers, but the same question I asked you above applies here as well: do you think that the MIB currently does outlaw this setup, or do you think that it should (but doesn't now)? Thanks. Regards, Bob Bob Moore IBM Networking Software +1-919-254-4436 remoore@us.ibm.com Keith McCloghrie on 12/05/2000 03:54:50 PM To: andrew@allegronetworks.com (Andrew Smith) cc: diffserv@ietf.org (diffserv), Robert Moore/Raleigh/IBM@IBMUS Subject: Re: [Diffserv] Model draft - sharing elements on multiple interfaces I think the DiffServ MIB is only just use-able at the moment due to its surfeit of complexity, and I suggest that incorporating the below into the model and thus reflecting it into the MIB will push the MIB over the "cliff" to become of no use to anybody. Keith. > This is a proposal for a solution to the second issue in my earlier message > Ref: http://www.ietf.org/internet-drafts/draft-ietf-diffserv-model-05.txt > > 2. Sharing of elements amongst multiple interfaces. > > Bob Moore has made a good point: right now the model describes everything that > happens to a packet as it arrives on ingress to *an* interface, then it goes > through a routing core, then it describes what happens on egress from *an* > interface. The problem is that there are very valid scenarios (and > implementation architectures too, although that's not really our problem here) > where you want traffic streams from multiple ingress interfaces to receive > shared processing before they get to the switch fabric. Ditto for a stream on > egress to receive some diffserv processing before being split out to its final > egress interface. This is a fairly fundamental ommission and I don't think it > can be tackled by hand-waving. So we should choose whether to support it > explicitly or not. > > To support it, I think we need a modified top-level diagram that shows that you > may repeat the routing core and subsequent "interface" blocks multiple times. > The current figure 2 implies that you may have only one "ingress interface > block" and one "egress interface block" per interface (the blocks are the dotted > boxes in the figure). I believe we would need an additional "routing core" of > some sort in between the first per-interface block and any subsequent > shared-multi-interface block in order to express the interconnections (similar > for egress). Do we then need arbitrary concatenations of such blocks or does 2 > on ingress and 2 on egress of each suffice? > > I'm too lazy to draw the real picture right now (a real ASCII-art challenge to > do it in only 72 columns) but it's something like this: right now we have one > direction, the top half, of figure 2 as: > > -> I -> core -> E -> > > The proposal would be to modify this to something like: > > -> I -+-> I -> core -> E -+-> E -> > | | > -> I -+ +-> E -> > > Where "I" represents an Ingress block and "E" represents an Egress block. And > you could represent the merge/split functions as additional routing cores > (albeit simplified ones, still out of scope for this model: maybe this would be > a use for those under-utilised Multiplexor and Demultiplexor elements but they'd > have to be redefined so that their scope could span multiple interfaces - right > now all elements are implicitly instantiated per-interface in this model). > > [I don't know if this solves Bob's issue or not - hopefully he'll let us know.] > > Andrew Smith > (editor of this draft) > > > _______________________________________________ > diffserv mailing list > diffserv@ietf.org > http://www1.ietf.org/mailman/listinfo/diffserv > Archive: http://www2.ietf.org/mail-archive/working-groups/diffserv/current/maillist.html > > _______________________________________________ diffserv mailing list diffserv@ietf.org http://www1.ietf.org/mailman/listinfo/diffserv Archive: http://www2.ietf.org/mail-archive/working-groups/diffserv/current/maillist.html From diffserv-admin@ietf.org Tue Dec 5 17:19: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 SMTP id RAA27427 for ; Tue, 5 Dec 2000 17:19:59 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id QAA25745; Tue, 5 Dec 2000 16:49:56 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id QAA25645 for ; Tue, 5 Dec 2000 16:49:49 -0500 (EST) Received: from bor.ellacoya.com (216-064-109-139.inaddr.vitts.com [216.64.109.139]) by ietf.org (8.9.1a/8.9.1a) with SMTP id QAA23003 for ; Tue, 5 Dec 2000 16:49:46 -0500 (EST) Received: by BOR with Internet Mail Service (5.5.2650.21) id ; Tue, 5 Dec 2000 16:42:48 -0500 Message-ID: From: "Weiss, Walter" To: "'Andrew Smith'" , diffserv Subject: RE: [Diffserv] Model draft - model for algorithmic droppers Date: Tue, 5 Dec 2000 16:42:47 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C05F04.4F2346D6" Sender: diffserv-admin@ietf.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_01C05F04.4F2346D6 Content-Type: text/plain; charset="ISO-8859-1" Andrew, > The example diagram (for a tail dropper), replacing current > figure 5, would then be: > > +----------------+ +-----------+ > | +-------+ | n |smoothing | > | |trigger|<------/--|function(s)| > | |alg. | | |(optional) | > | +-------+ | +-----------+ > | | | ^ > | v | |Depth > Input | +-------+ no | ------------+ to next > ---------->|action |-----------> |x|x|x|x|-------> > | | ? | | ------------+ e.g. Scheduler > | +-------+ | FIFO > +------|---------+ > Algorithmic |yes > Dropper v > +------+ > |Next |e.g. AbsDrop,Mark > |Action| > +------+ > I like this picture better than the previous version. However, I have a couple of observations. First, there is a fairly lengthy discussion of queuing blocks (algorithmic droppers, queues, and schedulers) and the relationships between them. When you seperate the drop function from the triggering function, you introduce the possibility if an action in the middle of queuing block, creating a number of inconsistencies in this portion of the text. It may be helpful to add some additional text recognizing that a Marking action would (MUST?) be bound back to the same FIFO as the no path. > This still leaves the problem of the name: everybody seems to > complain about > "Algorithmic Dropper" but nobody has/had a better name. And > now it can do things > other than Drop. How about "Algorithmic", "Algorithmic > Element", "Algorithmic > Trigger", "Trigger Condition", "Trigger Element" or "Trigger > Action"? Vote early > and often (assuming you like the proposed revision of course). Whatever this new block does, it will now have to be defined as a logically seperate block. Staying with the theme of other terms (Classifier, Meter, Dropper, etc.) I am fine with the term "Trigger". regards, -Walter ------_=_NextPart_001_01C05F04.4F2346D6 Content-Type: text/html; charset="ISO-8859-1" Content-Transfer-Encoding: quoted-printable RE: [Diffserv] Model draft - model for algorithmic = droppers

Andrew,

> The example diagram (for a tail dropper), = replacing current
> figure 5, would then be:
>
>          = +----------------+    +-----------+
>          = |  +-------+     | n  |smoothing  = |
>          = |  |trigger|<------/--|function(s)|
>          = |  |alg.   |     |    = |(optional) |
>          = |  +-------+     |    = +-----------+
>          = |      = |         = |       ^
>          = |      = v         = |       |Depth
>    Input |  +-------+ = no  |   ------------+  to next
> ---------->|action |-----------> = |x|x|x|x|------->
>          = |  |   ?   |     = |   ------------+  e.g. Scheduler
>          = |  +-------+     = |      FIFO
>          = +------|---------+
>    Algorithmic  |yes
>    = Dropper      v
>          = ;    +------+
>          = ;    |Next  |e.g. AbsDrop,Mark
>          = ;    |Action|
>          = ;    +------+
>
I like this picture better than the previous = version. However, I have a couple of observations. First, there is a = fairly lengthy discussion of queuing blocks (algorithmic droppers, = queues, and schedulers) and the relationships between them. When you = seperate the drop function from the triggering function, you introduce = the possibility if an action in the middle of queuing block, creating a = number of inconsistencies in this portion of the text. It may be = helpful to add some additional text recognizing that a Marking action = would (MUST?) be bound back to the same FIFO as the no path.

> This still leaves the problem of the name: = everybody seems to
> complain about
> "Algorithmic Dropper" but nobody = has/had a better name. And
> now it can do things
> other than Drop. How about = "Algorithmic", "Algorithmic
> Element", "Algorithmic
> Trigger", "Trigger Condition", = "Trigger Element" or "Trigger
> Action"? Vote early
> and often (assuming you like the proposed = revision of course).

Whatever this new block does, it will now have to be = defined as a logically seperate block. Staying with the theme of other = terms (Classifier, Meter, Dropper, etc.) I am fine with the term = "Trigger".

regards,

-Walter

------_=_NextPart_001_01C05F04.4F2346D6-- _______________________________________________ diffserv mailing list diffserv@ietf.org http://www1.ietf.org/mailman/listinfo/diffserv Archive: http://www2.ietf.org/mail-archive/working-groups/diffserv/current/maillist.html From diffserv-admin@ietf.org Tue Dec 5 17:54: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 SMTP id RAA05349 for ; Tue, 5 Dec 2000 17:54:57 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id RAA26385; Tue, 5 Dec 2000 17:20:09 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id RAA26355 for ; Tue, 5 Dec 2000 17:20:05 -0500 (EST) Received: from cisco.com (ups.cisco.com [171.69.18.21]) by ietf.org (8.9.1a/8.9.1a) with SMTP id RAA27455 for ; Tue, 5 Dec 2000 17:20:04 -0500 (EST) Received: (from kzm@localhost) by cisco.com (8.8.8/2.6/Cisco List Logging/8.8.8) id OAA22003; Tue, 5 Dec 2000 14:19:33 -0800 (PST) From: Keith McCloghrie Message-Id: <200012052219.OAA22003@cisco.com> Subject: Re: [Diffserv] Model draft - sharing elements on multiple interfaces To: remoore@us.ibm.com (Robert Moore) Date: Tue, 5 Dec 2000 14:19:33 -0800 (PST) Cc: kzm@cisco.com (Keith McCloghrie), andrew@allegronetworks.com (Andrew Smith), diffserv@ietf.org (diffserv) In-Reply-To: from "Robert Moore" at Dec 05, 2000 04:27:53 PM X-Mailer: ELM [version 2.5 PL1] MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: diffserv-admin@ietf.org Errors-To: diffserv-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Diffserv Discussion List X-BeenThere: diffserv@ietf.org Content-Transfer-Encoding: 7bit Bob, I was arguing against additional complexity, which was what I believed would ensue from Andrew's proposed change from: > > -> I -> core -> E -> > > > > The proposal would be to modify this to something like: > > > > -> I -+-> I -> core -> E -+-> E -> > > | | > > -> I -+ +-> E -> I think it would be possible to allow merging on ingress just by removing the restriction on two data paths merging, which is stated in this ASN.1 comment (I think that's the only place it's specified): -- The use of next pointer to point to diffserv functional datapath -- element of a different datapath is not allowed I agree it's harder for egress which requries splitting, for which I think the current MIB structure is insufficient, and my concern is that a MIB structure which would allow it is going to be more complex. Keith. > Keith, > > I'm not sure what you're arguing for here. At least > on the ingress side, sharing an element (say a > Classifier) between two ingress interfaces amounts > to having the dataPathStart pointers for two entries > in the dataPathTable point to the same entry in the > diffServClassifier table. Are you saying that the MIB > currently rules this out? If so, I've missed it. Or > are you saying that while the MIB doesn't currently > rule it out, it should be changed so that it does? > > It's a little harder to describe for egress, but I > think the idea would be that two Data Paths start out > together, but then somehow diverge before they're done. > I'm not sure exactly how to express this in terms of > the Next pointers, but the same question I asked you > above applies here as well: do you think that the MIB > currently does outlaw this setup, or do you think that > it should (but doesn't now)? > > Thanks. > > Regards, > Bob > > Bob Moore > IBM Networking Software > +1-919-254-4436 > remoore@us.ibm.com > > > > Keith McCloghrie on 12/05/2000 03:54:50 PM > > To: andrew@allegronetworks.com (Andrew Smith) > cc: diffserv@ietf.org (diffserv), Robert Moore/Raleigh/IBM@IBMUS > Subject: Re: [Diffserv] Model draft - sharing elements on multiple > interfaces > > > > I think the DiffServ MIB is only just use-able at the moment due to > its surfeit of complexity, and I suggest that incorporating the below > into the model and thus reflecting it into the MIB will push the MIB > over the "cliff" to become of no use to anybody. > > Keith. > > > This is a proposal for a solution to the second issue in my earlier > message > > Ref: http://www.ietf.org/internet-drafts/draft-ietf-diffserv-model-05.txt > > > > 2. Sharing of elements amongst multiple interfaces. > > > > Bob Moore has made a good point: right now the model describes everything > that > > happens to a packet as it arrives on ingress to *an* interface, then it > goes > > through a routing core, then it describes what happens on egress from > *an* > > interface. The problem is that there are very valid scenarios (and > > implementation architectures too, although that's not really our problem > here) > > where you want traffic streams from multiple ingress interfaces to > receive > > shared processing before they get to the switch fabric. Ditto for a > stream on > > egress to receive some diffserv processing before being split out to its > final > > egress interface. This is a fairly fundamental ommission and I don't > think it > > can be tackled by hand-waving. So we should choose whether to support it > > explicitly or not. > > > > To support it, I think we need a modified top-level diagram that shows > that you > > may repeat the routing core and subsequent "interface" blocks multiple > times. > > The current figure 2 implies that you may have only one "ingress > interface > > block" and one "egress interface block" per interface (the blocks are the > dotted > > boxes in the figure). I believe we would need an additional "routing > core" of > > some sort in between the first per-interface block and any subsequent > > shared-multi-interface block in order to express the interconnections > (similar > > for egress). Do we then need arbitrary concatenations of such blocks or > does 2 > > on ingress and 2 on egress of each suffice? > > > > I'm too lazy to draw the real picture right now (a real ASCII-art > challenge to > > do it in only 72 columns) but it's something like this: right now we have > one > > direction, the top half, of figure 2 as: > > > > -> I -> core -> E -> > > > > The proposal would be to modify this to something like: > > > > -> I -+-> I -> core -> E -+-> E -> > > | | > > -> I -+ +-> E -> > > > > Where "I" represents an Ingress block and "E" represents an Egress block. > And > > you could represent the merge/split functions as additional routing cores > > (albeit simplified ones, still out of scope for this model: maybe this > would be > > a use for those under-utilised Multiplexor and Demultiplexor elements but > they'd > > have to be redefined so that their scope could span multiple interfaces - > right > > now all elements are implicitly instantiated per-interface in this > model). > > > > [I don't know if this solves Bob's issue or not - hopefully he'll let us > know.] > > > > Andrew Smith > > (editor of this draft) > > > > > > _______________________________________________ > > diffserv mailing list > > diffserv@ietf.org > > http://www1.ietf.org/mailman/listinfo/diffserv > > Archive: > http://www2.ietf.org/mail-archive/working-groups/diffserv/current/maillist.html > > > > > > > > > _______________________________________________ diffserv mailing list diffserv@ietf.org http://www1.ietf.org/mailman/listinfo/diffserv Archive: http://www2.ietf.org/mail-archive/working-groups/diffserv/current/maillist.html From diffserv-admin@ietf.org Tue Dec 5 19:21:40 2000 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with SMTP id TAA20270 for ; Tue, 5 Dec 2000 19:21:40 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id SAA27495; Tue, 5 Dec 2000 18:38:40 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id SAA27467 for ; Tue, 5 Dec 2000 18:38:36 -0500 (EST) Received: from cisco.com (ups.cisco.com [171.69.18.21]) by ietf.org (8.9.1a/8.9.1a) with SMTP id SAA14613 for ; Tue, 5 Dec 2000 18:38:34 -0500 (EST) Received: (from kzm@localhost) by cisco.com (8.8.8/2.6/Cisco List Logging/8.8.8) id PAA08271; Tue, 5 Dec 2000 15:38:03 -0800 (PST) From: Keith McCloghrie Message-Id: <200012052338.PAA08271@cisco.com> Subject: Re: [Diffserv] Model draft - sharing elements on multiple interfaces To: kzm@cisco.com (Keith McCloghrie) Date: Tue, 5 Dec 2000 15:38:03 -0800 (PST) Cc: remoore@us.ibm.com (Robert Moore), kzm@cisco.com (Keith McCloghrie), andrew@allegronetworks.com (Andrew Smith), diffserv@ietf.org (diffserv) In-Reply-To: <200012052219.OAA22003@cisco.com> from "Keith McCloghrie" at Dec 05, 2000 02:19:33 PM X-Mailer: ELM [version 2.5 PL1] MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: diffserv-admin@ietf.org Errors-To: diffserv-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Diffserv Discussion List X-BeenThere: diffserv@ietf.org Content-Transfer-Encoding: 7bit A further thought concerning the definition of StaticRowPointer. While I think it's inappropriate for the DESCRIPTION of StaticRowPointer to include a discussion of "cloning", nevertheless that DESCRIPTION defines the TC's "additional semantics" as: The additional semantics of this textual convention, relative to RowPointer, are related to the object the pointer is pointing to. The pointed-to object may have more than one parent object pointing to it, indicating the pointed-to object can be shared by one or more parent objects. Now, if two data paths merge (see below), then that means that two xxxNext pointers point to the same "pointed-to object", which by the definition above says that the xxxNext pointers should be StaticRowPointer's !! That's probably not what you had in mind ?? Keith. > Bob, > > I was arguing against additional complexity, which was what I believed > would ensue from Andrew's proposed change from: > > > > -> I -> core -> E -> > > > > > > The proposal would be to modify this to something like: > > > > > > -> I -+-> I -> core -> E -+-> E -> > > > | | > > > -> I -+ +-> E -> > > I think it would be possible to allow merging on ingress just by > removing the restriction on two data paths merging, which is stated > in this ASN.1 comment (I think that's the only place it's specified): > > -- The use of next pointer to point to diffserv functional datapath > -- element of a different datapath is not allowed > > I agree it's harder for egress which requries splitting, for which > I think the current MIB structure is insufficient, and my concern is > that a MIB structure which would allow it is going to be more complex. > > Keith. > > > > Keith, > > > > I'm not sure what you're arguing for here. At least > > on the ingress side, sharing an element (say a > > Classifier) between two ingress interfaces amounts > > to having the dataPathStart pointers for two entries > > in the dataPathTable point to the same entry in the > > diffServClassifier table. Are you saying that the MIB > > currently rules this out? If so, I've missed it. Or > > are you saying that while the MIB doesn't currently > > rule it out, it should be changed so that it does? > > > > It's a little harder to describe for egress, but I > > think the idea would be that two Data Paths start out > > together, but then somehow diverge before they're done. > > I'm not sure exactly how to express this in terms of > > the Next pointers, but the same question I asked you > > above applies here as well: do you think that the MIB > > currently does outlaw this setup, or do you think that > > it should (but doesn't now)? > > > > Thanks. > > > > Regards, > > Bob > > > > Bob Moore > > IBM Networking Software > > +1-919-254-4436 > > remoore@us.ibm.com > > > > > > > > Keith McCloghrie on 12/05/2000 03:54:50 PM > > > > To: andrew@allegronetworks.com (Andrew Smith) > > cc: diffserv@ietf.org (diffserv), Robert Moore/Raleigh/IBM@IBMUS > > Subject: Re: [Diffserv] Model draft - sharing elements on multiple > > interfaces > > > > > > > > I think the DiffServ MIB is only just use-able at the moment due to > > its surfeit of complexity, and I suggest that incorporating the below > > into the model and thus reflecting it into the MIB will push the MIB > > over the "cliff" to become of no use to anybody. > > > > Keith. > > > > > This is a proposal for a solution to the second issue in my earlier > > message > > > Ref: http://www.ietf.org/internet-drafts/draft-ietf-diffserv-model-05.txt > > > > > > 2. Sharing of elements amongst multiple interfaces. > > > > > > Bob Moore has made a good point: right now the model describes everything > > that > > > happens to a packet as it arrives on ingress to *an* interface, then it > > goes > > > through a routing core, then it describes what happens on egress from > > *an* > > > interface. The problem is that there are very valid scenarios (and > > > implementation architectures too, although that's not really our problem > > here) > > > where you want traffic streams from multiple ingress interfaces to > > receive > > > shared processing before they get to the switch fabric. Ditto for a > > stream on > > > egress to receive some diffserv processing before being split out to its > > final > > > egress interface. This is a fairly fundamental ommission and I don't > > think it > > > can be tackled by hand-waving. So we should choose whether to support it > > > explicitly or not. > > > > > > To support it, I think we need a modified top-level diagram that shows > > that you > > > may repeat the routing core and subsequent "interface" blocks multiple > > times. > > > The current figure 2 implies that you may have only one "ingress > > interface > > > block" and one "egress interface block" per interface (the blocks are the > > dotted > > > boxes in the figure). I believe we would need an additional "routing > > core" of > > > some sort in between the first per-interface block and any subsequent > > > shared-multi-interface block in order to express the interconnections > > (similar > > > for egress). Do we then need arbitrary concatenations of such blocks or > > does 2 > > > on ingress and 2 on egress of each suffice? > > > > > > I'm too lazy to draw the real picture right now (a real ASCII-art > > challenge to > > > do it in only 72 columns) but it's something like this: right now we have > > one > > > direction, the top half, of figure 2 as: > > > > > > -> I -> core -> E -> > > > > > > The proposal would be to modify this to something like: > > > > > > -> I -+-> I -> core -> E -+-> E -> > > > | | > > > -> I -+ +-> E -> > > > > > > Where "I" represents an Ingress block and "E" represents an Egress block. > > And > > > you could represent the merge/split functions as additional routing cores > > > (albeit simplified ones, still out of scope for this model: maybe this > > would be > > > a use for those under-utilised Multiplexor and Demultiplexor elements but > > they'd > > > have to be redefined so that their scope could span multiple interfaces - > > right > > > now all elements are implicitly instantiated per-interface in this > > model). > > > > > > [I don't know if this solves Bob's issue or not - hopefully he'll let us > > know.] > > > > > > Andrew Smith > > > (editor of this draft) > > > > > > > > > _______________________________________________ > > > diffserv mailing list > > > diffserv@ietf.org > > > http://www1.ietf.org/mailman/listinfo/diffserv > > > Archive: > > http://www2.ietf.org/mail-archive/working-groups/diffserv/current/maillist.html > > > > > > > > > > > > > > > > > > > _______________________________________________ > diffserv mailing list > diffserv@ietf.org > http://www1.ietf.org/mailman/listinfo/diffserv > Archive: http://www2.ietf.org/mail-archive/working-groups/diffserv/current/maillist.html > > _______________________________________________ diffserv mailing list diffserv@ietf.org http://www1.ietf.org/mailman/listinfo/diffserv Archive: http://www2.ietf.org/mail-archive/working-groups/diffserv/current/maillist.html From diffserv-admin@ietf.org Tue Dec 5 21:40:08 2000 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with SMTP id VAA18649 for ; Tue, 5 Dec 2000 21:40:08 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id UAA28918; Tue, 5 Dec 2000 20:42:52 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id UAA28882 for ; Tue, 5 Dec 2000 20:42:48 -0500 (EST) Received: from palgong.knu.ac.kr (palgong.kyungpook.ac.kr [155.230.12.2]) by ietf.org (8.9.1a/8.9.1a) with SMTP id UAA04592 for ; Tue, 5 Dec 2000 20:42:45 -0500 (EST) Received: from guru0109 (p14_213.kyungpook.ac.kr [155.230.14.213]) by palgong.knu.ac.kr (8.11.0/8.11.0) with SMTP id eB61hD800970 for ; Wed, 6 Dec 2000 10:43:14 +0900 (KST) Message-ID: <000d01c05f25$54a93d60$d50ee69b@guru0109> From: "Young S. Choi" To: Date: Wed, 6 Dec 2000 10:39:10 +0900 MIME-Version: 1.0 Content-Type: text/plain; charset="ks_c_5601-1987" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.00.3018.1300 X-MimeOLE: Produced By Microsoft MimeOLE V5.00.3018.1300 Content-Transfer-Encoding: 7bit Subject: [Diffserv] The position of IntServ/RSVP, DiffServ in the Internet network model Sender: diffserv-admin@ietf.org Errors-To: diffserv-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 DiffServer I read Xipeng Xiao and Lionel Ni, "Internet QoS: A Big Picture", IEEE Network Magazine, March/April, pp. 8-18, 1999. (you can get above paper in http://www.cse.msu.edu/~xiaoxipe/) Last of that paper, author shows the position of IntServ & DiffServ as transport layer. Well, I can't sure whether intserv is osi layer 4 or not. But I have thought DiffServ OSI 3 Layer. I mean, Network layer. Am I wrong? I can't find any reason about why diffserv is mapped to transport layer. Thanks a lot in advance, And with best regards... -- Young S.Choi _______________________________________________ diffserv mailing list diffserv@ietf.org http://www1.ietf.org/mailman/listinfo/diffserv Archive: http://www2.ietf.org/mail-archive/working-groups/diffserv/current/maillist.html From diffserv-admin@ietf.org Wed Dec 6 01:12:31 2000 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with SMTP id BAA09995 for ; Wed, 6 Dec 2000 01:12:31 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id AAA01430; Wed, 6 Dec 2000 00:52:50 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id AAA01398 for ; Wed, 6 Dec 2000 00:52:46 -0500 (EST) Received: from usc.edu (root@usc.edu [128.125.253.136]) by ietf.org (8.9.1a/8.9.1a) with SMTP id AAA01310 for ; Wed, 6 Dec 2000 00:52:46 -0500 (EST) Received: from koh-sun005.usc.edu (demir@koh-sun005.usc.edu [128.125.5.185]) by usc.edu (8.9.3.1/8.9.3/usc) with ESMTP id VAA25311; Tue, 5 Dec 2000 21:52:43 -0800 (PST) Received: from localhost (demir@localhost) by koh-sun005.usc.edu (8.9.3.1/8.9.3/usc) with ESMTP id VAA02188; Tue, 5 Dec 2000 21:52:45 -0800 (PST) Date: Tue, 5 Dec 2000 21:52:44 -0800 (PST) From: demir To: John Schnizlein cc: Brian E Carpenter , diffserv@ietf.org Subject: Re: [Diffserv] EFRESOLVE definition in the presence of excess inputburstiness In-Reply-To: <4.1.20001205151421.00b6c3a0@diablo.cisco.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: diffserv-admin@ietf.org Errors-To: diffserv-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Diffserv Discussion List X-BeenThere: diffserv@ietf.org John, > Quoting from the int-serv approach does not justify applying > this approach to the (intentionally different) diff-serv approach. John, What I quoted is NOT an "approach", It is a "fundamental design issue" (That's how I see it). I don't know if this "fundamental design issue" was around before IntServ. I assume it was, because there have been a lot of "thinkers". If you read the "Fundamental Design Issues for the Future Internet.", IEEE Journal on Selected Areas in Communications, Vol 13, No. 7, pp. 1176-1188, September 1995, Scott Shenker", you can get more info. Does anyone know if it is the "first" paper addressing this issue? > Diffserv chose to define a small set of mechanisms first, not services. > My impression was that there was an implicit agreement to risk > whether or not (or just how) useful services could be built from them. That's what I am arguing about. I agree that Diffserv chose to define a small set of mechanisms first, not services. That's how a QoS architecture should be. I am arguing about this "implicit agreement" if there is such a thing. If there is, it should be an "explicit aggrement". How I see it is now is that it is an "explicit aggreement and they are on the RFCs of Diffserv. What I am saying is this can be "relaxed and generalized". It won't change anything on the current work. It will leave an "open window". This should be the "philosophy" behind any architecture (I think). Let me quoto a very new lines that David Clark posted it today. "If you are building a network to hook together computer applications, where there may be a large number, and "you" may not even know what some of them are, building the response into the network layer will not work as well."- David Clark. Could you point me out a reference about "useful services". Is there such an aggrement on them? I assume not. If there is, probably, "application level" is done. If "application level is done", the most efficient way to bild the netwotk would be is that to hook up the "services" into the "mechanisms". I think this won't happen. If it does, I guess "the limits of human brain will have been reached". And if this happens, lots of "ifs" wil go on and go on, finally, "everthing will be bounded". This is against the "evolution" and let's not go there. Alper K. Demir > > It seems to me that your choices are to accept the diffserv approach > or find a rough consensus to change the strategy of the working group. > > At 03:15 PM 12/04/2000 -0800, demir wrote: > >... I am pointing out a "PHB" definition issue. > >I am talking about a problem of the current architecture > >(where some MAYs won't have any effect on the current): > > > >- "First, we want to start out by implementing a simple set of > > services, which are useful and easy to understand. At the same time, > > we should not embed these services into the mechanism, but should > > build a general mechanism that allows us to change the services as > > our experience matures."- D. Clark / J. Wroclawski, "An Approach to > > Service Allocation in the Internet" > > > >It seems to me that G4 along with other guideslines are > >restrictive. Services (expected) are being embedded into the PHB > >mechanisms. > > It may very well be that the EF PHB should specify that bursts larger > than what an individual hop can accommodate must be dropped. The > reason this is not specified is because people might think it requires > implementing the meter to measure this in core devices that can be > guaranteed through the configuration of the domain that they never get > too large a burst. Saying that the result of too large a burst is not > defined seems to me an adequate compliance with (informational) RFC 2475. > We should not imply that burst meters are required on the inputs of > the core ("interior nodes"). > > John > _______________________________________________ diffserv mailing list diffserv@ietf.org http://www1.ietf.org/mailman/listinfo/diffserv Archive: http://www2.ietf.org/mail-archive/working-groups/diffserv/current/maillist.html From diffserv-admin@ietf.org Wed Dec 6 08:50: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 SMTP id IAA11288 for ; Wed, 6 Dec 2000 08:50:36 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id IAA13357; Wed, 6 Dec 2000 08:17:43 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id IAA13329 for ; Wed, 6 Dec 2000 08:16:40 -0500 (EST) Received: from smtp4.cluster.oleane.net ([195.25.12.62]) by ietf.org (8.9.1a/8.9.1a) with SMTP id IAA03648 for ; Wed, 6 Dec 2000 08:16:40 -0500 (EST) Received: from oleane (dyn-1-1-091.Vin.dialup.oleane.fr [195.25.4.91]) by smtp4.cluster.oleane.net with SMTP id eB6DFIi91889 for ; Wed, 6 Dec 2000 14:15:18 +0100 (CET) Message-ID: <006f01c05f86$e5e32960$8001a8c0@oleane.com> From: "Peter Lewis" To: Date: Wed, 6 Dec 2000 14:17:34 +0100 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_006C_01C05F8F.474C03E0" X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.00.2314.1300 X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2314.1300 Subject: [Diffserv] IP.Net call for papers Sender: diffserv-admin@ietf.org Errors-To: diffserv-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Diffserv Discussion List X-BeenThere: diffserv@ietf.org This is a multi-part message in MIME format. ------=_NextPart_000_006C_01C05F8F.474C03E0 Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable The dead line for the IP.Net call for papers has been postponed to = December 22nd. Get more details at: http://www.upperside.fr/baipnet.htm Due to the success of the exhibition part, the event will take place = from 19 to 22 June at the Sofitel Hotel in Paris. ------=_NextPart_000_006C_01C05F8F.474C03E0 Content-Type: text/html; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable
The dead line for the IP.Net call = for papers has=20 been postponed to December 22nd.
Get more details at:
http://www.upperside.fr/baip= net.htm
Due to the success of the exhibition = part, the=20 event will take place from 19 to 22 June at the Sofitel Hotel in=20 Paris.
 
------=_NextPart_000_006C_01C05F8F.474C03E0-- _______________________________________________ diffserv mailing list diffserv@ietf.org http://www1.ietf.org/mailman/listinfo/diffserv Archive: http://www2.ietf.org/mail-archive/working-groups/diffserv/current/maillist.html From diffserv-admin@ietf.org Wed Dec 6 10:41: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 SMTP id KAA02161 for ; Wed, 6 Dec 2000 10:41:50 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id KAA15221; Wed, 6 Dec 2000 10:09:41 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id KAA15189 for ; Wed, 6 Dec 2000 10:09:37 -0500 (EST) 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 SMTP id KAA26634 for ; Wed, 6 Dec 2000 10:09:37 -0500 (EST) Received: from southrelay01.raleigh.ibm.com (southrelay01.raleigh.ibm.com [9.37.3.208]) by e24.nc.us.ibm.com (8.9.3/8.9.3) with ESMTP id KAA39394; Wed, 6 Dec 2000 10:11:01 -0600 Received: from d04nm200.raleigh.ibm.com (d04nm200.raleigh.ibm.com [9.67.228.37]) by southrelay01.raleigh.ibm.com (8.8.8m3/NCO v4.95) with ESMTP id KAA37238; Wed, 6 Dec 2000 10:09:07 -0500 Importance: Normal Subject: Re: [Diffserv] Model draft - model for algorithmic droppers To: Andrew Smith Cc: diffserv X-Mailer: Lotus Notes Release 5.0.3 (Intl) 21 March 2000 Message-ID: From: "Robert Moore" Date: Wed, 6 Dec 2000 10:13:32 -0500 X-MIMETrack: Serialize by Router on D04NM200/04/M/IBM(Release 5.0.3 (Intl)|21 March 2000) at 12/06/2000 10:09:34 AM MIME-Version: 1.0 Content-type: text/plain; charset=us-ascii Sender: diffserv-admin@ietf.org Errors-To: diffserv-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Diffserv Discussion List X-BeenThere: diffserv@ietf.org I also raised questions related to this topic on the list, last Friday. Interestingly, I concluded that the existing Figure 5 gave the more useful view. The problem I have with the direction you're proposing now is not the picture, but the words that you use to describe the operation of an algorithmic dropper. In trying to emphasize its similarity with other conditioning elements, you say that a dropper makes a drop decision on a packet that "arrive[s] at its input." But I see a difference between dropping a packet that's "in" the dropper, and dropping a packet that's sitting at some specified position in a queue (which is a different conditioning element). The only way to make it right, and I'm *not* going to try to draw this, would be to say that when there's a tail dropper involved, the last position in the queue is *in* the tail dropper, rather than in the queue object. Similarly, a head dropper would contain the first position in the queue. With this arrangement, putting a packet onto the tail of a queue would be identical to having it arrive at the tail dropper's input. And moving up from position 2 to position 1 in a queue would be identical to arriving at the head dropper's input. I don't like this formulation at all: it's ugly to have the queue element represent most, but not quite all, of the positions in a queue. And the "next" associations between a tail dropper and its queue, and between a queue and its head dropper, become very different from the other "next" associations in the model. But if you're going to put the algorithmic droppers in the data path, and if you're going to say that they act on packets that arrive at their inputs, then I think you have to say something like this. A somewhat independent point: if you're going to represent head droppers in the way you propose, then you're going to have to amend the "canonical" orders of conditioning elements in a queuing block and in a TCB. In both cases these canonical orders exclude the case of a queue followed immediately by an algorithmic dropper. 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://www2.ietf.org/mail-archive/working-groups/diffserv/current/maillist.html From diffserv-admin@ietf.org Wed Dec 6 11:10:52 2000 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with SMTP id LAA08969 for ; Wed, 6 Dec 2000 11:10:48 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id KAA15668; Wed, 6 Dec 2000 10:39:56 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id KAA15645 for ; Wed, 6 Dec 2000 10:39:52 -0500 (EST) Received: from pmesmtp01.wcom.com (pmesmtp01.wcom.com [199.249.20.1]) by ietf.org (8.9.1a/8.9.1a) with SMTP id KAA01714 for ; Wed, 6 Dec 2000 10:39:51 -0500 (EST) Received: from CONVERSION-DAEMON by firewall.mcit.com (PMDF V5.2-32 #42256) id <0G5500301KSPEV@firewall.mcit.com> for diffserv@ietf.org; Wed, 6 Dec 2000 15:38:49 +0000 (GMT) Received: from pmismtp01.wcomnet.com ([166.38.62.36]) by firewall.mcit.com (PMDF V5.2-32 #42256) with ESMTP id <0G55000N3KSP7T@firewall.mcit.com>; Wed, 06 Dec 2000 15:38:49 +0000 (GMT) Received: from CONVERSION-DAEMON by pmismtp01.wcomnet.com (PMDF V5.2-33 #42258) id <0G5500001KSOSP@pmismtp01.wcomnet.com>; Wed, 06 Dec 2000 15:38:48 +0000 (GMT) Received: from pmismtp01.wcomnet.com by pmismtp01.wcomnet.com (PMDF V5.2-33 #42258) with SMTP id <0G5500001KSIRF@pmismtp01.wcomnet.com>; Wed, 06 Dec 2000 15:38:48 +0000 (GMT) Received: from omzexch006.mcit.com ([166.37.194.37]) by pmismtp01.wcomnet.com (PMDF V5.2-33 #42258) with ESMTP id <0G5500IMXKSBAI@pmismtp01.wcomnet.com>; Wed, 06 Dec 2000 15:38:35 +0000 (GMT) Received: by omzexch006 with Internet Mail Service (5.5.2651.58) id ; Wed, 06 Dec 2000 15:38:35 +0000 Content-return: allowed Date: Wed, 06 Dec 2000 15:38:33 +0000 From: "Iliff, Tina" Subject: RE: [Diffserv] The position of IntServ/RSVP, DiffServ in the Inte rnet network model To: "'Young S. Choi'" , diffserv@ietf.org Message-id: <492EB4A3F68CD411ABE800508B69362E14B3BF@RIPEXCH002.wcomnet.com> MIME-version: 1.0 X-Mailer: Internet Mail Service (5.5.2651.58) Content-type: multipart/alternative; boundary="Boundary_(ID_nyCyyhZrBpvPSCuYvnLYpw)" Sender: diffserv-admin@ietf.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. --Boundary_(ID_nyCyyhZrBpvPSCuYvnLYpw) Content-type: text/plain; charset=ISO-8859-1 My opinion is that it is closer to the application layer vice the network layer. In other words it does not serve to determine where traffic is going...well, RSVP in a way does; however, Diffserv does not explicitly perform this action Tina Iliff -----Original Message----- From: Young S. Choi [mailto:guru0109@palgong.knu.ac.kr] Sent: Tuesday, December 05, 2000 7:39 PM To: diffserv@ietf.org Subject: [Diffserv] The position of IntServ/RSVP, DiffServ in the Internet network model Hi DiffServer I read Xipeng Xiao and Lionel Ni, "Internet QoS: A Big Picture", IEEE Network Magazine, March/April, pp. 8-18, 1999. (you can get above paper in http://www.cse.msu.edu/~xiaoxipe/) Last of that paper, author shows the position of IntServ & DiffServ as transport layer. Well, I can't sure whether intserv is osi layer 4 or not. But I have thought DiffServ OSI 3 Layer. I mean, Network layer. Am I wrong? I can't find any reason about why diffserv is mapped to transport layer. Thanks a lot in advance, And with best regards... -- Young S.Choi _______________________________________________ diffserv mailing list diffserv@ietf.org http://www1.ietf.org/mailman/listinfo/diffserv Archive: http://www2.ietf.org/mail-archive/working-groups/diffserv/current/maillist.h tml --Boundary_(ID_nyCyyhZrBpvPSCuYvnLYpw) Content-type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable RE: [Diffserv] The position of IntServ/RSVP, DiffServ in the = Internet network model

My opinion is that it is closer to the = application layer vice the network layer.  In other words it does = not serve to determine where traffic is going...well, RSVP in a way = does; however, Diffserv does not explicitly perform this = action

Tina Iliff


--Boundary_(ID_nyCyyhZrBpvPSCuYvnLYpw)-- _______________________________________________ diffserv mailing list diffserv@ietf.org http://www1.ietf.org/mailman/listinfo/diffserv Archive: http://www2.ietf.org/mail-archive/working-groups/diffserv/current/maillist.html From diffserv-admin@ietf.org Wed Dec 6 11:48: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 SMTP id LAA18458 for ; Wed, 6 Dec 2000 11:48:38 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id LAA16461; Wed, 6 Dec 2000 11:23:26 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id LAA16431 for ; Wed, 6 Dec 2000 11:23:22 -0500 (EST) Received: from mrelay1.swift.com (begis50.swift.com [149.134.97.1]) by ietf.org (8.9.1a/8.9.1a) with SMTP id LAA12236 for ; Wed, 6 Dec 2000 11:23:20 -0500 (EST) From: firewall.alerts.generic@swift.com Received: from begis52 ([172.24.21.9]) by mrelay1.swift.com (Sun Internet Mail Server sims.3.5.1998.11.13.11.10) with SMTP id <0G5500G02MUP1F@mrelay1.swift.com> for diffserv@ietf.org; Wed, 6 Dec 2000 16:23:13 +0000 (GMT) Date: Wed, 06 Dec 2000 16:23:13 +0000 (GMT) Date-warning: Date header was inserted by mrelay1.swift.com To: Tina.Iliff@WCOM.Com, diffserv@ietf.org Message-id: <0G5500G03MUP1F@mrelay1.swift.com> Subject: [Diffserv] Cleaned virus file _MailData>-----Original Message-----
From:   Young S. Choi [mailto:guru0109@palgong.knu.ac.kr]
Sent:   Tuesday, December 05, 2000 7:39 PM
To:     diffserv@ietf.org
X-BeenThere: diffserv@ietf.org InterScan E-Mail VirusWall has cleaned all the viruses contained in the following attached file. The sender of the original file was . begin 666 _MailData>-----Original Message-----
end _______________________________________________ diffserv mailing list diffserv@ietf.org http://www1.ietf.org/mailman/listinfo/diffserv Archive: http://www2.ietf.org/mail-archive/working-groups/diffserv/current/maillist.html From diffserv-admin@ietf.org Wed Dec 6 11:49:52 2000 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with SMTP id LAA18769 for ; Wed, 6 Dec 2000 11:49:52 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id LAA16348; Wed, 6 Dec 2000 11:20:42 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id LAA16250 for ; Wed, 6 Dec 2000 11:20:35 -0500 (EST) Received: from slb-smtpout-01.boeing.com (slb-smtpout-01.boeing.com [12.13.237.21]) by ietf.org (8.9.1a/8.9.1a) with SMTP id LAA11491 for ; Wed, 6 Dec 2000 11:20:34 -0500 (EST) Received: from slb-av-02.boeing.com ([129.172.13.7]) by slb-smtpout-01.boeing.com (8.9.2/8.8.5-M2) with ESMTP id IAA09321 for ; Wed, 6 Dec 2000 08:20:33 -0800 (PST) Received: from slb-hub-01.boeing.com (localhost [127.0.0.1]) by slb-av-02.boeing.com (8.9.3/8.9.2) with ESMTP id IAA19255 for ; Wed, 6 Dec 2000 08:20:33 -0800 (PST) Received: from xch-phlbh-01.he.boeing.com by slb-hub-01.boeing.com with ESMTP; Wed, 6 Dec 2000 08:20:18 -0800 Received: by xch-phlbh-01.he.boeing.com with Internet Mail Service (5.5.2650.21) id ; Wed, 6 Dec 2000 11:20:17 -0500 Message-Id: <4102273CEB77D211869200805FE6F593018C5BC4@xch-phl-01.he.boeing.com> From: "Manfredi, Albert E" To: "'Iliff, Tina'" , diffserv@ietf.org Subject: RE: [Diffserv] The position of IntServ/RSVP,DiffServ in the Inte rnet network model Date: Wed, 6 Dec 2000 11:20:16 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C05FA0.6B1F3FB0" Sender: diffserv-admin@ietf.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_01C05FA0.6B1F3FB0 Content-Type: text/plain; charset="iso-8859-1" Instead, I would have put it closer to the Link Layer than to the Network Layer. Since, after all, what Diffserv wants to do is similar to what ATM does when it sits under IP, or MPLS for that matter, and is also similar to what VLANs might do when they sit under IP. If somehow the Transport Layer is used to determine which Diffserv code point should be used, this approach is similar to certain IP over ATM schemes, like AEREQUIPA (I believe it was), where the ATM switch uses some preconfigured rules to set up the ATM SVC with appropriate QoS for that IP packet stream. That would be Link Layer. Diffserv does operate between routers, though, and Diffserv could be used to affect the routing decision. So my take is that it must be operating at the Network Layer. (The WG chairs are about to bounce this to diffserv-interest.) Bert albert.e.manfredi@boeing.com -----Original Message----- From: Iliff, Tina [mailto:Tina.Iliff@WCOM.Com] Sent: Wednesday, December 06, 2000 10:39 AM To: 'Young S. Choi'; diffserv@ietf.org Subject: RE: [Diffserv] The position of IntServ/RSVP,DiffServ in the Inte rnet network model My opinion is that it is closer to the application layer vice the network layer. In other words it does not serve to determine where traffic is going...well, RSVP in a way does; however, Diffserv does not explicitly perform this action Tina Iliff BM__MailData-----Original Message----- From: Young S. Choi [ mailto:guru0109@palgong.knu.ac.kr ] Sent: Tuesday, December 05, 2000 7:39 PM To: diffserv@ietf.org Subject: [Diffserv] The position of IntServ/RSVP, DiffServ in the Internet network model Hi DiffServer I read Xipeng Xiao and Lionel Ni, "Internet QoS: A Big Picture", IEEE Network Magazine, March/April, pp. 8-18, 1999. (you can get above paper in http://www.cse.msu.edu/~xiaoxipe/ ) Last of that paper, author shows the position of IntServ & DiffServ as transport layer. Well, I can't sure whether intserv is osi layer 4 or not. But I have thought DiffServ OSI 3 Layer. I mean, Network layer. Am I wrong? I can't find any reason about why diffserv is mapped to transport layer. Thanks a lot in advance, And with best regards... -- Young S.Choi _______________________________________________ diffserv mailing list diffserv@ietf.org http://www1.ietf.org/mailman/listinfo/diffserv Archive: http://www2.ietf.org/mail-archive/working-groups/diffserv/current/maillist.h tml ------_=_NextPart_001_01C05FA0.6B1F3FB0 Content-Type: text/html; charset="iso-8859-1" RE: [Diffserv] The position of IntServ/RSVP, DiffServ in the Internet network model
Instead, I would have put it closer to the Link Layer than to the Network Layer. Since, after all, what Diffserv wants to do is similar to what ATM does when it sits under IP, or MPLS for that matter, and is also similar to what VLANs might do when they sit under IP.
 
If somehow the Transport Layer is used to determine which Diffserv code point should be used, this approach is similar to certain IP over ATM schemes, like AEREQUIPA (I believe it was), where the ATM switch uses some preconfigured rules to set up the ATM SVC with appropriate QoS for that IP packet stream. That would be Link Layer.
 
Diffserv does operate between routers, though, and Diffserv could be used to affect the routing decision. So my take is that it must be operating at the Network Layer.
 
(The WG chairs are about to bounce this to diffserv-interest.)
 
Bert
 
  
-----Original Message-----
From: Iliff, Tina [mailto:Tina.Iliff@WCOM.Com]
Sent: Wednesday, December 06, 2000 10:39 AM
To: 'Young S. Choi'; diffserv@ietf.org
Subject: RE: [Diffserv] The position of IntServ/RSVP,DiffServ in the Inte rnet network model

My opinion is that it is closer to the application layer vice the network layer.  In other words it does not serve to determine where traffic is going...well, RSVP in a way does; however, Diffserv does not explicitly perform this action

Tina Iliff


------_=_NextPart_001_01C05FA0.6B1F3FB0-- _______________________________________________ diffserv mailing list diffserv@ietf.org http://www1.ietf.org/mailman/listinfo/diffserv Archive: http://www2.ietf.org/mail-archive/working-groups/diffserv/current/maillist.html From diffserv-admin@ietf.org Wed Dec 6 11:52:08 2000 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with SMTP id LAA19493 for ; Wed, 6 Dec 2000 11:52:07 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id LAA16496; Wed, 6 Dec 2000 11:23:34 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id LAA16465 for ; Wed, 6 Dec 2000 11:23:27 -0500 (EST) Received: from mrelay1.swift.com (begis50.swift.com [149.134.97.1]) by ietf.org (8.9.1a/8.9.1a) with SMTP id LAA12267 for ; Wed, 6 Dec 2000 11:23:26 -0500 (EST) From: firewall.alerts.generic@swift.com Received: from begis52 ([172.24.21.9]) by mrelay1.swift.com (Sun Internet Mail Server sims.3.5.1998.11.13.11.10) with SMTP id <0G5500G02MUW1N@mrelay1.swift.com> for diffserv@ietf.org; Wed, 6 Dec 2000 16:23:21 +0000 (GMT) Date: Wed, 06 Dec 2000 17:14:57 +0100 (W. Europe Standard Time) To: Tina.Iliff@WCOM.Com, diffserv@ietf.org Message-id: <0G5500G03MUX1N@mrelay1.swift.com> Subject: [Diffserv] InterScan NT Alert Sender: diffserv-admin@ietf.org Errors-To: diffserv-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Diffserv Discussion List X-BeenThere: diffserv@ietf.org Receiver, InterScan has detected virus(es) in the e-mail attachment. Date: Wed, 06 Dec 2000 17:14:57 +0100 (W. Europe Standard Time) Method: Mail From: To: File: _MailData>-----Original Message-----
From:   Young S. Choi [mailto:guru0109@palgong.knu.ac.kr]
Sent:   Tuesday, December 05, 2000 7:39 PM
To:     diffserv@ietf.org
; Wed, 6 Dec 2000 12:05:06 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id LAA16892; Wed, 6 Dec 2000 11:38:13 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id LAA16864 for ; Wed, 6 Dec 2000 11:38:07 -0500 (EST) 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 SMTP id LAA16062 for ; Wed, 6 Dec 2000 11:38:06 -0500 (EST) 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 LAA16706; Wed, 6 Dec 2000 11:39:31 -0600 Received: from d04nm200.raleigh.ibm.com (d04nm200.raleigh.ibm.com [9.67.228.37]) by southrelay02.raleigh.ibm.com (8.8.8m3/NCO v4.95) with ESMTP id LAA95952; Wed, 6 Dec 2000 11:37:36 -0500 Importance: Normal Subject: Re: [Diffserv] Model draft - sharing elements on multiple interfaces To: Keith McCloghrie Cc: kzm@cisco.com (Keith McCloghrie), andrew@allegronetworks.com (Andrew Smith), diffserv@ietf.org (diffserv) X-Mailer: Lotus Notes Release 5.0.3 (Intl) 21 March 2000 Message-ID: From: "Robert Moore" Date: Wed, 6 Dec 2000 11:42:04 -0500 X-MIMETrack: Serialize by Router on D04NM200/04/M/IBM(Release 5.0.3 (Intl)|21 March 2000) at 12/06/2000 11:38:03 AM 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 Keith, If I'm understanding you correctly, then I think I agree with you. We can allow the sharing of conditioning elements in the ingress case, but continue to rule it out for egress. This covers a case like a single meter that processes traffic aggregated from several ingress interfaces, which seems like something we want to allow. But it doesn't complicate the MIB in the egress case. If we allow sharing of conditioning elements for ingress interfaces, I think there are two cases that need to be mentioned in the MIB: - Two DataPathStart pointers pointing to the same element. If we leave it at that, we have no answer to the question "Which data path is the element *really* on?" But I think this is OK -- we can say that it's equally on both data paths. - A "next" pointer in a conditioning element pointing to a next conditioning element on a different data path. The MIB would also have to say clearly that these two options are *not* allowed for egress data paths. For Andrew's picture, I think it would be fine to combine the new version for the ingress side with the old version for the egress side. Does this sound good to everybody? Regards, Bob Bob Moore IBM Networking Software +1-919-254-4436 remoore@us.ibm.com Keith McCloghrie @ietf.org on 12/05/2000 05:19:33 PM Sent by: diffserv-admin@ietf.org To: Robert Moore/Raleigh/IBM@IBMUS cc: kzm@cisco.com (Keith McCloghrie), andrew@allegronetworks.com (Andrew Smith), diffserv@ietf.org (diffserv) Subject: Re: [Diffserv] Model draft - sharing elements on multiple interfaces Bob, I was arguing against additional complexity, which was what I believed would ensue from Andrew's proposed change from: > > -> I -> core -> E -> > > > > The proposal would be to modify this to something like: > > > > -> I -+-> I -> core -> E -+-> E -> > > | | > > -> I -+ +-> E -> I think it would be possible to allow merging on ingress just by removing the restriction on two data paths merging, which is stated in this ASN.1 comment (I think that's the only place it's specified): -- The use of next pointer to point to diffserv functional datapath -- element of a different datapath is not allowed I agree it's harder for egress which requries splitting, for which I think the current MIB structure is insufficient, and my concern is that a MIB structure which would allow it is going to be more complex. Keith. > Keith, > > I'm not sure what you're arguing for here. At least > on the ingress side, sharing an element (say a > Classifier) between two ingress interfaces amounts > to having the dataPathStart pointers for two entries > in the dataPathTable point to the same entry in the > diffServClassifier table. Are you saying that the MIB > currently rules this out? If so, I've missed it. Or > are you saying that while the MIB doesn't currently > rule it out, it should be changed so that it does? > > It's a little harder to describe for egress, but I > think the idea would be that two Data Paths start out > together, but then somehow diverge before they're done. > I'm not sure exactly how to express this in terms of > the Next pointers, but the same question I asked you > above applies here as well: do you think that the MIB > currently does outlaw this setup, or do you think that > it should (but doesn't now)? > > Thanks. > > Regards, > Bob > > Bob Moore > IBM Networking Software > +1-919-254-4436 > remoore@us.ibm.com > > > > Keith McCloghrie on 12/05/2000 03:54:50 PM > > To: andrew@allegronetworks.com (Andrew Smith) > cc: diffserv@ietf.org (diffserv), Robert Moore/Raleigh/IBM@IBMUS > Subject: Re: [Diffserv] Model draft - sharing elements on multiple > interfaces > > > > I think the DiffServ MIB is only just use-able at the moment due to > its surfeit of complexity, and I suggest that incorporating the below > into the model and thus reflecting it into the MIB will push the MIB > over the "cliff" to become of no use to anybody. > > Keith. > > > This is a proposal for a solution to the second issue in my earlier > message > > Ref: http://www.ietf.org/internet-drafts/draft-ietf-diffserv-model-05.txt > > > > 2. Sharing of elements amongst multiple interfaces. > > > > Bob Moore has made a good point: right now the model describes everything > that > > happens to a packet as it arrives on ingress to *an* interface, then it > goes > > through a routing core, then it describes what happens on egress from > *an* > > interface. The problem is that there are very valid scenarios (and > > implementation architectures too, although that's not really our problem > here) > > where you want traffic streams from multiple ingress interfaces to > receive > > shared processing before they get to the switch fabric. Ditto for a > stream on > > egress to receive some diffserv processing before being split out to its > final > > egress interface. This is a fairly fundamental ommission and I don't > think it > > can be tackled by hand-waving. So we should choose whether to support it > > explicitly or not. > > > > To support it, I think we need a modified top-level diagram that shows > that you > > may repeat the routing core and subsequent "interface" blocks multiple > times. > > The current figure 2 implies that you may have only one "ingress > interface > > block" and one "egress interface block" per interface (the blocks are the > dotted > > boxes in the figure). I believe we would need an additional "routing > core" of > > some sort in between the first per-interface block and any subsequent > > shared-multi-interface block in order to express the interconnections > (similar > > for egress). Do we then need arbitrary concatenations of such blocks or > does 2 > > on ingress and 2 on egress of each suffice? > > > > I'm too lazy to draw the real picture right now (a real ASCII-art > challenge to > > do it in only 72 columns) but it's something like this: right now we have > one > > direction, the top half, of figure 2 as: > > > > -> I -> core -> E -> > > > > The proposal would be to modify this to something like: > > > > -> I -+-> I -> core -> E -+-> E -> > > | | > > -> I -+ +-> E -> > > > > Where "I" represents an Ingress block and "E" represents an Egress block. > And > > you could represent the merge/split functions as additional routing cores > > (albeit simplified ones, still out of scope for this model: maybe this > would be > > a use for those under-utilised Multiplexor and Demultiplexor elements but > they'd > > have to be redefined so that their scope could span multiple interfaces - > right > > now all elements are implicitly instantiated per-interface in this > model). > > > > [I don't know if this solves Bob's issue or not - hopefully he'll let us > know.] > > > > Andrew Smith > > (editor of this draft) > > > > > > _______________________________________________ > > diffserv mailing list > > diffserv@ietf.org > > http://www1.ietf.org/mailman/listinfo/diffserv > > Archive: > http://www2.ietf.org/mail-archive/working-groups/diffserv/current/maillist.html > > > > > > > > > _______________________________________________ diffserv mailing list diffserv@ietf.org http://www1.ietf.org/mailman/listinfo/diffserv Archive: http://www2.ietf.org/mail-archive/working-groups/diffserv/current/maillist.html _______________________________________________ diffserv mailing list diffserv@ietf.org http://www1.ietf.org/mailman/listinfo/diffserv Archive: http://www2.ietf.org/mail-archive/working-groups/diffserv/current/maillist.html From diffserv-admin@ietf.org Wed Dec 6 12:13: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 SMTP id MAA25233 for ; Wed, 6 Dec 2000 12:13:38 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id LAA16959; Wed, 6 Dec 2000 11:39:51 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id LAA16928 for ; Wed, 6 Dec 2000 11:39:46 -0500 (EST) Received: from pmesmtp01.wcom.com (pmesmtp01.wcom.com [199.249.20.1]) by ietf.org (8.9.1a/8.9.1a) with SMTP id LAA16455 for ; Wed, 6 Dec 2000 11:39:45 -0500 (EST) Received: from CONVERSION-DAEMON by firewall.mcit.com (PMDF V5.2-32 #42256) id <0G5500M01NIUYB@firewall.mcit.com> for diffserv@ietf.org; Wed, 6 Dec 2000 16:37:42 +0000 (GMT) Received: from pmismtp01.wcomnet.com ([166.38.62.36]) by firewall.mcit.com (PMDF V5.2-32 #42256) with ESMTP id <0G5500K6HNIUI2@firewall.mcit.com> for diffserv@ietf.org; Wed, 06 Dec 2000 16:37:42 +0000 (GMT) Received: from CONVERSION-DAEMON by pmismtp01.wcomnet.com (PMDF V5.2-33 #42258) id <0G5500B01NIUE2@pmismtp01.wcomnet.com> for diffserv@ietf.org; Wed, 06 Dec 2000 16:37:42 +0000 (GMT) Received: from pmismtp01.wcomnet.com by pmismtp01.wcomnet.com (PMDF V5.2-33 #42258) with SMTP id <0G5500B01NID6C@pmismtp01.wcomnet.com> for diffserv@ietf.org; Wed, 06 Dec 2000 16:37:41 +0000 (GMT) Received: from omzexch006.mcit.com ([166.37.194.37]) by pmismtp01.wcomnet.com (PMDF V5.2-33 #42258) with ESMTP id <0G5500A2GNI6V6@pmismtp01.wcomnet.com> for diffserv@ietf.org; Wed, 06 Dec 2000 16:37:18 +0000 (GMT) Received: by omzexch006 with Internet Mail Service (5.5.2651.58) id ; Wed, 06 Dec 2000 16:37:18 +0000 Content-return: allowed Date: Wed, 06 Dec 2000 16:37:16 +0000 From: "Iliff, Tina" To: "'diffserv@ietf.org'" Message-id: <492EB4A3F68CD411ABE800508B69362E14B3C2@RIPEXCH002.wcomnet.com> MIME-version: 1.0 X-Mailer: Internet Mail Service (5.5.2651.58) Content-type: multipart/alternative; boundary="Boundary_(ID_+MMfEKOiarxDP0IUimpoLA)" Subject: [Diffserv] diffsev-pib-02: qosQSchdParam Sender: diffserv-admin@ietf.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. --Boundary_(ID_+MMfEKOiarxDP0IUimpoLA) Content-type: text/plain; charset=ISO-8859-1 All, I have a concern regarding the structure of the qosQ table. It contains an attribute named SchdParam which provides the parameters used by the scheduler element for this particular queue. My concern is that there is also a SchdParam attribute in the qosScheduler table. It makes more sense to leave the parameter in the qosScheduler table and not in the qosQ table. It seems it is a duplication of information. Tina Iliff --Boundary_(ID_+MMfEKOiarxDP0IUimpoLA) Content-type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable diffsev-pib-02: qosQSchdParam

All,

I have a concern regarding the = structure of the qosQ table.  It contains an attribute named = SchdParam which provides the parameters used by the scheduler element = for this particular queue.  My concern is that there is also a = SchdParam attribute in the qosScheduler table.  It makes more = sense to leave the parameter in the qosScheduler table and not in the = qosQ table.  It seems it is a duplication of = information.

Tina Iliff

--Boundary_(ID_+MMfEKOiarxDP0IUimpoLA)-- _______________________________________________ diffserv mailing list diffserv@ietf.org http://www1.ietf.org/mailman/listinfo/diffserv Archive: http://www2.ietf.org/mail-archive/working-groups/diffserv/current/maillist.html From diffserv-admin@ietf.org Wed Dec 6 12:19:48 2000 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with SMTP id MAA26655 for ; Wed, 6 Dec 2000 12:19:48 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id LAA17217; Wed, 6 Dec 2000 11:49:35 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id LAA17185 for ; Wed, 6 Dec 2000 11:49:31 -0500 (EST) Received: from c2.ciena.com ([63.118.32.25]) by ietf.org (8.9.1a/8.9.1a) with SMTP id LAA18692 for ; Wed, 6 Dec 2000 11:49:30 -0500 (EST) From: CIENA-Antivirus@ciena.com Received: by c2.ciena.com (8.8.8+Sun/SMI-SVR4-8.0) id LAA13967; Wed, 6 Dec 2000 11:49:00 -0500 (EST) Message-Id: <200012061649.LAA13967@c2.ciena.com> Received: from unknown(10.4.252.1) by c2.ciena.com via smap (V2.0) id xma013858; Wed, 6 Dec 00 11:48:37 -0500 Date: Wed, 06 Dec 2000 11:47:49 -0500 (Eastern Standard Time) To: , Subject: [Diffserv] InterScan NT Alert Sender: diffserv-admin@ietf.org Errors-To: diffserv-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Diffserv Discussion List X-BeenThere: diffserv@ietf.org Receiver, CIENA's mail security server has detected virus(es) in the e-mail attachment. Date: Wed, 06 Dec 2000 11:47:49 -0500 (Eastern Standard Time) Method: Mail From: To: File: _MailData>-----Original Message-----
From:   Young S. Choi [mailto:guru0109@palgong.knu.ac.kr]
Sent:   Tuesday, December 05, 2000 7:39 PM
To:     diffserv@ietf.org
; Wed, 6 Dec 2000 12:24:18 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id LAA17332; Wed, 6 Dec 2000 11:52:23 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id LAA17290 for ; Wed, 6 Dec 2000 11:52:19 -0500 (EST) Received: from c2.ciena.com ([63.118.32.25]) by ietf.org (8.9.1a/8.9.1a) with SMTP id LAA19555 for ; Wed, 6 Dec 2000 11:52:17 -0500 (EST) From: CIENA-Antivirus@ciena.com Received: by c2.ciena.com (8.8.8+Sun/SMI-SVR4-8.0) id LAA14659; Wed, 6 Dec 2000 11:51:47 -0500 (EST) Message-Id: <200012061651.LAA14659@c2.ciena.com> Received: from unknown(10.4.252.1) by c2.ciena.com via smap (V2.0) id xma014514; Wed, 6 Dec 00 11:51:08 -0500 Date: Wed, 06 Dec 2000 11:50:22 -0500 (Eastern Standard Time) To: , Subject: [Diffserv] InterScan NT Alert Sender: diffserv-admin@ietf.org Errors-To: diffserv-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Diffserv Discussion List X-BeenThere: diffserv@ietf.org Receiver, CIENA's mail security server has detected virus(es) in the e-mail attachment. Date: Wed, 06 Dec 2000 11:50:22 -0500 (Eastern Standard Time) Method: Mail From: To: File: _MailData>-----Original Message-----
From:   Young S. Choi [mailto:guru0109@palgong.knu.ac.kr]
Sent:   Tuesday, December 05, 2000 7:39 PM
To:     diffserv@ietf.org
; Wed, 6 Dec 2000 12:37:39 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id MAA17893; Wed, 6 Dec 2000 12:07:46 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id MAA17862 for ; Wed, 6 Dec 2000 12:07:42 -0500 (EST) Received: from DF-INET-1.dogfoodinternet.com (df-inet1.exchange.microsoft.com [131.107.8.8]) by ietf.org (8.9.1a/8.9.1a) with SMTP id MAA23980 for ; Wed, 6 Dec 2000 12:07:40 -0500 (EST) Received: from df-virus2.platinum.corp.microsoft.com ([172.30.236.33]) by DF-INET-1.dogfoodinternet.com with Microsoft SMTPSVC(5.0.2195.1600); Wed, 6 Dec 2000 08:42:59 -0800 Received: from 172.30.236.11 by df-virus2.platinum.corp.microsoft.com (InterScan E-Mail VirusWall NT); Wed, 06 Dec 2000 08:43:40 -0800 (Pacific Standard Time) Received: from DF-SCOOBY.platinum.corp.microsoft.com ([172.30.236.125]) by yuri.dns.microsoft.com with Microsoft SMTPSVC(5.0.2195.1600); Wed, 6 Dec 2000 08:43:40 -0800 content-class: urn:content-classes:message Subject: RE: [Diffserv] The position of IntServ/RSVP,DiffServ in the Inte rnet network model MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C05FA3.AF156C7F" Date: Wed, 6 Dec 2000 08:43:38 -0800 X-MimeOLE: Produced By Microsoft Exchange V6.0.4599.0 Message-ID: Thread-Topic: [Diffserv] The position of IntServ/RSVP,DiffServ in the Inte rnet network model Thread-Index: AcBfoeg5Jwy7s3yYQeicu/2i2PzVhgAAaEZA From: "Yoram Bernet" To: "Manfredi, Albert E" , "Iliff, Tina" , X-OriginalArrivalTime: 06 Dec 2000 16:43:40.0688 (UTC) FILETIME=[B0340100:01C05FA3] Sender: diffserv-admin@ietf.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_01C05FA3.AF156C7F Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Check out RFC 2998. It talks about using RSVP to gain admission to the diffserv 'link layer'. -----Original Message----- From: Manfredi, Albert E [mailto:Albert.Manfredi@PHL.Boeing.com] Sent: Wednesday, December 06, 2000 8:20 AM To: Iliff, Tina; diffserv@ietf.org Subject: RE: [Diffserv] The position of IntServ/RSVP,DiffServ in the Inte rnet network model Instead, I would have put it closer to the Link Layer than to the Network Layer. Since, after all, what Diffserv wants to do is similar to what ATM does when it sits under IP, or MPLS for that matter, and is also similar to what VLANs might do when they sit under IP. =20 If somehow the Transport Layer is used to determine which Diffserv code point should be used, this approach is similar to certain IP over ATM schemes, like AEREQUIPA (I believe it was), where the ATM switch uses some preconfigured rules to set up the ATM SVC with appropriate QoS for that IP packet stream. That would be Link Layer. =20 Diffserv does operate between routers, though, and Diffserv could be used to affect the routing decision. So my take is that it must be operating at the Network Layer. =20 (The WG chairs are about to bounce this to diffserv-interest.) =20 Bert albert.e.manfredi@boeing.com =20 =20 -----Original Message----- From: Iliff, Tina [mailto:Tina.Iliff@WCOM.Com] Sent: Wednesday, December 06, 2000 10:39 AM To: 'Young S. Choi'; diffserv@ietf.org Subject: RE: [Diffserv] The position of IntServ/RSVP,DiffServ in the Inte rnet network model My opinion is that it is closer to the application layer vice the network layer. In other words it does not serve to determine where traffic is going...well, RSVP in a way does; however, Diffserv does not explicitly perform this action Tina Iliff=20 -----Original Message-----=20 From: Young S. Choi [ mailto:guru0109@palgong.knu.ac.kr]=20 Sent: Tuesday, December 05, 2000 7:39 PM=20 To: diffserv@ietf.org=20 Subject: [Diffserv] The position of IntServ/RSVP, DiffServ in the Internet network model=20 Hi DiffServer=20 I read=20 Xipeng Xiao and Lionel Ni, "Internet QoS: A Big Picture", IEEE Network=20 Magazine, March/April, pp. 8-18, 1999.=20 (you can get above paper in http://www.cse.msu.edu/~xiaoxipe/)=20 Last of that paper, author shows the position of IntServ & DiffServ as=20 transport layer.=20 Well, I can't sure whether intserv is osi layer 4 or not.=20 But I have thought DiffServ OSI 3 Layer. I mean, Network layer. Am I wrong?=20 I can't find any reason about why diffserv is mapped to transport layer. Thanks a lot in advance,=20 And with best regards...=20 --=20 Young S.Choi=20 _______________________________________________=20 diffserv mailing list=20 diffserv@ietf.org=20 http://www1.ietf.org/mailman/listinfo/diffserv=20 Archive: http://www2.ietf.org/mail-archive/working-groups/diffserv/current/mailli st.html=20 ------_=_NextPart_001_01C05FA3.AF156C7F Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable RE: [Diffserv] The position of IntServ/RSVP, DiffServ in the = Internet network model
Check=20 out RFC 2998. It talks about using RSVP to gain admission to the = diffserv 'link=20 layer'.
-----Original Message-----
From: Manfredi, Albert E = [mailto:Albert.Manfredi@PHL.Boeing.com]
Sent: Wednesday, = December=20 06, 2000 8:20 AM
To: Iliff, Tina;=20 diffserv@ietf.org
Subject: RE: [Diffserv] The position of=20 IntServ/RSVP,DiffServ in the Inte rnet network = model

Instead, I = would have=20 put it closer to the Link Layer than to the Network Layer. Since, = after all,=20 what Diffserv wants to do is similar to what ATM does when it sits = under IP,=20 or MPLS for that matter, and is also similar to what VLANs might do = when they=20 sit under IP.
 
If somehow = the=20 Transport Layer is used to determine which Diffserv code point should = be used,=20 this approach is similar to certain IP over ATM schemes, like = AEREQUIPA (I=20 believe it was), where the ATM switch uses some preconfigured rules to = set up=20 the ATM SVC with appropriate QoS for that IP packet stream. That would = be Link=20 Layer.
 
Diffserv = does operate=20 between routers, though, and Diffserv could be used to affect the = routing=20 decision. So my take is that it must be operating at the Network=20 Layer.
 
(The WG = chairs are=20 about to bounce this to diffserv-interest.)
 
Bert
albert.e.manfredi@boeing.com=
 
  
-----Original Message-----
From: Iliff, Tina=20 [mailto:Tina.Iliff@WCOM.Com]
Sent: Wednesday, December 06, = 2000=20 10:39 AM
To: 'Young S. Choi'; = diffserv@ietf.org
Subject:=20 RE: [Diffserv] The position of IntServ/RSVP,DiffServ in the Inte = rnet=20 network model

My opinion is that it is closer to = the=20 application layer vice the network layer.  In other words it = does not=20 serve to determine where traffic is going...well, RSVP in a way = does;=20 however, Diffserv does not explicitly perform this action

Tina Iliff =


    -----Original=20 Message-----
    From:  =20 Young S. Choi [mailto:guru0109@palgong.knu.ac= .kr]=20
    Sent:   = Tuesday, December 05, 2000 7:39 PM =
    To:     diffserv@ietf.org
    Subject:        = [Diffserv] The position of IntServ/RSVP, = DiffServ in the=20 Internet network model

    Hi DiffServer

    I read

    Xipeng Xiao and  Lionel Ni, = "Internet=20 QoS: A Big Picture", IEEE Network
    Magazine, March/April, pp. 8-18, 1999.

    (you can get above paper in http://www.cse.msu.edu/~xiaoxipe/)

    Last of that paper, author shows = the=20 position of IntServ & DiffServ as
    transport layer.

    Well, I can't sure whether = intserv is osi=20 layer 4 or not.

    But I have thought DiffServ OSI = 3 Layer. I=20 mean, Network layer. Am I wrong?
    I=20 can't find any reason about why diffserv is mapped to transport=20 layer.

    Thanks a lot in advance, =
    And with best regards...

    --
    Young S.Choi


    _______________________________________________ =
    diffserv mailing list
    diffserv@ietf.org
    http://www1.ietf.org/mailman/listinfo/diffserv= =20
    Archive: http://www2.ietf.org/mail-archive/working-groups/diffserv= /current/maillist.html=20

------_=_NextPart_001_01C05FA3.AF156C7F-- _______________________________________________ diffserv mailing list diffserv@ietf.org http://www1.ietf.org/mailman/listinfo/diffserv Archive: http://www2.ietf.org/mail-archive/working-groups/diffserv/current/maillist.html From diffserv-admin@ietf.org Wed Dec 6 14:56: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 SMTP id OAA29251 for ; Wed, 6 Dec 2000 14:56:05 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id OAA19816; Wed, 6 Dec 2000 14:24:49 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id OAA19789 for ; Wed, 6 Dec 2000 14:24:45 -0500 (EST) Received: from mta6.snfc21.pbi.net (mta6.snfc21.pbi.net [206.13.28.240]) by ietf.org (8.9.1a/8.9.1a) with SMTP id OAA23545 for ; Wed, 6 Dec 2000 14:24:44 -0500 (EST) Received: from allegronetworks.com ([207.214.220.93]) by mta6.snfc21.pbi.net (Sun Internet Mail Server sims.3.5.2000.01.05.12.18.p9) with ESMTP id <0G55000MOSQ4OR@mta6.snfc21.pbi.net> for diffserv@ietf.org; Wed, 6 Dec 2000 10:30:07 -0800 (PST) Date: Wed, 06 Dec 2000 10:38:08 -0800 From: Andrew Smith Subject: Re: [Diffserv] Model draft - sharing elements on multiple interfaces To: Robert Moore Cc: diffserv Message-id: <3A2E8790.40401@allegronetworks.com> Organization: Allegro Networks MIME-version: 1.0 Content-type: text/plain; charset=us-ascii; format=flowed Content-transfer-encoding: 7bit User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; m18) Gecko/20001108 Netscape6/6.0 X-Accept-Language: en References: Content-Transfer-Encoding: 7bit Sender: diffserv-admin@ietf.org Errors-To: diffserv-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Diffserv Discussion List X-BeenThere: diffserv@ietf.org Content-Transfer-Encoding: 7bit Bob, I think you're trying to craft a compromise with Keith here but what you propose is inconsistent. [Note that I didn't mention the MIB in my message: the MIB can implement a subset of the model if it so chooses, so long as it is not inconsistent with the model, but that's not the point I raised - by all means discuss the impact of this issue on the MIB in a separate thread but don't let that confuse this discussion of the model]. The point in question is whether "shared-between-multiple-interfaces" elements are both (a) useful for implementing specific services and (b) likely to be implemented by more than one vendor and (c) without this change, does it make it impossible/unlikely that the model can be used to represent a significant set of devices? I believe that, for (a), the model needs to be symmetric: if such a service is useful for "in" then it is also for "out" e.g. metering on a collection of interfaces representing one customer is just as useful in both directions. As regards (b), I'd like to hear some more opinions: so far the exit poll (3 opinions) seems to read: In? Out? Y/N Y/N 2/1 1/2 (if that notation makes sense). And for (c) I'm not sure we have any data points. Andrew Robert Moore wrote: > Keith, > > If I'm understanding you correctly, then I think I agree > with you. We can allow the sharing of conditioning > elements in the ingress case, but continue to rule it out > for egress. This covers a case like a single meter that > processes traffic aggregated from several ingress > interfaces, which seems like something we want to allow. > But it doesn't complicate the MIB in the egress case. > > If we allow sharing of conditioning elements for ingress > interfaces, I think there are two cases that need to be > mentioned in the MIB: > > - Two DataPathStart pointers pointing to the same > element. If we leave it at that, we have no answer > to the question "Which data path is the element > *really* on?" But I think this is OK -- we can > say that it's equally on both data paths. > - A "next" pointer in a conditioning element pointing > to a next conditioning element on a different > data path. > > The MIB would also have to say clearly that these two > options are *not* allowed for egress data paths. > > For Andrew's picture, I think it would be fine to > combine the new version for the ingress side with the > old version for the egress side. > > Does this sound good to everybody? > > Regards, > Bob > > Bob Moore > IBM Networking Software > +1-919-254-4436 > remoore@us.ibm.com > > > > Keith McCloghrie @ietf.org on 12/05/2000 05:19:33 PM > > Sent by: diffserv-admin@ietf.org > > > To: Robert Moore/Raleigh/IBM@IBMUS > cc: kzm@cisco.com (Keith McCloghrie), andrew@allegronetworks.com (Andrew > Smith), diffserv@ietf.org (diffserv) > Subject: Re: [Diffserv] Model draft - sharing elements on multiple > interfaces > > > > Bob, > > I was arguing against additional complexity, which was what I believed > would ensue from Andrew's proposed change from: > > >>> -> I -> core -> E -> >>> >>> The proposal would be to modify this to something like: >>> >>> -> I -+-> I -> core -> E -+-> E -> >>> | | >>> -> I -+ +-> E -> >> > > I think it would be possible to allow merging on ingress just by > removing the restriction on two data paths merging, which is stated > in this ASN.1 comment (I think that's the only place it's specified): > > -- The use of next pointer to point to diffserv functional datapath > -- element of a different datapath is not allowed > > I agree it's harder for egress which requries splitting, for which > I think the current MIB structure is insufficient, and my concern is > that a MIB structure which would allow it is going to be more complex. > > Keith. > > > >> Keith, >> >> I'm not sure what you're arguing for here. At least >> on the ingress side, sharing an element (say a >> Classifier) between two ingress interfaces amounts >> to having the dataPathStart pointers for two entries >> in the dataPathTable point to the same entry in the >> diffServClassifier table. Are you saying that the MIB >> currently rules this out? If so, I've missed it. Or >> are you saying that while the MIB doesn't currently >> rule it out, it should be changed so that it does? >> >> It's a little harder to describe for egress, but I >> think the idea would be that two Data Paths start out >> together, but then somehow diverge before they're done. >> I'm not sure exactly how to express this in terms of >> the Next pointers, but the same question I asked you >> above applies here as well: do you think that the MIB >> currently does outlaw this setup, or do you think that >> it should (but doesn't now)? >> >> Thanks. >> >> Regards, >> Bob >> >> Bob Moore >> IBM Networking Software >> +1-919-254-4436 >> remoore@us.ibm.com >> >> >> >> Keith McCloghrie on 12/05/2000 03:54:50 PM >> >> To: andrew@allegronetworks.com (Andrew Smith) >> cc: diffserv@ietf.org (diffserv), Robert Moore/Raleigh/IBM@IBMUS >> Subject: Re: [Diffserv] Model draft - sharing elements on multiple >> interfaces >> >> >> >> I think the DiffServ MIB is only just use-able at the moment due to >> its surfeit of complexity, and I suggest that incorporating the below >> into the model and thus reflecting it into the MIB will push the MIB >> over the "cliff" to become of no use to anybody. >> >> Keith. >> >> >>> This is a proposal for a solution to the second issue in my earlier >> >> message >> >>> Ref: >> > http://www.ietf.org/internet-drafts/draft-ietf-diffserv-model-05.txt > >>> 2. Sharing of elements amongst multiple interfaces. >>> >>> Bob Moore has made a good point: right now the model describes >> > everything > >> that >> >>> happens to a packet as it arrives on ingress to *an* interface, then it >> >> goes >> >>> through a routing core, then it describes what happens on egress from >> >> *an* >> >>> interface. The problem is that there are very valid scenarios (and >>> implementation architectures too, although that's not really our >> > problem > >> here) >> >>> where you want traffic streams from multiple ingress interfaces to >> >> receive >> >>> shared processing before they get to the switch fabric. Ditto for a >> >> stream on >> >>> egress to receive some diffserv processing before being split out to >> > its > >> final >> >>> egress interface. This is a fairly fundamental ommission and I don't >> >> think it >> >>> can be tackled by hand-waving. So we should choose whether to support >> > it > >>> explicitly or not. >>> >>> To support it, I think we need a modified top-level diagram that shows >> >> that you >> >>> may repeat the routing core and subsequent "interface" blocks multiple >> >> times. >> >>> The current figure 2 implies that you may have only one "ingress >> >> interface >> >>> block" and one "egress interface block" per interface (the blocks are >> > the > >> dotted >> >>> boxes in the figure). I believe we would need an additional "routing >> >> core" of >> >>> some sort in between the first per-interface block and any subsequent >>> shared-multi-interface block in order to express the interconnections >> >> (similar >> >>> for egress). Do we then need arbitrary concatenations of such blocks or >> >> does 2 >> >>> on ingress and 2 on egress of each suffice? >>> >>> I'm too lazy to draw the real picture right now (a real ASCII-art >> >> challenge to >> >>> do it in only 72 columns) but it's something like this: right now we >> > have > >> one >> >>> direction, the top half, of figure 2 as: >>> >>> -> I -> core -> E -> >>> >>> The proposal would be to modify this to something like: >>> >>> -> I -+-> I -> core -> E -+-> E -> >>> | | >>> -> I -+ +-> E -> >>> >>> Where "I" represents an Ingress block and "E" represents an Egress >> > block. > >> And >> >>> you could represent the merge/split functions as additional routing >> > cores > >>> (albeit simplified ones, still out of scope for this model: maybe this >> >> would be >> >>> a use for those under-utilised Multiplexor and Demultiplexor elements >> > but > >> they'd >> >>> have to be redefined so that their scope could span multiple interfaces >> > - > >> right >> >>> now all elements are implicitly instantiated per-interface in this >> >> model). >> >>> [I don't know if this solves Bob's issue or not - hopefully he'll let >> > us > >> know.] >> >>> Andrew Smith >>> (editor of this draft) >>> >>> >>> _______________________________________________ >>> diffserv mailing list >>> diffserv@ietf.org >>> http://www1.ietf.org/mailman/listinfo/diffserv >>> Archive: >> > http://www2.ietf.org/mail-archive/working-groups/diffserv/current/maillist.html > > >>> >> >> >> > > > _______________________________________________ > diffserv mailing list > diffserv@ietf.org > http://www1.ietf.org/mailman/listinfo/diffserv > Archive: > http://www2.ietf.org/mail-archive/working-groups/diffserv/current/maillist.html > > > > > _______________________________________________ > diffserv mailing list > diffserv@ietf.org > http://www1.ietf.org/mailman/listinfo/diffserv > Archive: http://www2.ietf.org/mail-archive/working-groups/diffserv/current/maillist.html _______________________________________________ diffserv mailing list diffserv@ietf.org http://www1.ietf.org/mailman/listinfo/diffserv Archive: http://www2.ietf.org/mail-archive/working-groups/diffserv/current/maillist.html From diffserv-admin@ietf.org Wed Dec 6 15:10: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 SMTP id PAA03245 for ; Wed, 6 Dec 2000 15:10:46 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id OAA20217; Wed, 6 Dec 2000 14:38:58 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id OAA20110 for ; Wed, 6 Dec 2000 14:38:48 -0500 (EST) Received: from e22.nc.us.ibm.com (e22.nc.us.ibm.com [32.97.136.228]) by ietf.org (8.9.1a/8.9.1a) with SMTP id OAA25953 for ; Wed, 6 Dec 2000 14:38:47 -0500 (EST) Received: from southrelay02.raleigh.ibm.com (southrelay02.raleigh.ibm.com [9.37.3.209]) by e22.nc.us.ibm.com (8.9.3/8.9.3) with ESMTP id OAA18990; Wed, 6 Dec 2000 14:35:30 -0600 Received: from d04nm200.raleigh.ibm.com (d04nm200.raleigh.ibm.com [9.67.228.37]) by southrelay02.raleigh.ibm.com (8.8.8m3/NCO v4.95) with ESMTP id OAA35376; Wed, 6 Dec 2000 14:38:17 -0500 Importance: Normal Subject: Re: [Diffserv] Model draft - sharing elements on multiple interfaces To: Andrew Smith Cc: diffserv X-Mailer: Lotus Notes Release 5.0.3 (Intl) 21 March 2000 Message-ID: From: "Robert Moore" Date: Wed, 6 Dec 2000 14:42:46 -0500 X-MIMETrack: Serialize by Router on D04NM200/04/M/IBM(Release 5.0.3 (Intl)|21 March 2000) at 12/06/2000 02:38:44 PM 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 Andrew, I'm still having trouble with the egress half of your symmetric solution. Here's how I visualize your idea of metering aggregated traffic across a set of egress interfaces: +---------+ +----------+ | |i/f 1---\ | |--> i/f 1 | | \ | | |Routing |i/f 2----->meter-->|classifier|--> i/f 2 |Core | / | | | |i/f 3---/ | |--> i/f 3 +---------+ +----------+ In words, the Routing Core does whatever it does to route packets (which is *outside* the scope of DiffServ), and for each packet selects egress i/f 1, 2, or 3. The data paths for these three egress interfaces then merge into a single meter, to provide the metering for the aggregated traffic. The meter is followed by a classifier, which fans the packets back out to their respective interfaces for queueing, scheduling, etc. It's the classifier that I don't understand. If the Routing Core selects an egress interface for a packet based on routing criteria that are outside the scope of DiffServ, then how can the classifier get each packet back to the correct interface? What is it filtering on? It can't base its decision on which interface the packet traversed just before the meter, because the model stipulates that a packet doesn't "remember" where it has been. Do you have a different way of thinking about this situation, one that doesn't run into this problem? Regards, Bob Bob Moore IBM Networking Software +1-919-254-4436 remoore@us.ibm.com Andrew Smith on 12/06/2000 01:38:08 PM To: Robert Moore/Raleigh/IBM@IBMUS cc: diffserv Subject: Re: [Diffserv] Model draft - sharing elements on multiple interfaces Bob, I think you're trying to craft a compromise with Keith here but what you propose is inconsistent. [Note that I didn't mention the MIB in my message: the MIB can implement a subset of the model if it so chooses, so long as it is not inconsistent with the model, but that's not the point I raised - by all means discuss the impact of this issue on the MIB in a separate thread but don't let that confuse this discussion of the model]. The point in question is whether "shared-between-multiple-interfaces" elements are both (a) useful for implementing specific services and (b) likely to be implemented by more than one vendor and (c) without this change, does it make it impossible/unlikely that the model can be used to represent a significant set of devices? I believe that, for (a), the model needs to be symmetric: if such a service is useful for "in" then it is also for "out" e.g. metering on a collection of interfaces representing one customer is just as useful in both directions. As regards (b), I'd like to hear some more opinions: so far the exit poll (3 opinions) seems to read: In? Out? Y/N Y/N 2/1 1/2 (if that notation makes sense). And for (c) I'm not sure we have any data points. Andrew Robert Moore wrote: > Keith, > > If I'm understanding you correctly, then I think I agree > with you. We can allow the sharing of conditioning > elements in the ingress case, but continue to rule it out > for egress. This covers a case like a single meter that > processes traffic aggregated from several ingress > interfaces, which seems like something we want to allow. > But it doesn't complicate the MIB in the egress case. > > If we allow sharing of conditioning elements for ingress > interfaces, I think there are two cases that need to be > mentioned in the MIB: > > - Two DataPathStart pointers pointing to the same > element. If we leave it at that, we have no answer > to the question "Which data path is the element > *really* on?" But I think this is OK -- we can > say that it's equally on both data paths. > - A "next" pointer in a conditioning element pointing > to a next conditioning element on a different > data path. > > The MIB would also have to say clearly that these two > options are *not* allowed for egress data paths. > > For Andrew's picture, I think it would be fine to > combine the new version for the ingress side with the > old version for the egress side. > > Does this sound good to everybody? > > Regards, > Bob > > Bob Moore > IBM Networking Software > +1-919-254-4436 > remoore@us.ibm.com > > > > Keith McCloghrie @ietf.org on 12/05/2000 05:19:33 PM > > Sent by: diffserv-admin@ietf.org > > > To: Robert Moore/Raleigh/IBM@IBMUS > cc: kzm@cisco.com (Keith McCloghrie), andrew@allegronetworks.com (Andrew > Smith), diffserv@ietf.org (diffserv) > Subject: Re: [Diffserv] Model draft - sharing elements on multiple > interfaces > > > > Bob, > > I was arguing against additional complexity, which was what I believed > would ensue from Andrew's proposed change from: > > >>> -> I -> core -> E -> >>> >>> The proposal would be to modify this to something like: >>> >>> -> I -+-> I -> core -> E -+-> E -> >>> | | >>> -> I -+ +-> E -> >> > > I think it would be possible to allow merging on ingress just by > removing the restriction on two data paths merging, which is stated > in this ASN.1 comment (I think that's the only place it's specified): > > -- The use of next pointer to point to diffserv functional datapath > -- element of a different datapath is not allowed > > I agree it's harder for egress which requries splitting, for which > I think the current MIB structure is insufficient, and my concern is > that a MIB structure which would allow it is going to be more complex. > > Keith. > > > >> Keith, >> >> I'm not sure what you're arguing for here. At least >> on the ingress side, sharing an element (say a >> Classifier) between two ingress interfaces amounts >> to having the dataPathStart pointers for two entries >> in the dataPathTable point to the same entry in the >> diffServClassifier table. Are you saying that the MIB >> currently rules this out? If so, I've missed it. Or >> are you saying that while the MIB doesn't currently >> rule it out, it should be changed so that it does? >> >> It's a little harder to describe for egress, but I >> think the idea would be that two Data Paths start out >> together, but then somehow diverge before they're done. >> I'm not sure exactly how to express this in terms of >> the Next pointers, but the same question I asked you >> above applies here as well: do you think that the MIB >> currently does outlaw this setup, or do you think that >> it should (but doesn't now)? >> >> Thanks. >> >> Regards, >> Bob >> >> Bob Moore >> IBM Networking Software >> +1-919-254-4436 >> remoore@us.ibm.com >> >> >> >> Keith McCloghrie on 12/05/2000 03:54:50 PM >> >> To: andrew@allegronetworks.com (Andrew Smith) >> cc: diffserv@ietf.org (diffserv), Robert Moore/Raleigh/IBM@IBMUS >> Subject: Re: [Diffserv] Model draft - sharing elements on multiple >> interfaces >> >> >> >> I think the DiffServ MIB is only just use-able at the moment due to >> its surfeit of complexity, and I suggest that incorporating the below >> into the model and thus reflecting it into the MIB will push the MIB >> over the "cliff" to become of no use to anybody. >> >> Keith. >> >> >>> This is a proposal for a solution to the second issue in my earlier >> >> message >> >>> Ref: >> > http://www.ietf.org/internet-drafts/draft-ietf-diffserv-model-05.txt > >>> 2. Sharing of elements amongst multiple interfaces. >>> >>> Bob Moore has made a good point: right now the model describes >> > everything > >> that >> >>> happens to a packet as it arrives on ingress to *an* interface, then it >> >> goes >> >>> through a routing core, then it describes what happens on egress from >> >> *an* >> >>> interface. The problem is that there are very valid scenarios (and >>> implementation architectures too, although that's not really our >> > problem > >> here) >> >>> where you want traffic streams from multiple ingress interfaces to >> >> receive >> >>> shared processing before they get to the switch fabric. Ditto for a >> >> stream on >> >>> egress to receive some diffserv processing before being split out to >> > its > >> final >> >>> egress interface. This is a fairly fundamental ommission and I don't >> >> think it >> >>> can be tackled by hand-waving. So we should choose whether to support >> > it > >>> explicitly or not. >>> >>> To support it, I think we need a modified top-level diagram that shows >> >> that you >> >>> may repeat the routing core and subsequent "interface" blocks multiple >> >> times. >> >>> The current figure 2 implies that you may have only one "ingress >> >> interface >> >>> block" and one "egress interface block" per interface (the blocks are >> > the > >> dotted >> >>> boxes in the figure). I believe we would need an additional "routing >> >> core" of >> >>> some sort in between the first per-interface block and any subsequent >>> shared-multi-interface block in order to express the interconnections >> >> (similar >> >>> for egress). Do we then need arbitrary concatenations of such blocks or >> >> does 2 >> >>> on ingress and 2 on egress of each suffice? >>> >>> I'm too lazy to draw the real picture right now (a real ASCII-art >> >> challenge to >> >>> do it in only 72 columns) but it's something like this: right now we >> > have > >> one >> >>> direction, the top half, of figure 2 as: >>> >>> -> I -> core -> E -> >>> >>> The proposal would be to modify this to something like: >>> >>> -> I -+-> I -> core -> E -+-> E -> >>> | | >>> -> I -+ +-> E -> >>> >>> Where "I" represents an Ingress block and "E" represents an Egress >> > block. > >> And >> >>> you could represent the merge/split functions as additional routing >> > cores > >>> (albeit simplified ones, still out of scope for this model: maybe this >> >> would be >> >>> a use for those under-utilised Multiplexor and Demultiplexor elements >> > but > >> they'd >> >>> have to be redefined so that their scope could span multiple interfaces >> > - > >> right >> >>> now all elements are implicitly instantiated per-interface in this >> >> model). >> >>> [I don't know if this solves Bob's issue or not - hopefully he'll let >> > us > >> know.] >> >>> Andrew Smith >>> (editor of this draft) >>> >>> >>> _______________________________________________ >>> diffserv mailing list >>> diffserv@ietf.org >>> http://www1.ietf.org/mailman/listinfo/diffserv >>> Archive: >> > http://www2.ietf.org/mail-archive/working-groups/diffserv/current/maillist.html > > >>> >> >> >> > > > _______________________________________________ > diffserv mailing list > diffserv@ietf.org > http://www1.ietf.org/mailman/listinfo/diffserv > Archive: > http://www2.ietf.org/mail-archive/working-groups/diffserv/current/maillist.html > > > > > _______________________________________________ > diffserv mailing list > diffserv@ietf.org > http://www1.ietf.org/mailman/listinfo/diffserv > Archive: http://www2.ietf.org/mail-archive/working-groups/diffserv/current/maillist.html _______________________________________________ diffserv mailing list diffserv@ietf.org http://www1.ietf.org/mailman/listinfo/diffserv Archive: http://www2.ietf.org/mail-archive/working-groups/diffserv/current/maillist.html From diffserv-admin@ietf.org Wed Dec 6 16: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 SMTP id QAA01133 for ; Wed, 6 Dec 2000 16:40:47 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id QAA21447; Wed, 6 Dec 2000 16:13:00 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id QAA21416 for ; Wed, 6 Dec 2000 16:12:56 -0500 (EST) Received: from zrtps06s.us.nortel.com (h50s48a140n47.user.nortelnetworks.com [47.140.48.50]) by ietf.org (8.9.1a/8.9.1a) with SMTP id QAA22245 for ; Wed, 6 Dec 2000 16:12:56 -0500 (EST) Message-Id: <200012062112.QAA22245@ietf.org> Received: from zbl6c016.corpeast.baynetworks.com by zrtps06s.us.nortel.com; Wed, 6 Dec 2000 14:32:34 -0500 Received: from zbl6c002.corpeast.baynetworks.com ([132.245.205.52]) by zbl6c016.corpeast.baynetworks.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2652.39) id W8KSPX8V; Wed, 6 Dec 2000 14:29:02 -0500 Received: from tweedy (dhcp223-142.engeast.baynetworks.com [192.32.223.142]) by zbl6c002.corpeast.baynetworks.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2652.39) id YJ8X7WTR; Wed, 6 Dec 2000 14:29:03 -0500 X-Sender: khchan@zbl6c002.corpeast.baynetworks.com X-Mailer: QUALCOMM Windows Eudora Pro Version 4.0 Date: Wed, 06 Dec 2000 14:27:49 -0500 To: "Iliff, Tina" X-Sybari-Space: 00000000 00000000 00000000 From: "Kwok-Ho Chan" Subject: Re: [Diffserv] diffsev-pib-02: qosQSchdParam Cc: "'diffserv@ietf.org'" In-Reply-To: <492EB4A3F68CD411ABE800508B69362E14B3C2@RIPEXCH002.wcomnet. com> Mime-Version: 1.0 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable X-Orig: Content-Transfer-Encoding: quoted-printable Sender: diffserv-admin@ietf.org Errors-To: diffserv-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Diffserv Discussion List X-BeenThere: diffserv@ietf.org Content-Transfer-Encoding: quoted-printable Tina:
Because a scheduler is a "Fan-In" element, many input, single output;
the queues that fan-into a scheduler will each need a SchdParam entry
to specify its scheduling order with respect to the other queues that feed
into the same scheduler.
It is also possible to have scheduler feeding into scheduler, hence the
SchdParam entry associated with a scheduler entry.
Hope this clear things up for you, please let me know.
-- Kwok --

At 04:37 PM 12/6/00 +0000, Iliff, Tina wrote:

All,

I have a concern regarding the structure of the qosQ table.=A0 It contains an attribute named SchdParam which provides the parameters used by the scheduler element for this particular queue.=A0 My concern is that there is also a SchdParam attribute in the qosScheduler table.=A0 It makes more sense to leave the parameter in the qosScheduler table and not in the qosQ table.=A0 It seems it is a duplication of information.

Tina Iliff


_______________________________________________ diffserv mailing list diffserv@ietf.org http://www1.ietf.org/mailman/listinfo/diffserv Archive: http://www2.ietf.org/mail-archive/working-groups/diffserv/current/maillist.html From diffserv-admin@ietf.org Wed Dec 6 16:41:21 2000 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with SMTP id QAA01261 for ; Wed, 6 Dec 2000 16:41:21 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id QAA21492; Wed, 6 Dec 2000 16:14:19 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id QAA21461 for ; Wed, 6 Dec 2000 16:14:10 -0500 (EST) Received: from pmesmtp01.wcom.com (pmesmtp01.wcom.com [199.249.20.1]) by ietf.org (8.9.1a/8.9.1a) with SMTP id QAA22587 for ; Wed, 6 Dec 2000 16:14:10 -0500 (EST) Received: from CONVERSION-DAEMON by firewall.mcit.com (PMDF V5.2-32 #42256) id <0G56008010731D@firewall.mcit.com> for diffserv@ietf.org; Wed, 6 Dec 2000 21:11:28 +0000 (GMT) Received: from pmismtp01.wcomnet.com ([166.38.62.36]) by firewall.mcit.com (PMDF V5.2-32 #42256) with ESMTP id <0G56002JD073B1@firewall.mcit.com>; Wed, 06 Dec 2000 21:11:27 +0000 (GMT) Received: from CONVERSION-DAEMON by pmismtp01.wcomnet.com (PMDF V5.2-33 #42258) id <0G5600401073T6@pmismtp01.wcomnet.com>; Wed, 06 Dec 2000 21:11:27 +0000 (GMT) Received: from pmismtp01.wcomnet.com by pmismtp01.wcomnet.com (PMDF V5.2-33 #42258) with SMTP id <0G560040106TRV@pmismtp01.wcomnet.com>; Wed, 06 Dec 2000 21:11:26 +0000 (GMT) Received: from omzexch006.mcit.com ([166.37.194.37]) by pmismtp01.wcomnet.com (PMDF V5.2-33 #42258) with ESMTP id <0G5600KOY06JO2@pmismtp01.wcomnet.com>; Wed, 06 Dec 2000 21:11:07 +0000 (GMT) Received: by omzexch006 with Internet Mail Service (5.5.2651.58) id ; Wed, 06 Dec 2000 21:11:06 +0000 Content-return: allowed Date: Wed, 06 Dec 2000 21:11:04 +0000 From: "Iliff, Tina" Subject: RE: [Diffserv] diffsev-pib-02: qosQSchdParam To: "'Kwok-Ho Chan'" Cc: "'diffserv@ietf.org'" Message-id: <492EB4A3F68CD411ABE800508B69362E14B3D1@RIPEXCH002.wcomnet.com> MIME-version: 1.0 X-Mailer: Internet Mail Service (5.5.2651.58) Content-type: multipart/alternative; boundary="Boundary_(ID_Z8nA5AYK34KOvYHI9GqhCg)" Sender: diffserv-admin@ietf.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. --Boundary_(ID_Z8nA5AYK34KOvYHI9GqhCg) Content-type: text/plain; charset=ISO-8859-1 Kwok, I understand the "Fan-In" concept and architecture. However, how about considering this suggestion: add a priority attribute to qosQ, remove the SchdParam attribute and remove the priority attribute from qosSchdParam since priority is a Queue specific "tag" and not Scheduler specific. Tina -----Original Message----- From: Kwok-Ho Chan [mailto:khchan@nortelnetworks.com] Sent: Wednesday, December 06, 2000 1:28 PM To: Iliff, Tina Cc: 'diffserv@ietf.org' Subject: Re: [Diffserv] diffsev-pib-02: qosQSchdParam Tina: Because a scheduler is a "Fan-In" element, many input, single output; the queues that fan-into a scheduler will each need a SchdParam entry to specify its scheduling order with respect to the other queues that feed into the same scheduler. It is also possible to have scheduler feeding into scheduler, hence the SchdParam entry associated with a scheduler entry. Hope this clear things up for you, please let me know. -- Kwok -- At 04:37 PM 12/6/00 +0000, Iliff, Tina wrote: All, I have a concern regarding the structure of the qosQ table. It contains an attribute named SchdParam which provides the parameters used by the scheduler element for this particular queue. My concern is that there is also a SchdParam attribute in the qosScheduler table. It makes more sense to leave the parameter in the qosScheduler table and not in the qosQ table. It seems it is a duplication of information. Tina Iliff --Boundary_(ID_Z8nA5AYK34KOvYHI9GqhCg) Content-type: text/html; charset=ISO-8859-1
Kwok,
 
I understand the "Fan-In" concept and architecture.  However, how about considering this suggestion:  add a priority attribute to qosQ, remove the SchdParam attribute and remove the priority attribute from qosSchdParam since priority is a Queue specific "tag" and not Scheduler specific.
 
Tina
-----Original Message-----
From: Kwok-Ho Chan [mailto:khchan@nortelnetworks.com]
Sent: Wednesday, December 06, 2000 1:28 PM
To: Iliff, Tina
Cc: 'diffserv@ietf.org'
Subject: Re: [Diffserv] diffsev-pib-02: qosQSchdParam

Tina:
Because a scheduler is a "Fan-In" element, many input, single output;
the queues that fan-into a scheduler will each need a SchdParam entry
to specify its scheduling order with respect to the other queues that feed
into the same scheduler.
It is also possible to have scheduler feeding into scheduler, hence the
SchdParam entry associated with a scheduler entry.
Hope this clear things up for you, please let me know.
-- Kwok --

At 04:37 PM 12/6/00 +0000, Iliff, Tina wrote:

All,

I have a concern regarding the structure of the qosQ table.  It contains an attribute named SchdParam which provides the parameters used by the scheduler element for this particular queue.  My concern is that there is also a SchdParam attribute in the qosScheduler table.  It makes more sense to leave the parameter in the qosScheduler table and not in the qosQ table.  It seems it is a duplication of information.

Tina Iliff


--Boundary_(ID_Z8nA5AYK34KOvYHI9GqhCg)-- _______________________________________________ diffserv mailing list diffserv@ietf.org http://www1.ietf.org/mailman/listinfo/diffserv Archive: http://www2.ietf.org/mail-archive/working-groups/diffserv/current/maillist.html From diffserv-admin@ietf.org Wed Dec 6 18:14: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 SMTP id SAA29557 for ; Wed, 6 Dec 2000 18:14:17 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id RAA22680; Wed, 6 Dec 2000 17:51:27 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id RAA22646 for ; Wed, 6 Dec 2000 17:51:23 -0500 (EST) Received: from mailman.packetdesign.com (dns.PACKETDESIGN.NET [216.15.46.10]) by ietf.org (8.9.1a/8.9.1a) with SMTP id RAA23500 for ; Wed, 6 Dec 2000 17:51:21 -0500 (EST) Received: from packetdesign.com (dhcp-168-0-13.packetdesign.com [192.168.0.13]) by mailman.packetdesign.com (8.11.0/8.11.0) with ESMTP id eB6MoEQ99209; Wed, 6 Dec 2000 14:50:14 -0800 (PST) (envelope-from nichols@packetdesign.com) Message-ID: <3A2EC561.41FE1997@packetdesign.com> Date: Wed, 06 Dec 2000 15:01:53 -0800 From: Kathleen Nichols X-Mailer: Mozilla 4.73 [en] (X11; I; Linux 2.2.12 i386) X-Accept-Language: en MIME-Version: 1.0 To: demir CC: John Schnizlein , Brian E Carpenter , diffserv@ietf.org Subject: Re: [Diffserv] EFRESOLVE definition in the presence of excess inputburstiness References: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: diffserv-admin@ietf.org Errors-To: diffserv-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Diffserv Discussion List X-BeenThere: diffserv@ietf.org Content-Transfer-Encoding: 7bit demir wrote: > ... I agree that Diffserv chose to define a > small set of mechanisms first, not services. That's how a QoS architecture > should be. I am arguing about this "implicit agreement" if there is > such a thing. If there is, it should be an "explicit aggrement". I may be missing the point here, but I think if you read the diffserv charter, this is made explicit: http://ietf.org/html.charters/diffserv-charter.html or, at least, our intent in that charter, approved by the IESG, was to be explicit in what diffserv was about and was to accomplish. Perhaps we are not as clear as we'd like to be? ...orking group. > > > > At 03:15 PM 12/04/2000 -0800, demir wrote: > > >... I am pointing out a "PHB" definition issue. > > >I am talking about a problem of the current architecture > > >(where some MAYs won't have any effect on the current): > > > > > >- "First, we want to start out by implementing a simple set of > > > services, which are useful and easy to understand. At the same time, > > > we should not embed these services into the mechanism, but should > > > build a general mechanism that allows us to change the services as > > > our experience matures."- D. Clark / J. Wroclawski, "An Approach to > > > Service Allocation in the Internet" > > > > > >It seems to me that G4 along with other guideslines are > > >restrictive. Services (expected) are being embedded into the PHB > > >mechanisms. > > So somethign I'd like to say here is to be careful in equating the pre-diffserv terminology that Clark and Wroclawski used to the terminology that's been defined since the WG was chartered. Clark's use of "mechanism" is analogous to what we call the per-hop forwarding behavior or PHB. "Mechanism" was objected to, particularly by vendors, because it sounded too much like "implementation" which they objected to having specified. I hope we are not embedding expected services into PHB definitions. This was why we took the approach we did for RFC 2598, though we had a particular service in mind. There are "SHOULDs" that allow one to relax things. On the other hand, when a particular "service" IS in mind, it would be well to have a PHB available that will implement it. Particularly if there is commercial interest in such a "service". Kathie _______________________________________________ diffserv mailing list diffserv@ietf.org http://www1.ietf.org/mailman/listinfo/diffserv Archive: http://www2.ietf.org/mail-archive/working-groups/diffserv/current/maillist.html From diffserv-admin@ietf.org Wed Dec 6 21:11:09 2000 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with SMTP id VAA05642 for ; Wed, 6 Dec 2000 21:11:09 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id UAA24408; Wed, 6 Dec 2000 20:40:26 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id UAA24377 for ; Wed, 6 Dec 2000 20:40:21 -0500 (EST) Received: from usc.edu (root@usc.edu [128.125.253.136]) by ietf.org (8.9.1a/8.9.1a) with SMTP id UAA01991 for ; Wed, 6 Dec 2000 20:40:20 -0500 (EST) Received: from sal-sun001.usc.edu (demir@sal-sun001.usc.edu [128.125.5.71]) by usc.edu (8.9.3.1/8.9.3/usc) with ESMTP id RAA21420; Wed, 6 Dec 2000 17:40:20 -0800 (PST) Received: from localhost (demir@localhost) by sal-sun001.usc.edu (8.9.3.1/8.9.3/usc) with ESMTP id RAA07870; Wed, 6 Dec 2000 17:40:18 -0800 (PST) Date: Wed, 6 Dec 2000 17:40:18 -0800 (PST) From: demir To: Kathleen Nichols cc: John Schnizlein , Brian E Carpenter , diffserv@ietf.org Subject: Re: [Diffserv] EFRESOLVE definition in the presence of excess inputburstiness In-Reply-To: <3A2EC561.41FE1997@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, > So somethign I'd like to say here is to be careful in equating the > pre-diffserv terminology that Clark and Wroclawski used to the > terminology that's been defined since the WG was chartered. Clark's > use of "mechanism" is analogous to what we call the per-hop forwarding > behavior or PHB. "Mechanism" was objected to, particularly by vendors, > because it sounded too much like "implementation" which they objected > to having specified. Exactly. That's how I refered it. > I hope we are not embedding expected services into PHB definitions. This > was why we took the approach we did for RFC 2598, though we had a > particular > service in mind. There are "SHOULDs" that allow one to relax things. On > the other hand, when a particular "service" IS in mind, it would be well > to have a PHB available that will implement it. Particularly if there > is commercial interest in such a "service". - My general point was about "what you hope". To me, EFRESOLVE has a risk of embedding services into EF PHB. S term is very risky (Intuitively, I feel that bounding delay at a hop in an efficient way might be a problem). Not does only it might depend on "network topology", but also it closely depends on the "scheduling" mechanisms used in a hop (This can be okay for a hop. I still see it as "embedding services" into the PHB. If someone comes up with a "bright" idea to achieve this goal on a PHB, that would be great. PDBs can handle it in the future because, the current EF PHB doesn't have any risk. - My suggestion: To keep the current EF PHB the way it is. - I emailed a new suggestion that EF MAY have "queuing and discard" behavior for EF PHB (my previous email). This won't change the current trend. It will leave an open window for "qualitative" services and it will help when "trafic conditioners" fail. Brian refered it as "fundamental" change (I assume he refered as "fundamental change" for EF). I agree. However, it would have been nice. If someone doesn't like it, he/she doesn't use it in a Diffserv domain. - Toplogy dependent parameters should be avoided ina PHB. - Currently, unaccepted terminology such as "burstiness" should be avoided in a PHB definition. PDBs can do that however they like. - I think current EF PHB is fine. Alper K. Demir _______________________________________________ diffserv mailing list diffserv@ietf.org http://www1.ietf.org/mailman/listinfo/diffserv Archive: http://www2.ietf.org/mail-archive/working-groups/diffserv/current/maillist.html From diffserv-admin@ietf.org Thu Dec 7 11:50:13 2000 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with SMTP id LAA17801 for ; Thu, 7 Dec 2000 11:50:12 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id LAA09355; Thu, 7 Dec 2000 11:09:50 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id LAA09326 for ; Thu, 7 Dec 2000 11:09:46 -0500 (EST) Received: from mailhub1.almaden.ibm.com (mailhub1.almaden.ibm.com [198.4.83.44]) by ietf.org (8.9.1a/8.9.1a) with SMTP id LAA08628 for ; Thu, 7 Dec 2000 11:09:45 -0500 (EST) Received: from maui.almaden.ibm.com (maui.almaden.ibm.com [9.1.24.92]) by mailhub1.almaden.ibm.com (8.8.8/8.8.8) with ESMTP id IAA23134; Thu, 7 Dec 2000 08:08:16 -0800 Received: from hursley.ibm.com (gsine04.us.sine.ibm.com [9.14.6.44]) by maui.almaden.ibm.com (AIX4.3/8.9.3/8.7) with ESMTP id IAA27282; Thu, 7 Dec 2000 08:09:05 -0800 Message-ID: <3A2FB5E2.9DFB91FC@hursley.ibm.com> Date: Thu, 07 Dec 2000 10:08:02 -0600 From: Brian E Carpenter Organization: IBM X-Mailer: Mozilla 4.61 [en] (Win98; I) X-Accept-Language: en,fr MIME-Version: 1.0 To: Vadim Suraev CC: "'diffserv@ietf.org'" Subject: Re: [Diffserv] AF PHB question References: <2B15221907365C468941FDFC02C87769CE7C@EXCHANGE.kerenix.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: diffserv-admin@ietf.org Errors-To: diffserv-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Diffserv Discussion List X-BeenThere: diffserv@ietf.org Content-Transfer-Encoding: 7bit No there isn't and no there shouldn't be. This is far too implementation- and configuration- sensitive to put in our specifications, IMHO. Brian Vadim Suraev wrote: > > Hi, DiffServers. > Is there any draft, specifies the formula for percentage of permitted packet > loss inside of AF PHB under normal conditions (no rate exceeding), AF is not > preempted by other PHB ? > I suppose, if EF PHB specifies formula for EF conformance (EFRESOLV), should > AF specify such formula for AF conformance ? > Thanks. > > KereniX Data-Aware Optical NetworksTM > ---------------------------------------------------------------------------- > ------ > Vadim Suraev http://www.kerenix.com > Phone: +972-3-9222077 x739 Mobile: 972-53-568711 > Fax: +972-3-9216769 vadim_suraev@kerenix.com > 8 Hashiloach St., POB 10053, Petach-Tikva 49001 ISRAEL > ---------------------------------------------------------------------------- _______________________________________________ diffserv mailing list diffserv@ietf.org http://www1.ietf.org/mailman/listinfo/diffserv Archive: http://www2.ietf.org/mail-archive/working-groups/diffserv/current/maillist.html From diffserv-admin@ietf.org Thu Dec 7 11:54:29 2000 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with SMTP id LAA18793 for ; Thu, 7 Dec 2000 11:54:25 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id LAA09566; Thu, 7 Dec 2000 11:19:59 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id LAA09539 for ; Thu, 7 Dec 2000 11:19:55 -0500 (EST) Received: from mailhub1.almaden.ibm.com (mailhub1.almaden.ibm.com [198.4.83.44]) by ietf.org (8.9.1a/8.9.1a) with SMTP id LAA10785 for ; Thu, 7 Dec 2000 11:19:53 -0500 (EST) Received: from maui.almaden.ibm.com (maui.almaden.ibm.com [9.1.24.92]) by mailhub1.almaden.ibm.com (8.8.8/8.8.8) with ESMTP id IAA28414; Thu, 7 Dec 2000 08:18:25 -0800 Received: from hursley.ibm.com (gsine04.us.sine.ibm.com [9.14.6.44]) by maui.almaden.ibm.com (AIX4.3/8.9.3/8.7) with ESMTP id IAA24772; Thu, 7 Dec 2000 08:19:18 -0800 Message-ID: <3A2FB846.ED7C43B8@hursley.ibm.com> Date: Thu, 07 Dec 2000 10:18:14 -0600 From: Brian E Carpenter Organization: IBM X-Mailer: Mozilla 4.61 [en] (Win98; I) X-Accept-Language: en,fr MIME-Version: 1.0 To: Dan Grossman CC: Andrew Smith , diffserv Subject: Re: [Diffserv] draft-ietf-diffserv-model-04.txt - what does it mean References: <200012041951.OAA01332@noah.dma.isg.mot.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: diffserv-admin@ietf.org Errors-To: diffserv-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Diffserv Discussion List X-BeenThere: diffserv@ietf.org Content-Transfer-Encoding: 7bit However, "best-effort" is the well-defined default behavior in RFC 2474. IMHO, saying that when you have nothing else to do to a packet, you treat it as BE is fully specified. Brian Dan Grossman wrote: > > > You see, I don't believe in this thing called "best effort" when you get down to > > the details of the per-hop thing: we insist that all arriving traffic meets a > > complete classifier and is divided into classes. Each class gets a specific > > treatment (e.g. access to forwarding, buffering or scheduling resources) *in > > relation to all the other classes*. There is no "special case", "default" or > > "other" treatment - everything needs to be specified. You should be able to > > model a (2-port) non-diffserv router as a classifier that matches everything, > > followed by a FIFO queue that gets access to all the buffering in the box, > > served by a scheduler that gets 100% of the line bandwidth, whenever there is > > data to send i.e. I believe that there is no such, at this level of the model, > > as "as if diffserv didn't exist". > > > > Andrew > > > What he said. :-) Except that treatment can be absolute, as well as in > relation to all other classes. And that one can apply the label "best effort" > to a classifier that matches everything, followed by a FIFO that gets access > to all the buffering that's left after the other classes, followed by a > scheduler that gets whatever transmission opportunities are left after all the > other classes have been satisfied. _______________________________________________ diffserv mailing list diffserv@ietf.org http://www1.ietf.org/mailman/listinfo/diffserv Archive: http://www2.ietf.org/mail-archive/working-groups/diffserv/current/maillist.html From diffserv-admin@ietf.org Thu Dec 7 11:59: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 SMTP id LAA19995 for ; Thu, 7 Dec 2000 11:59:22 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id LAA09455; Thu, 7 Dec 2000 11:13:52 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id LAA09424 for ; Thu, 7 Dec 2000 11:13:48 -0500 (EST) Received: from mailhub1.almaden.ibm.com (mailhub1.almaden.ibm.com [198.4.83.44]) by ietf.org (8.9.1a/8.9.1a) with SMTP id LAA09488 for ; Thu, 7 Dec 2000 11:13:45 -0500 (EST) Received: from maui.almaden.ibm.com (maui.almaden.ibm.com [9.1.24.92]) by mailhub1.almaden.ibm.com (8.8.8/8.8.8) with ESMTP id IAA30020 for ; Thu, 7 Dec 2000 08:12:17 -0800 Received: from hursley.ibm.com (gsine04.us.sine.ibm.com [9.14.6.44]) by maui.almaden.ibm.com (AIX4.3/8.9.3/8.7) with ESMTP id IAA32426 for ; Thu, 7 Dec 2000 08:13:14 -0800 Message-ID: <3A2FB6DB.F6A36B53@hursley.ibm.com> Date: Thu, 07 Dec 2000 10:12:11 -0600 From: Brian E Carpenter Organization: IBM X-Mailer: Mozilla 4.61 [en] (Win98; I) X-Accept-Language: en,fr MIME-Version: 1.0 To: "'diffserv@ietf.org'" Subject: Re: [Diffserv] Degree of detail in the DiffServ MIB References: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: diffserv-admin@ietf.org Errors-To: diffserv-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Diffserv Discussion List X-BeenThere: diffserv@ietf.org Content-Transfer-Encoding: 7bit I'd like opinions from diffservers whether the Policy WG is or is not getting into too much detail in this case. Brian Robert Moore wrote: > > Here is the DiffServ MIB's text describing the DSCP Mark Action Table: > > 3.4.1. DSCP Mark Action Table > > This Action is applied to traffic in order to mark it with a Diffserv > Codepoint (DSCP) value, specified in the diffServDscpMarkActTable. Other > marking actions might be specified elsewhere - these are outside the > scope of this MIB. > > And here is the text from QDDIM describing the property in > a DSCP marker that holds the DSCP value: > > 4.4.16.1 The Property DSCPValue > > This property is an unsigned 8-bit integer, representing a value to be > used for marking the DSCP within the DS field in an IPv4 or IPv6 packet > header. Since the DSCP consists of 6 bits, the values for this property > are limited to the range 0..63. When the DSCP is marked, the remaining > two bit in the DS field are left unchanged. > > Clearly there is an additional detail in the QDDIM version: > the statement that the remaining two bits are left unchanged. > (The range limitation 0..63 is handled in the MIB by the > Dscp Textual Convention (-1 | 0..63), combined with the > description text for the object, saying that the value -1 > is not allowed.) In the ordinary Policy Framework treatment > ("ordinary" based on one partially completed example of PCIM > and PCLS, but never mind that:-), this level of detail would > be documented in the Information Model (QDDIM in this case), > and then incorporated by reference into the Data Models (the > MIB and the PIB) derived from it. But in this case the Data > Models are much more mature, and thus closer to completion, > than the QDDIM. The only remaining alternatives are either > not to have the detail at all in the MIB and PIB, or else to > copy the QDDIM text into them. I vote for copying the text > in, because of past history of cases in which "everybody knows > what that means" being exposed as cases in which different > people "know" different things. > > I don't have a complete list, but I'm sure this is not the > only instance where the QDDIM has more detail than the two > diffserv Data Models. > > 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://www2.ietf.org/mail-archive/working-groups/diffserv/current/maillist.html From diffserv-admin@ietf.org Thu Dec 7 12:03: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 SMTP id MAA21348 for ; Thu, 7 Dec 2000 12:03:24 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id LAA09712; Thu, 7 Dec 2000 11:25:43 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id LAA09681 for ; Thu, 7 Dec 2000 11:25:38 -0500 (EST) Received: from mailhub1.almaden.ibm.com (mailhub1.almaden.ibm.com [198.4.83.44]) by ietf.org (8.9.1a/8.9.1a) with SMTP id LAA11970 for ; Thu, 7 Dec 2000 11:25:37 -0500 (EST) Received: from maui.almaden.ibm.com (maui.almaden.ibm.com [9.1.24.92]) by mailhub1.almaden.ibm.com (8.8.8/8.8.8) with ESMTP id IAA47516; Thu, 7 Dec 2000 08:23:37 -0800 Received: from hursley.ibm.com (gsine04.us.sine.ibm.com [9.14.6.44]) by maui.almaden.ibm.com (AIX4.3/8.9.3/8.7) with ESMTP id IAA20490; Thu, 7 Dec 2000 08:24:33 -0800 Message-ID: <3A2FB980.14BEAD33@hursley.ibm.com> Date: Thu, 07 Dec 2000 10:23:28 -0600 From: Brian E Carpenter Organization: IBM X-Mailer: Mozilla 4.61 [en] (Win98; I) X-Accept-Language: en,fr MIME-Version: 1.0 To: Kathleen Nichols CC: Robert Moore , "'diffserv@ietf.org'" , policy@raleigh.ibm.com Subject: Re: [Diffserv] DSCP marking versus DSCP remarking References: <3A2D4EE0.EBFEAE43@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 I believe this is quite clearly discussed in RFC 2474/5. Packets arriving from a non-DS domain can't be regarded as containing a meaningful DSCP value until they have been classified and marked. I don't think that Policy WG documents should be in the business of tweaking the diffserv architecture. Brian Kathleen Nichols wrote: > > Robert Moore wrote: > > > ... > > > > This is *almost* just a question of wordsmithing in the > > three diffserv WG documents. But not quite. If there is > > actual disagreement in the WG about whether there is such > > a thing as an unmarked packet, that is, a packet that's > > not marked with any DSCP, then the question should be > > discussed until the WG reaches a consensus one way or the > > other. Does everybody agree with the QDDIM team that > > there is no such thing as a packet unmarked with any DSCP? > > > > With my WG co-chair hat OFF, I agree that we should just have > a "marker" as a primitive element. I would not phrase this as > saying "there is no such thing as a packet unmarked with any > DSCP". If someone chooses to use that phrase to describe > packets marked with an unknown, illegal, or unverified DSCP, > it should not have any architectural effect. > > Kathie > > _______________________________________________ > diffserv mailing list > diffserv@ietf.org > http://www1.ietf.org/mailman/listinfo/diffserv > Archive: http://www2.ietf.org/mail-archive/working-groups/diffserv/current/maillist.html _______________________________________________ diffserv mailing list diffserv@ietf.org http://www1.ietf.org/mailman/listinfo/diffserv Archive: http://www2.ietf.org/mail-archive/working-groups/diffserv/current/maillist.html From diffserv-admin@ietf.org Thu Dec 7 12:18: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 SMTP id MAA25409 for ; Thu, 7 Dec 2000 12:18:15 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id LAA09990; Thu, 7 Dec 2000 11:35:27 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id LAA09962 for ; Thu, 7 Dec 2000 11:35:23 -0500 (EST) Received: from mailhub1.almaden.ibm.com (mailhub1.almaden.ibm.com [198.4.83.44]) by ietf.org (8.9.1a/8.9.1a) with SMTP id LAA14222 for ; Thu, 7 Dec 2000 11:35:21 -0500 (EST) Received: from maui.almaden.ibm.com (maui.almaden.ibm.com [9.1.24.92]) by mailhub1.almaden.ibm.com (8.8.8/8.8.8) with ESMTP id IAA24254; Thu, 7 Dec 2000 08:33:49 -0800 Received: from hursley.ibm.com (gsine04.us.sine.ibm.com [9.14.6.44]) by maui.almaden.ibm.com (AIX4.3/8.9.3/8.7) with ESMTP id IAA32434; Thu, 7 Dec 2000 08:34:46 -0800 Message-ID: <3A2FBBE4.58F0DF4D@hursley.ibm.com> Date: Thu, 07 Dec 2000 10:33:40 -0600 From: Brian E Carpenter Organization: IBM X-Mailer: Mozilla 4.61 [en] (Win98; I) X-Accept-Language: en,fr MIME-Version: 1.0 To: Keith McCloghrie CC: Robert Moore , Andrew Smith , diffserv Subject: Re: [Diffserv] Model draft - sharing elements on multiple interfaces References: <200012052219.OAA22003@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 How about covering this by a text note in the document, not by drawing the picture. "this model does not exclude the sharing of elements by more than one ingress, or even by more than one egress, but this is not explicitly modelled by the current document." Brian Keith McCloghrie wrote: > > Bob, > > I was arguing against additional complexity, which was what I believed > would ensue from Andrew's proposed change from: > > > > -> I -> core -> E -> > > > > > > The proposal would be to modify this to something like: > > > > > > -> I -+-> I -> core -> E -+-> E -> > > > | | > > > -> I -+ +-> E -> > > I think it would be possible to allow merging on ingress just by > removing the restriction on two data paths merging, which is stated > in this ASN.1 comment (I think that's the only place it's specified): > > -- The use of next pointer to point to diffserv functional datapath > -- element of a different datapath is not allowed > > I agree it's harder for egress which requries splitting, for which > I think the current MIB structure is insufficient, and my concern is > that a MIB structure which would allow it is going to be more complex. > > Keith. > > > > Keith, > > > > I'm not sure what you're arguing for here. At least > > on the ingress side, sharing an element (say a > > Classifier) between two ingress interfaces amounts > > to having the dataPathStart pointers for two entries > > in the dataPathTable point to the same entry in the > > diffServClassifier table. Are you saying that the MIB > > currently rules this out? If so, I've missed it. Or > > are you saying that while the MIB doesn't currently > > rule it out, it should be changed so that it does? > > > > It's a little harder to describe for egress, but I > > think the idea would be that two Data Paths start out > > together, but then somehow diverge before they're done. > > I'm not sure exactly how to express this in terms of > > the Next pointers, but the same question I asked you > > above applies here as well: do you think that the MIB > > currently does outlaw this setup, or do you think that > > it should (but doesn't now)? > > > > Thanks. > > > > Regards, > > Bob > > > > Bob Moore > > IBM Networking Software > > +1-919-254-4436 > > remoore@us.ibm.com > > > > > > > > Keith McCloghrie on 12/05/2000 03:54:50 PM > > > > To: andrew@allegronetworks.com (Andrew Smith) > > cc: diffserv@ietf.org (diffserv), Robert Moore/Raleigh/IBM@IBMUS > > Subject: Re: [Diffserv] Model draft - sharing elements on multiple > > interfaces > > > > > > > > I think the DiffServ MIB is only just use-able at the moment due to > > its surfeit of complexity, and I suggest that incorporating the below > > into the model and thus reflecting it into the MIB will push the MIB > > over the "cliff" to become of no use to anybody. > > > > Keith. > > > > > This is a proposal for a solution to the second issue in my earlier > > message > > > Ref: http://www.ietf.org/internet-drafts/draft-ietf-diffserv-model-05.txt > > > > > > 2. Sharing of elements amongst multiple interfaces. > > > > > > Bob Moore has made a good point: right now the model describes everything > > that > > > happens to a packet as it arrives on ingress to *an* interface, then it > > goes > > > through a routing core, then it describes what happens on egress from > > *an* > > > interface. The problem is that there are very valid scenarios (and > > > implementation architectures too, although that's not really our problem > > here) > > > where you want traffic streams from multiple ingress interfaces to > > receive > > > shared processing before they get to the switch fabric. Ditto for a > > stream on > > > egress to receive some diffserv processing before being split out to its > > final > > > egress interface. This is a fairly fundamental ommission and I don't > > think it > > > can be tackled by hand-waving. So we should choose whether to support it > > > explicitly or not. > > > > > > To support it, I think we need a modified top-level diagram that shows > > that you > > > may repeat the routing core and subsequent "interface" blocks multiple > > times. > > > The current figure 2 implies that you may have only one "ingress > > interface > > > block" and one "egress interface block" per interface (the blocks are the > > dotted > > > boxes in the figure). I believe we would need an additional "routing > > core" of > > > some sort in between the first per-interface block and any subsequent > > > shared-multi-interface block in order to express the interconnections > > (similar > > > for egress). Do we then need arbitrary concatenations of such blocks or > > does 2 > > > on ingress and 2 on egress of each suffice? > > > > > > I'm too lazy to draw the real picture right now (a real ASCII-art > > challenge to > > > do it in only 72 columns) but it's something like this: right now we have > > one > > > direction, the top half, of figure 2 as: > > > > > > -> I -> core -> E -> > > > > > > The proposal would be to modify this to something like: > > > > > > -> I -+-> I -> core -> E -+-> E -> > > > | | > > > -> I -+ +-> E -> > > > > > > Where "I" represents an Ingress block and "E" represents an Egress block. > > And > > > you could represent the merge/split functions as additional routing cores > > > (albeit simplified ones, still out of scope for this model: maybe this > > would be > > > a use for those under-utilised Multiplexor and Demultiplexor elements but > > they'd > > > have to be redefined so that their scope could span multiple interfaces - > > right > > > now all elements are implicitly instantiated per-interface in this > > model). > > > > > > [I don't know if this solves Bob's issue or not - hopefully he'll let us > > know.] > > > > > > Andrew Smith > > > (editor of this draft) > > > > > > > > > _______________________________________________ > > > diffserv mailing list > > > diffserv@ietf.org > > > http://www1.ietf.org/mailman/listinfo/diffserv > > > Archive: > > http://www2.ietf.org/mail-archive/working-groups/diffserv/current/maillist.html > > > > > > > > > > > > > > > > > > _______________________________________________ > diffserv mailing list > diffserv@ietf.org > http://www1.ietf.org/mailman/listinfo/diffserv > Archive: http://www2.ietf.org/mail-archive/working-groups/diffserv/current/maillist.html -- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - Brian E Carpenter Program Director, Internet Standards & Technology, IBM On assignment for IBM at http://www.iCAIR.org Board Chairman, Internet Society http://www.isoc.org Non-IBM email: brian@icair.org _______________________________________________ diffserv mailing list diffserv@ietf.org http://www1.ietf.org/mailman/listinfo/diffserv Archive: http://www2.ietf.org/mail-archive/working-groups/diffserv/current/maillist.html From diffserv-admin@ietf.org Thu Dec 7 12:27:57 2000 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with SMTP id MAA27928 for ; Thu, 7 Dec 2000 12:27:52 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id LAA10227; Thu, 7 Dec 2000 11:50:24 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id LAA10196 for ; Thu, 7 Dec 2000 11:50:20 -0500 (EST) Received: from mailhub1.almaden.ibm.com (mailhub1.almaden.ibm.com [198.4.83.44]) by ietf.org (8.9.1a/8.9.1a) with SMTP id LAA17849 for ; Thu, 7 Dec 2000 11:50:18 -0500 (EST) Received: from maui.almaden.ibm.com (maui.almaden.ibm.com [9.1.24.92]) by mailhub1.almaden.ibm.com (8.8.8/8.8.8) with ESMTP id IAA42834; Thu, 7 Dec 2000 08:48:49 -0800 Received: from hursley.ibm.com (gsine04.us.sine.ibm.com [9.14.6.44]) by maui.almaden.ibm.com (AIX4.3/8.9.3/8.7) with ESMTP id IAA20502; Thu, 7 Dec 2000 08:49:43 -0800 Message-ID: <3A2FBF57.D02D8AEE@hursley.ibm.com> Date: Thu, 07 Dec 2000 10:48:23 -0600 From: Brian E Carpenter Organization: IBM X-Mailer: Mozilla 4.61 [en] (Win98; I) X-Accept-Language: en,fr MIME-Version: 1.0 To: Sylvain Gingras CC: "'diffserv@ietf.org'" Subject: Re: [Diffserv] Re: I-D ACTION:draft-ietf-diffserv-model-05.txt (on Metering) References: <9DC5E2ABE65BD54CA9088DA3194461D6012FF0A7@BBY1EXM01> 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 should say more or less what I've said to Shahram in private: I believe (without checking the archive) that we changed this around in response to a clear majority view, knowing that some people disagree, but the IETF works by rough consensus. When we last call the document we by definition check the consensus and then we will see. We can't re-debate every point of disagreement on every draft. Brian Sylvain Gingras wrote: > > Regarding the discussion of the 'loose' and 'strict' token buckets, I was also > surprised at the unexplained and gradual shift away from the conventional 'strict' > token bucket policer in the latest versions of the text. ... _______________________________________________ diffserv mailing list diffserv@ietf.org http://www1.ietf.org/mailman/listinfo/diffserv Archive: http://www2.ietf.org/mail-archive/working-groups/diffserv/current/maillist.html From diffserv-admin@ietf.org Thu Dec 7 12:34: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 SMTP id MAA29490 for ; Thu, 7 Dec 2000 12:34:12 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id MAA10799; Thu, 7 Dec 2000 12:03:25 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id MAA10760 for ; Thu, 7 Dec 2000 12:03:21 -0500 (EST) Received: from mailhub1.almaden.ibm.com (mailhub1.almaden.ibm.com [198.4.83.44]) by ietf.org (8.9.1a/8.9.1a) with SMTP id MAA21315 for ; Thu, 7 Dec 2000 12:03:19 -0500 (EST) Received: from maui.almaden.ibm.com (maui.almaden.ibm.com [9.1.24.92]) by mailhub1.almaden.ibm.com (8.8.8/8.8.8) with ESMTP id JAA38730; Thu, 7 Dec 2000 09:01:47 -0800 Received: from hursley.ibm.com (gsine04.us.sine.ibm.com [9.14.6.44]) by maui.almaden.ibm.com (AIX4.3/8.9.3/8.7) with ESMTP id JAA20512; Thu, 7 Dec 2000 09:02:44 -0800 Message-ID: <3A2FC261.6FE20BA2@hursley.ibm.com> Date: Thu, 07 Dec 2000 11:01:21 -0600 From: Brian E Carpenter Organization: IBM X-Mailer: Mozilla 4.61 [en] (Win98; I) X-Accept-Language: en,fr MIME-Version: 1.0 To: Kathleen Nichols CC: demir , John Schnizlein , diffserv@ietf.org Subject: Re: [Diffserv] EFRESOLVE definition in the presence of excess inputburstiness References: <3A2EC561.41FE1997@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 And don't forget that DiffServ totally inverts the meaning of the words "service" and "behavior" compared to IntServ. Brian Kathleen Nichols wrote: > > demir wrote: > > > ... I agree that Diffserv chose to define a > > small set of mechanisms first, not services. That's how a QoS architecture > > should be. I am arguing about this "implicit agreement" if there is > > such a thing. If there is, it should be an "explicit aggrement". > > I may be missing the point here, but I think if you read the diffserv > charter, this is made explicit: > http://ietf.org/html.charters/diffserv-charter.html > > or, at least, our intent in that charter, approved by the IESG, was to > be explicit in what diffserv was about and was to accomplish. Perhaps > we are not as clear as we'd like to be? > > ...orking group. > > > > > > At 03:15 PM 12/04/2000 -0800, demir wrote: > > > >... I am pointing out a "PHB" definition issue. > > > >I am talking about a problem of the current architecture > > > >(where some MAYs won't have any effect on the current): > > > > > > > >- "First, we want to start out by implementing a simple set of > > > > services, which are useful and easy to understand. At the same time, > > > > we should not embed these services into the mechanism, but should > > > > build a general mechanism that allows us to change the services as > > > > our experience matures."- D. Clark / J. Wroclawski, "An Approach to > > > > Service Allocation in the Internet" > > > > > > > >It seems to me that G4 along with other guideslines are > > > >restrictive. Services (expected) are being embedded into the PHB > > > >mechanisms. > > > > > So somethign I'd like to say here is to be careful in equating the > pre-diffserv terminology that Clark and Wroclawski used to the > terminology that's been defined since the WG was chartered. Clark's > use of "mechanism" is analogous to what we call the per-hop forwarding > behavior or PHB. "Mechanism" was objected to, particularly by vendors, > because it sounded too much like "implementation" which they objected > to having specified. > > I hope we are not embedding expected services into PHB definitions. This > was why we took the approach we did for RFC 2598, though we had a > particular > service in mind. There are "SHOULDs" that allow one to relax things. On > the other hand, when a particular "service" IS in mind, it would be well > to have a PHB available that will implement it. Particularly if there > is commercial interest in such a "service". > > Kathie > > _______________________________________________ > diffserv mailing list > diffserv@ietf.org > http://www1.ietf.org/mailman/listinfo/diffserv > Archive: http://www2.ietf.org/mail-archive/working-groups/diffserv/current/maillist.html -- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - Brian E Carpenter Program Director, Internet Standards & Technology, IBM On assignment for IBM at http://www.iCAIR.org Board Chairman, Internet Society http://www.isoc.org Non-IBM email: brian@icair.org _______________________________________________ diffserv mailing list diffserv@ietf.org http://www1.ietf.org/mailman/listinfo/diffserv Archive: http://www2.ietf.org/mail-archive/working-groups/diffserv/current/maillist.html From diffserv-admin@ietf.org Thu Dec 7 12:54: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 SMTP id MAA02766 for ; Thu, 7 Dec 2000 12:54:45 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id MAA11167; Thu, 7 Dec 2000 12:17:25 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id MAA11139 for ; Thu, 7 Dec 2000 12:17:21 -0500 (EST) Received: from e21.nc.us.ibm.com (e21.nc.us.ibm.com [32.97.136.227]) by ietf.org (8.9.1a/8.9.1a) with SMTP id MAA25165 for ; Thu, 7 Dec 2000 12:17:17 -0500 (EST) Received: from southrelay02.raleigh.ibm.com (southrelay02.raleigh.ibm.com [9.37.3.209]) by e21.nc.us.ibm.com (8.9.3/8.9.3) with ESMTP id MAA21682 for ; Thu, 7 Dec 2000 12:14:26 -0600 Received: from d04nm200.raleigh.ibm.com (d04nm200.raleigh.ibm.com [9.67.228.37]) by southrelay02.raleigh.ibm.com (8.8.8m3/NCO v4.95) with ESMTP id MAA88450; Thu, 7 Dec 2000 12:16:45 -0500 Importance: Normal Subject: Re: [Diffserv] Degree of detail in the DiffServ MIB To: Brian E Carpenter Cc: "'diffserv@ietf.org'" X-Mailer: Lotus Notes Release 5.0.3 (Intl) 21 March 2000 Message-ID: From: "Robert Moore" Date: Thu, 7 Dec 2000 12:21:24 -0500 X-MIMETrack: Serialize by Router on D04NM200/04/M/IBM(Release 5.0.3 (Intl)|21 March 2000) at 12/07/2000 12:17:13 PM MIME-Version: 1.0 Content-type: text/plain; charset=us-ascii Sender: diffserv-admin@ietf.org Errors-To: diffserv-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Diffserv Discussion List X-BeenThere: diffserv@ietf.org Brian, I think that the WG question is a red herring here. The important question is whether the MIB and PIB need to have this level of detail. Whether they include it directly, or import it by reference from a document like QDDIM, is a secondary question. So why *wouldn't* you want this level of detail in the MIB and the PIB? I don't think it's because you want to leave vendors room to innovate in how they do DSCP marking. The only other argument I can think of is that the detail is unnecessary, i.e., that everybody will implement it correctly, even without the additional detail. Since we've had cases in the past where "obvious" things were interpreted, and thus implemented, in unexpected ways, my inclination is to err on the side of too much detail rather than too little. The additional detail doesn't hurt anything, and it might help. Regards, Bob Bob Moore IBM Networking Software +1-919-254-4436 remoore@us.ibm.com Brian E Carpenter @ietf.org on 12/07/2000 11:12:11 AM Sent by: diffserv-admin@ietf.org To: "'diffserv@ietf.org'" cc: Subject: Re: [Diffserv] Degree of detail in the DiffServ MIB I'd like opinions from diffservers whether the Policy WG is or is not getting into too much detail in this case. Brian Robert Moore wrote: > > Here is the DiffServ MIB's text describing the DSCP Mark Action Table: > > 3.4.1. DSCP Mark Action Table > > This Action is applied to traffic in order to mark it with a Diffserv > Codepoint (DSCP) value, specified in the diffServDscpMarkActTable. Other > marking actions might be specified elsewhere - these are outside the > scope of this MIB. > > And here is the text from QDDIM describing the property in > a DSCP marker that holds the DSCP value: > > 4.4.16.1 The Property DSCPValue > > This property is an unsigned 8-bit integer, representing a value to be > used for marking the DSCP within the DS field in an IPv4 or IPv6 packet > header. Since the DSCP consists of 6 bits, the values for this property > are limited to the range 0..63. When the DSCP is marked, the remaining > two bit in the DS field are left unchanged. > > Clearly there is an additional detail in the QDDIM version: > the statement that the remaining two bits are left unchanged. > (The range limitation 0..63 is handled in the MIB by the > Dscp Textual Convention (-1 | 0..63), combined with the > description text for the object, saying that the value -1 > is not allowed.) In the ordinary Policy Framework treatment > ("ordinary" based on one partially completed example of PCIM > and PCLS, but never mind that:-), this level of detail would > be documented in the Information Model (QDDIM in this case), > and then incorporated by reference into the Data Models (the > MIB and the PIB) derived from it. But in this case the Data > Models are much more mature, and thus closer to completion, > than the QDDIM. The only remaining alternatives are either > not to have the detail at all in the MIB and PIB, or else to > copy the QDDIM text into them. I vote for copying the text > in, because of past history of cases in which "everybody knows > what that means" being exposed as cases in which different > people "know" different things. > > I don't have a complete list, but I'm sure this is not the > only instance where the QDDIM has more detail than the two > diffserv Data Models. > > 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://www2.ietf.org/mail-archive/working-groups/diffserv/current/maillist.html _______________________________________________ diffserv mailing list diffserv@ietf.org http://www1.ietf.org/mailman/listinfo/diffserv Archive: http://www2.ietf.org/mail-archive/working-groups/diffserv/current/maillist.html From diffserv-admin@ietf.org Thu Dec 7 13: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 SMTP id NAA06641 for ; Thu, 7 Dec 2000 13:21:35 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id MAA11804; Thu, 7 Dec 2000 12:50:45 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id MAA11778 for ; Thu, 7 Dec 2000 12:50:41 -0500 (EST) Received: from mailhub1.almaden.ibm.com (mailhub1.almaden.ibm.com [198.4.83.44]) by ietf.org (8.9.1a/8.9.1a) with SMTP id MAA02265 for ; Thu, 7 Dec 2000 12:50:39 -0500 (EST) Received: from maui.almaden.ibm.com (maui.almaden.ibm.com [9.1.24.92]) by mailhub1.almaden.ibm.com (8.8.8/8.8.8) with ESMTP id JAA58402; Thu, 7 Dec 2000 09:49:03 -0800 Received: from hursley.ibm.com (gsine04.us.sine.ibm.com [9.14.6.44]) by maui.almaden.ibm.com (AIX4.3/8.9.3/8.7) with ESMTP id JAA20526; Thu, 7 Dec 2000 09:50:00 -0800 Message-ID: <3A2FCD69.E251FB39@hursley.ibm.com> Date: Thu, 07 Dec 2000 11:48:25 -0600 From: Brian E Carpenter Organization: IBM X-Mailer: Mozilla 4.61 [en] (Win98; I) X-Accept-Language: en,fr MIME-Version: 1.0 To: Robert Moore CC: "'diffserv@ietf.org'" Subject: Re: [Diffserv] Degree of detail in the DiffServ MIB 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 Bob, My question is explicitly about the level of detail in QDDIM. I don't understand why something called a policy model would even attempt to model or describe these details. It's a WG question because it creates a level of dependency of Policy documents on Diffserv documents that concerns me. I don't want to hear that we need to hold up Diffserv documents because of this dependency. It's intentional that we say nothing whatever about the Currently Unused bits in DiffServ documents. They don't belong to DiffServ so we should say nothing about them. Brian Robert Moore wrote: > > Brian, > > I think that the WG question is a red herring here. The > important question is whether the MIB and PIB need to have > this level of detail. Whether they include it directly, > or import it by reference from a document like QDDIM, is a > secondary question. > > So why *wouldn't* you want this level of detail in the MIB > and the PIB? I don't think it's because you want to leave > vendors room to innovate in how they do DSCP marking. The > only other argument I can think of is that the detail is > unnecessary, i.e., that everybody will implement it > correctly, even without the additional detail. Since we've > had cases in the past where "obvious" things were > interpreted, and thus implemented, in unexpected ways, > my inclination is to err on the side of too much detail > rather than too little. The additional detail doesn't hurt > anything, and it might help. > > Regards, > Bob > > Bob Moore > IBM Networking Software > +1-919-254-4436 > remoore@us.ibm.com > > Brian E Carpenter @ietf.org on 12/07/2000 11:12:11 > AM > > Sent by: diffserv-admin@ietf.org > > To: "'diffserv@ietf.org'" > cc: > Subject: Re: [Diffserv] Degree of detail in the DiffServ MIB > > I'd like opinions from diffservers whether the Policy WG is or is not > getting into too much detail in this case. > > Brian > > Robert Moore wrote: > > > > Here is the DiffServ MIB's text describing the DSCP Mark Action Table: > > > > 3.4.1. DSCP Mark Action Table > > > > This Action is applied to traffic in order to mark it with a Diffserv > > Codepoint (DSCP) value, specified in the diffServDscpMarkActTable. > Other > > marking actions might be specified elsewhere - these are outside the > > scope of this MIB. > > > > And here is the text from QDDIM describing the property in > > a DSCP marker that holds the DSCP value: > > > > 4.4.16.1 The Property DSCPValue > > > > This property is an unsigned 8-bit integer, representing a value to be > > used for marking the DSCP within the DS field in an IPv4 or IPv6 packet > > header. Since the DSCP consists of 6 bits, the values for this > property > > are limited to the range 0..63. When the DSCP is marked, the remaining > > two bit in the DS field are left unchanged. > > > > Clearly there is an additional detail in the QDDIM version: > > the statement that the remaining two bits are left unchanged. > > (The range limitation 0..63 is handled in the MIB by the > > Dscp Textual Convention (-1 | 0..63), combined with the > > description text for the object, saying that the value -1 > > is not allowed.) In the ordinary Policy Framework treatment > > ("ordinary" based on one partially completed example of PCIM > > and PCLS, but never mind that:-), this level of detail would > > be documented in the Information Model (QDDIM in this case), > > and then incorporated by reference into the Data Models (the > > MIB and the PIB) derived from it. But in this case the Data > > Models are much more mature, and thus closer to completion, > > than the QDDIM. The only remaining alternatives are either > > not to have the detail at all in the MIB and PIB, or else to > > copy the QDDIM text into them. I vote for copying the text > > in, because of past history of cases in which "everybody knows > > what that means" being exposed as cases in which different > > people "know" different things. > > > > I don't have a complete list, but I'm sure this is not the > > only instance where the QDDIM has more detail than the two > > diffserv Data Models. > > > > 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://www2.ietf.org/mail-archive/working-groups/diffserv/current/maillist.html _______________________________________________ diffserv mailing list diffserv@ietf.org http://www1.ietf.org/mailman/listinfo/diffserv Archive: http://www2.ietf.org/mail-archive/working-groups/diffserv/current/maillist.html From diffserv-admin@ietf.org Thu Dec 7 14:44: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 SMTP id OAA22870 for ; Thu, 7 Dec 2000 14:44:19 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id NAA12783; Thu, 7 Dec 2000 13:30:09 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id NAA12752 for ; Thu, 7 Dec 2000 13:30:05 -0500 (EST) Received: from e22.nc.us.ibm.com (e22.nc.us.ibm.com [32.97.136.228]) by ietf.org (8.9.1a/8.9.1a) with SMTP id NAA07694 for ; Thu, 7 Dec 2000 13:30:04 -0500 (EST) Received: from southrelay02.raleigh.ibm.com (southrelay02.raleigh.ibm.com [9.37.3.209]) by e22.nc.us.ibm.com (8.9.3/8.9.3) with ESMTP id NAA17340 for ; Thu, 7 Dec 2000 13:26:45 -0600 Received: from d04nm200.raleigh.ibm.com (d04nm200.raleigh.ibm.com [9.67.228.37]) by southrelay02.raleigh.ibm.com (8.8.8m3/NCO v4.95) with ESMTP id NAA97416; Thu, 7 Dec 2000 13:29:32 -0500 Importance: Normal Subject: Re: [Diffserv] Degree of detail in the DiffServ MIB To: Brian E Carpenter Cc: "'diffserv@ietf.org'" X-Mailer: Lotus Notes Release 5.0.3 (Intl) 21 March 2000 Message-ID: From: "Robert Moore" Date: Thu, 7 Dec 2000 13:30:29 -0500 X-MIMETrack: Serialize by Router on D04NM200/04/M/IBM(Release 5.0.3 (Intl)|21 March 2000) at 12/07/2000 01:30:00 PM MIME-Version: 1.0 Content-type: text/plain; charset=us-ascii Sender: diffserv-admin@ietf.org Errors-To: diffserv-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Diffserv Discussion List X-BeenThere: diffserv@ietf.org Brian, Part of the confusion here is that QDDIM is *not* a policy model, nor is it called one: its full name is "Information Model for Describing Network Device QoS Mechanisms for Differentiated Services." It came about as a result of two different impulses: 1. As a part of the Policy Framework WG's proof-of-concept "worked example," where we would show how to apply Core Policy to some specific domain. In this role it is a companion document to QPIM (which *is* a policy model), to let us illustrate the process by which a high-level policy gets mapped to lower-level device configuration. 2. In response to the desire for something more formal than "most of the authors overlap" to insure that the DiffServ MIB and PIB be consistent with each other. The Informal Model accomplishes this to some extent, but there has been interest in something more formal. This was part of the impetus behind NIM, which has now largely transferred over to SMIng. And it's the essence of what we have been doing in the Policy Framework WG: defining information models, which are then mapped to data models. By having a common starting point, it's guaranteed that the data models will all be consistent with each other. So that's what QDDIM is: the information model not for DiffServ policy, but for representing and configuring DiffServ mechanisms. Organizationally, we've got exactly the same question for information models that we had/have for MIBs, for PIBs, for LDAP schemas, for SMIng specifications, for...: who should define them -- the subject matter experts/WG, or a separate WG of experts in the particular modeling technology? As you know, there's no agreed-upon answer to this question. Two additional points: - I'm not in any way suggesting that you hold up the DiffServ documents -- just that the Diffserv WG consider updating then to reflect some of the things we did in QDDIM. - Given that DiffServ has no business touching the two Currently Unused bits, I'd *still* be more comfortable with an explicit statement that they're supposed to be left alone, rather than leaving it up to DiffServ implementers to reach this conclusion. Regards, Bob Bob Moore IBM Networking Software +1-919-254-4436 remoore@us.ibm.com Brian E Carpenter on 12/07/2000 12:48:25 PM To: Robert Moore/Raleigh/IBM@IBMUS cc: "'diffserv@ietf.org'" Subject: Re: [Diffserv] Degree of detail in the DiffServ MIB Bob, My question is explicitly about the level of detail in QDDIM. I don't understand why something called a policy model would even attempt to model or describe these details. It's a WG question because it creates a level of dependency of Policy documents on Diffserv documents that concerns me. I don't want to hear that we need to hold up Diffserv documents because of this dependency. It's intentional that we say nothing whatever about the Currently Unused bits in DiffServ documents. They don't belong to DiffServ so we should say nothing about them. Brian Robert Moore wrote: > > Brian, > > I think that the WG question is a red herring here. The > important question is whether the MIB and PIB need to have > this level of detail. Whether they include it directly, > or import it by reference from a document like QDDIM, is a > secondary question. > > So why *wouldn't* you want this level of detail in the MIB > and the PIB? I don't think it's because you want to leave > vendors room to innovate in how they do DSCP marking. The > only other argument I can think of is that the detail is > unnecessary, i.e., that everybody will implement it > correctly, even without the additional detail. Since we've > had cases in the past where "obvious" things were > interpreted, and thus implemented, in unexpected ways, > my inclination is to err on the side of too much detail > rather than too little. The additional detail doesn't hurt > anything, and it might help. > > Regards, > Bob > > Bob Moore > IBM Networking Software > +1-919-254-4436 > remoore@us.ibm.com > > Brian E Carpenter @ietf.org on 12/07/2000 11:12:11 > AM > > Sent by: diffserv-admin@ietf.org > > To: "'diffserv@ietf.org'" > cc: > Subject: Re: [Diffserv] Degree of detail in the DiffServ MIB > > I'd like opinions from diffservers whether the Policy WG is or is not > getting into too much detail in this case. > > Brian > > Robert Moore wrote: > > > > Here is the DiffServ MIB's text describing the DSCP Mark Action Table: > > > > 3.4.1. DSCP Mark Action Table > > > > This Action is applied to traffic in order to mark it with a Diffserv > > Codepoint (DSCP) value, specified in the diffServDscpMarkActTable. > Other > > marking actions might be specified elsewhere - these are outside the > > scope of this MIB. > > > > And here is the text from QDDIM describing the property in > > a DSCP marker that holds the DSCP value: > > > > 4.4.16.1 The Property DSCPValue > > > > This property is an unsigned 8-bit integer, representing a value to be > > used for marking the DSCP within the DS field in an IPv4 or IPv6 packet > > header. Since the DSCP consists of 6 bits, the values for this > property > > are limited to the range 0..63. When the DSCP is marked, the remaining > > two bit in the DS field are left unchanged. > > > > Clearly there is an additional detail in the QDDIM version: > > the statement that the remaining two bits are left unchanged. > > (The range limitation 0..63 is handled in the MIB by the > > Dscp Textual Convention (-1 | 0..63), combined with the > > description text for the object, saying that the value -1 > > is not allowed.) In the ordinary Policy Framework treatment > > ("ordinary" based on one partially completed example of PCIM > > and PCLS, but never mind that:-), this level of detail would > > be documented in the Information Model (QDDIM in this case), > > and then incorporated by reference into the Data Models (the > > MIB and the PIB) derived from it. But in this case the Data > > Models are much more mature, and thus closer to completion, > > than the QDDIM. The only remaining alternatives are either > > not to have the detail at all in the MIB and PIB, or else to > > copy the QDDIM text into them. I vote for copying the text > > in, because of past history of cases in which "everybody knows > > what that means" being exposed as cases in which different > > people "know" different things. > > > > I don't have a complete list, but I'm sure this is not the > > only instance where the QDDIM has more detail than the two > > diffserv Data Models. > > > > 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://www2.ietf.org/mail-archive/working-groups/diffserv/current/maillist.html _______________________________________________ diffserv mailing list diffserv@ietf.org http://www1.ietf.org/mailman/listinfo/diffserv Archive: http://www2.ietf.org/mail-archive/working-groups/diffserv/current/maillist.html From diffserv-admin@ietf.org Thu Dec 7 14:55:28 2000 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with SMTP id OAA24523 for ; Thu, 7 Dec 2000 14:55:28 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id OAA13831; Thu, 7 Dec 2000 14:05:12 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id OAA13800 for ; Thu, 7 Dec 2000 14:05:08 -0500 (EST) Received: from cisco.com (ups.cisco.com [171.69.18.21]) by ietf.org (8.9.1a/8.9.1a) with SMTP id OAA13786 for ; Thu, 7 Dec 2000 14:05:07 -0500 (EST) Received: (from kzm@localhost) by cisco.com (8.8.8/2.6/Cisco List Logging/8.8.8) id LAA02789; Thu, 7 Dec 2000 11:04:34 -0800 (PST) From: Keith McCloghrie Message-Id: <200012071904.LAA02789@cisco.com> Subject: Re: [Diffserv] Degree of detail in the DiffServ MIB To: brian@hursley.ibm.com (Brian E Carpenter) Date: Thu, 7 Dec 2000 11:04:34 -0800 (PST) Cc: remoore@us.ibm.com (Robert Moore), diffserv@ietf.org ('diffserv@ietf.org') In-Reply-To: <3A2FCD69.E251FB39@hursley.ibm.com> from "Brian E Carpenter" at Dec 07, 2000 11:48:25 AM X-Mailer: ELM [version 2.5 PL1] MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: diffserv-admin@ietf.org Errors-To: diffserv-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Diffserv Discussion List X-BeenThere: diffserv@ietf.org Content-Transfer-Encoding: 7bit I think the issue here is authoritative versus informational. The QDIM is obviously not authoritative on the definition of the DSCP field, but I think it could well be helpful for it to supply additional information. So, could the issue be resolve editorially, by having the QDDIM document refer to the source of the authoritative definition, as well as providing the additional information ?? Keith. > Bob, > > My question is explicitly about the level of detail in QDDIM. > I don't understand why something called a policy model would > even attempt to model or describe these details. It's a WG question > because it creates a level of dependency of Policy documents > on Diffserv documents that concerns me. I don't want to hear that > we need to hold up Diffserv documents because of this dependency. > > It's intentional that we say nothing whatever about the Currently > Unused bits in DiffServ documents. They don't belong to DiffServ so > we should say nothing about them. > > Brian > > Robert Moore wrote: > > > > Brian, > > > > I think that the WG question is a red herring here. The > > important question is whether the MIB and PIB need to have > > this level of detail. Whether they include it directly, > > or import it by reference from a document like QDDIM, is a > > secondary question. > > > > So why *wouldn't* you want this level of detail in the MIB > > and the PIB? I don't think it's because you want to leave > > vendors room to innovate in how they do DSCP marking. The > > only other argument I can think of is that the detail is > > unnecessary, i.e., that everybody will implement it > > correctly, even without the additional detail. Since we've > > had cases in the past where "obvious" things were > > interpreted, and thus implemented, in unexpected ways, > > my inclination is to err on the side of too much detail > > rather than too little. The additional detail doesn't hurt > > anything, and it might help. > > > > Regards, > > Bob > > > > Bob Moore > > IBM Networking Software > > +1-919-254-4436 > > remoore@us.ibm.com > > > > Brian E Carpenter @ietf.org on 12/07/2000 11:12:11 > > AM > > > > Sent by: diffserv-admin@ietf.org > > > > To: "'diffserv@ietf.org'" > > cc: > > Subject: Re: [Diffserv] Degree of detail in the DiffServ MIB > > > > I'd like opinions from diffservers whether the Policy WG is or is not > > getting into too much detail in this case. > > > > Brian > > > > Robert Moore wrote: > > > > > > Here is the DiffServ MIB's text describing the DSCP Mark Action Table: > > > > > > 3.4.1. DSCP Mark Action Table > > > > > > This Action is applied to traffic in order to mark it with a Diffserv > > > Codepoint (DSCP) value, specified in the diffServDscpMarkActTable. > > Other > > > marking actions might be specified elsewhere - these are outside the > > > scope of this MIB. > > > > > > And here is the text from QDDIM describing the property in > > > a DSCP marker that holds the DSCP value: > > > > > > 4.4.16.1 The Property DSCPValue > > > > > > This property is an unsigned 8-bit integer, representing a value to be > > > used for marking the DSCP within the DS field in an IPv4 or IPv6 packet > > > header. Since the DSCP consists of 6 bits, the values for this > > property > > > are limited to the range 0..63. When the DSCP is marked, the remaining > > > two bit in the DS field are left unchanged. > > > > > > Clearly there is an additional detail in the QDDIM version: > > > the statement that the remaining two bits are left unchanged. > > > (The range limitation 0..63 is handled in the MIB by the > > > Dscp Textual Convention (-1 | 0..63), combined with the > > > description text for the object, saying that the value -1 > > > is not allowed.) In the ordinary Policy Framework treatment > > > ("ordinary" based on one partially completed example of PCIM > > > and PCLS, but never mind that:-), this level of detail would > > > be documented in the Information Model (QDDIM in this case), > > > and then incorporated by reference into the Data Models (the > > > MIB and the PIB) derived from it. But in this case the Data > > > Models are much more mature, and thus closer to completion, > > > than the QDDIM. The only remaining alternatives are either > > > not to have the detail at all in the MIB and PIB, or else to > > > copy the QDDIM text into them. I vote for copying the text > > > in, because of past history of cases in which "everybody knows > > > what that means" being exposed as cases in which different > > > people "know" different things. > > > > > > I don't have a complete list, but I'm sure this is not the > > > only instance where the QDDIM has more detail than the two > > > diffserv Data Models. > > > > > > 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://www2.ietf.org/mail-archive/working-groups/diffserv/current/maillist.html > > _______________________________________________ > diffserv mailing list > diffserv@ietf.org > http://www1.ietf.org/mailman/listinfo/diffserv > Archive: http://www2.ietf.org/mail-archive/working-groups/diffserv/current/maillist.html > > _______________________________________________ diffserv mailing list diffserv@ietf.org http://www1.ietf.org/mailman/listinfo/diffserv Archive: http://www2.ietf.org/mail-archive/working-groups/diffserv/current/maillist.html From diffserv-admin@ietf.org Thu Dec 7 14:58:34 2000 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with SMTP id OAA24923 for ; Thu, 7 Dec 2000 14:58:34 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id OAA14048; Thu, 7 Dec 2000 14:18:11 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id OAA13947 for ; Thu, 7 Dec 2000 14:18:04 -0500 (EST) Received: from diablo.cisco.com (diablo.cisco.com [171.68.224.210]) by ietf.org (8.9.1a/8.9.1a) with SMTP id OAA17012 for ; Thu, 7 Dec 2000 14:18:03 -0500 (EST) Received: from jschnizl1-pc (jschnizl-isdn1.cisco.com [171.68.12.74]) by diablo.cisco.com (8.8.6 (PHNE_14041)/CISCO.SERVER.1.2) with SMTP id LAA02526; Thu, 7 Dec 2000 11:17:27 -0800 (PST) Message-Id: <4.1.20001207134402.00a3eef0@diablo.cisco.com> X-Sender: jschnizl@diablo.cisco.com X-Mailer: QUALCOMM Windows Eudora Pro Version 4.1 Date: Thu, 07 Dec 2000 14:17:34 -0500 To: "Robert Moore" , Brian E Carpenter From: John Schnizlein Subject: Re: [Diffserv] Degree of detail in the DiffServ MIB Cc: In-Reply-To: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: diffserv-admin@ietf.org Errors-To: diffserv-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Diffserv Discussion List X-BeenThere: diffserv@ietf.org There is a general problem with the degree of detail in various models for diffserv. Beyond the specification in RFC 2427, these details interfere with the creative flexibility in composing the blocks of functionality. [A1] For example, models appear to limit queuing and marking to various stages in the treatment of a packet. [Q3] It is useful to reflect principles from RFC 2474, such as the prohibition on masking DSCPs, in information models. At least DSCP mask values should not occur in these models. I see no reason to specify beyond the 64 possible integer values of a DSCP in the MIB or PIB [Q1]. In this particular case, the risk of implementers getting it wrong is small. [A2] The additional dependency of MIB or PIB documents on a QDDIM document (for information limited to what is in RFC 2474) would be bad [Q2]. Additional details in these models, especially if they are to be translated into management functions, are dangerous [A3] because they imply limitations on the use of diffserv concepts that are not intended in the standard. Especially as the information models, and data models derived from them, are translated into various database schema automatically, there is a risk that the non-standard details in the model become de facto parts of the standard. John At 12:21 PM 12/07/2000 -0500, Robert Moore wrote: > >The important question is whether the MIB and PIB need to >have this level of detail. ---> Q1 >Whether they include it directly, or import it by reference >from a document like QDDIM, is a secondary question. ---> Q2 > >So why *wouldn't* you want this level of detail in the >MIB and the PIB? ---> Q3 >I don't think it's because you want to leave >vendors room to innovate in how they do DSCP marking. ---> A1 >The only other argument I can think of is that the detail >is unnecessary, i.e., that everybody will implement it >correctly, even without the additional detail. ---> A2 >Since we've had cases in the past where "obvious" things >were interpreted, and thus implemented, in unexpected ways, >my inclination is to err on the side of too much detail >rather than too little. The additional detail doesn't hurt >anything, and it might help. ---> A3 >... >Brian E Carpenter on 12/07/2000 11:12:11 AM > >I'd like opinions from diffservers whether the Policy WG is or is not >getting into too much detail in this case. > > Brian > >Robert Moore wrote: >> >> Here is the DiffServ MIB's text describing the DSCP Mark Action Table: >> >> 3.4.1. DSCP Mark Action Table >> >> This Action is applied to traffic in order to mark it with a Diffserv >> Codepoint (DSCP) value, specified in the diffServDscpMarkActTable. >Other >> marking actions might be specified elsewhere - these are outside the >> scope of this MIB. >> >> And here is the text from QDDIM describing the property in >> a DSCP marker that holds the DSCP value: >> >> 4.4.16.1 The Property DSCPValue >> >> This property is an unsigned 8-bit integer, representing a value to be >> used for marking the DSCP within the DS field in an IPv4 or IPv6 packet >> header. Since the DSCP consists of 6 bits, the values for this >property >> are limited to the range 0..63. When the DSCP is marked, the remaining >> two bit in the DS field are left unchanged. >> >> Clearly there is an additional detail in the QDDIM version: >> the statement that the remaining two bits are left unchanged. >> (The range limitation 0..63 is handled in the MIB by the >> Dscp Textual Convention (-1 | 0..63), combined with the >> description text for the object, saying that the value -1 >> is not allowed.) In the ordinary Policy Framework treatment >> ("ordinary" based on one partially completed example of PCIM >> and PCLS, but never mind that:-), this level of detail would >> be documented in the Information Model (QDDIM in this case), >> and then incorporated by reference into the Data Models (the >> MIB and the PIB) derived from it. But in this case the Data >> Models are much more mature, and thus closer to completion, >> than the QDDIM. The only remaining alternatives are either >> not to have the detail at all in the MIB and PIB, or else to >> copy the QDDIM text into them. I vote for copying the text >> in, because of past history of cases in which "everybody knows >> what that means" being exposed as cases in which different >> people "know" different things. >> >> I don't have a complete list, but I'm sure this is not the >> only instance where the QDDIM has more detail than the two >> diffserv Data Models. _______________________________________________ diffserv mailing list diffserv@ietf.org http://www1.ietf.org/mailman/listinfo/diffserv Archive: http://www2.ietf.org/mail-archive/working-groups/diffserv/current/maillist.html From diffserv-admin@ietf.org Thu Dec 7 15:02: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 SMTP id PAA25446 for ; Thu, 7 Dec 2000 15:02:24 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id OAA14124; Thu, 7 Dec 2000 14:23:47 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id OAA14103 for ; Thu, 7 Dec 2000 14:23:44 -0500 (EST) Received: from procyon.pmc-sierra.bc.ca (procyon.pmc-sierra.bc.ca [134.87.115.1]) by ietf.org (8.9.1a/8.9.1a) with SMTP id OAA18540 for ; Thu, 7 Dec 2000 14:23:35 -0500 (EST) Received: from bby1exi01.pmc-sierra.bc.ca (bby1exi01.pmc-sierra.bc.ca [216.241.231.251]) by procyon.pmc-sierra.bc.ca (6.6.6/6.6.6) with ESMTP id KAA18865; Thu, 7 Dec 2000 10:20:42 -0800 (PST) Received: by bby1exi01.pmc-sierra.bc.ca with Internet Mail Service (5.5.2650.21) id ; Thu, 7 Dec 2000 10:21:09 -0800 Message-ID: <9DC5E2ABE65BD54CA9088DA3194461D6010C9ADC@BBY1EXM01> From: Shahram Davari To: "'Brian E Carpenter'" , Sylvain Gingras Cc: "'diffserv@ietf.org'" Subject: RE: [Diffserv] Re: I-D ACTION:draft-ietf-diffserv-model-05.txt (o n Metering) Date: Thu, 7 Dec 2000 10:21:08 -0800 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: text/plain Sender: diffserv-admin@ietf.org Errors-To: diffserv-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Diffserv Discussion List X-BeenThere: diffserv@ietf.org Hi Brian, Will IETF approve a document that has rough consensus but can be proved to have technical error? Yours, -Shahram > -----Original Message----- > From: Brian E Carpenter [mailto:brian@hursley.ibm.com] > Sent: Thursday, December 07, 2000 11:48 AM > To: Sylvain Gingras > Cc: 'diffserv@ietf.org' > Subject: Re: [Diffserv] Re: I-D > ACTION:draft-ietf-diffserv-model-05.txt > (on Metering) > > > I should say more or less what I've said to Shahram in private: > > I believe (without checking the archive) that we changed this > around in response to a clear majority view, knowing that some > people disagree, but the IETF works by rough consensus. When we > last call the document we by definition check the consensus > and then we will see. We can't re-debate every point of disagreement > on every draft. > > Brian > > Sylvain Gingras wrote: > > > > Regarding the discussion of the 'loose' and 'strict' token > buckets, I was also > > surprised at the unexplained and gradual shift away from > the conventional 'strict' > > token bucket policer in the latest versions of the text. > ... > > _______________________________________________ > diffserv mailing list > diffserv@ietf.org > http://www1.ietf.org/mailman/listinfo/diffserv > Archive: > http://www2.ietf.org/mail-archive/working-groups/diffserv/curr ent/maillist.html _______________________________________________ diffserv mailing list diffserv@ietf.org http://www1.ietf.org/mailman/listinfo/diffserv Archive: http://www2.ietf.org/mail-archive/working-groups/diffserv/current/maillist.html From diffserv-admin@ietf.org Thu Dec 7 15:08: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 SMTP id PAA26244 for ; Thu, 7 Dec 2000 15:08:49 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id OAA14416; Thu, 7 Dec 2000 14:39:34 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id OAA14385 for ; Thu, 7 Dec 2000 14:39:30 -0500 (EST) Received: from mta6.snfc21.pbi.net (mta6.snfc21.pbi.net [206.13.28.240]) by ietf.org (8.9.1a/8.9.1a) with SMTP id OAA22119 for ; Thu, 7 Dec 2000 14:39:29 -0500 (EST) Received: from allegronetworks.com ([206.170.1.27]) by mta6.snfc21.pbi.net (Sun Internet Mail Server sims.3.5.2000.01.05.12.18.p9) with ESMTP id <0G57002RTNTE7G@mta6.snfc21.pbi.net> for diffserv@ietf.org; Thu, 7 Dec 2000 10:39:17 -0800 (PST) Date: Thu, 07 Dec 2000 10:47:26 -0800 From: Andrew Smith Subject: Re: [Diffserv] Degree of detail in the DiffServ MIB To: Brian E Carpenter Cc: Robert Moore , "'diffserv@ietf.org'" Message-id: <3A2FDB3E.1010607@allegronetworks.com> Organization: Allegro Networks MIME-version: 1.0 Content-type: text/plain; charset=us-ascii; format=flowed Content-transfer-encoding: 7bit User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; m18) Gecko/20001108 Netscape6/6.0 X-Accept-Language: en References: <3A2FCD69.E251FB39@hursley.ibm.com> Content-Transfer-Encoding: 7bit Sender: diffserv-admin@ietf.org Errors-To: diffserv-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Diffserv Discussion List X-BeenThere: diffserv@ietf.org Content-Transfer-Encoding: 7bit I guess I'm a Diffserver, not a Policier. I think that the QDDIM text is too specific - this is a good example of a case where importing by reference rather than by value is a good thing. If you make sure that the reference is precise enough (e.g. find the right paragraph in the appropriate DS base RFC - BTW, that would be a good "REFERENCE" clause addition to the Dscp TC in the MIB) then you've done sufficient. In particular, the CU bits should not be referenced at all. I sympathise with the desire to include more detailed information, particularly in a machine-parsable form (e.g. a DESCRIPTION clause in a MIB), but that does a disservice when it can easily become out of date and yet it remains built in to the "Help" files of a management tool, for example. Andrew Smith Brian E Carpenter wrote: > Bob, > > My question is explicitly about the level of detail in QDDIM. > I don't understand why something called a policy model would > even attempt to model or describe these details. It's a WG question > because it creates a level of dependency of Policy documents > on Diffserv documents that concerns me. I don't want to hear that > we need to hold up Diffserv documents because of this dependency. > > It's intentional that we say nothing whatever about the Currently > Unused bits in DiffServ documents. They don't belong to DiffServ so > we should say nothing about them. > > Brian > > Robert Moore wrote: > >> Brian, >> >> I think that the WG question is a red herring here. The >> important question is whether the MIB and PIB need to have >> this level of detail. Whether they include it directly, >> or import it by reference from a document like QDDIM, is a >> secondary question. >> >> So why *wouldn't* you want this level of detail in the MIB >> and the PIB? I don't think it's because you want to leave >> vendors room to innovate in how they do DSCP marking. The >> only other argument I can think of is that the detail is >> unnecessary, i.e., that everybody will implement it >> correctly, even without the additional detail. Since we've >> had cases in the past where "obvious" things were >> interpreted, and thus implemented, in unexpected ways, >> my inclination is to err on the side of too much detail >> rather than too little. The additional detail doesn't hurt >> anything, and it might help. >> >> Regards, >> Bob >> >> Bob Moore >> IBM Networking Software >> +1-919-254-4436 >> remoore@us.ibm.com >> >> Brian E Carpenter @ietf.org on 12/07/2000 11:12:11 >> AM >> >> Sent by: diffserv-admin@ietf.org >> >> To: "'diffserv@ietf.org'" >> cc: >> Subject: Re: [Diffserv] Degree of detail in the DiffServ MIB >> >> I'd like opinions from diffservers whether the Policy WG is or is not >> getting into too much detail in this case. >> >> Brian >> >> Robert Moore wrote: >> >>> Here is the DiffServ MIB's text describing the DSCP Mark Action Table: >>> >>> 3.4.1. DSCP Mark Action Table >>> >>> This Action is applied to traffic in order to mark it with a Diffserv >>> Codepoint (DSCP) value, specified in the diffServDscpMarkActTable. >> >> Other >> >>> marking actions might be specified elsewhere - these are outside the >>> scope of this MIB. >>> >>> And here is the text from QDDIM describing the property in >>> a DSCP marker that holds the DSCP value: >>> >>> 4.4.16.1 The Property DSCPValue >>> >>> This property is an unsigned 8-bit integer, representing a value to be >>> used for marking the DSCP within the DS field in an IPv4 or IPv6 packet >>> header. Since the DSCP consists of 6 bits, the values for this >> >> property >> >>> are limited to the range 0..63. When the DSCP is marked, the remaining >>> two bit in the DS field are left unchanged. >>> >>> Clearly there is an additional detail in the QDDIM version: >>> the statement that the remaining two bits are left unchanged. >>> (The range limitation 0..63 is handled in the MIB by the >>> Dscp Textual Convention (-1 | 0..63), combined with the >>> description text for the object, saying that the value -1 >>> is not allowed.) In the ordinary Policy Framework treatment >>> ("ordinary" based on one partially completed example of PCIM >>> and PCLS, but never mind that:-), this level of detail would >>> be documented in the Information Model (QDDIM in this case), >>> and then incorporated by reference into the Data Models (the >>> MIB and the PIB) derived from it. But in this case the Data >>> Models are much more mature, and thus closer to completion, >>> than the QDDIM. The only remaining alternatives are either >>> not to have the detail at all in the MIB and PIB, or else to >>> copy the QDDIM text into them. I vote for copying the text >>> in, because of past history of cases in which "everybody knows >>> what that means" being exposed as cases in which different >>> people "know" different things. >>> >>> I don't have a complete list, but I'm sure this is not the >>> only instance where the QDDIM has more detail than the two >>> diffserv Data Models. >>> >>> 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://www2.ietf.org/mail-archive/working-groups/diffserv/current/maillist.html > > > _______________________________________________ > diffserv mailing list > diffserv@ietf.org > http://www1.ietf.org/mailman/listinfo/diffserv > Archive: http://www2.ietf.org/mail-archive/working-groups/diffserv/current/maillist.html _______________________________________________ diffserv mailing list diffserv@ietf.org http://www1.ietf.org/mailman/listinfo/diffserv Archive: http://www2.ietf.org/mail-archive/working-groups/diffserv/current/maillist.html From diffserv-admin@ietf.org Thu Dec 7 15:09:06 2000 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with SMTP id PAA26299 for ; Thu, 7 Dec 2000 15:09:06 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id OAA14549; Thu, 7 Dec 2000 14:44:41 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id OAA14520 for ; Thu, 7 Dec 2000 14:44:37 -0500 (EST) Received: from mta5.snfc21.pbi.net (mta5.snfc21.pbi.net [206.13.28.241]) by ietf.org (8.9.1a/8.9.1a) with SMTP id OAA22929 for ; Thu, 7 Dec 2000 14:44:35 -0500 (EST) Received: from allegronetworks.com ([206.170.1.27]) by mta5.snfc21.pbi.net (Sun Internet Mail Server sims.3.5.2000.01.05.12.18.p9) with ESMTP id <0G5700M87ONOX7@mta5.snfc21.pbi.net> for diffserv@ietf.org; Thu, 7 Dec 2000 10:57:26 -0800 (PST) Date: Thu, 07 Dec 2000 11:05:10 -0800 From: Andrew Smith To: Robert Moore Cc: diffserv@ietf.org, policy@raleigh.ibm.com Message-id: <3A2FDF66.9060505@allegronetworks.com> Organization: Allegro Networks MIME-version: 1.0 Content-type: text/plain; charset=us-ascii; format=flowed Content-transfer-encoding: 7bit User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; m18) Gecko/20001108 Netscape6/6.0 X-Accept-Language: en References: Content-Transfer-Encoding: 7bit Subject: [Diffserv] Re: Modeling of algorithmic droppers and queues Sender: diffserv-admin@ietf.org Errors-To: diffserv-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Diffserv Discussion List X-BeenThere: diffserv@ietf.org Content-Transfer-Encoding: 7bit Bob, OK, glad to see that someone actually reads the fine print - thanks! You caught the Model draft in an inconsistent state between it's prior use of Option 1 in -03 and earlier and the -04/-05 versions which use Option 2 for the Figure 5 diagram (a lot of the text and Section 8.2's example didn't get made consistent with Option 2 - that's my fault). But I'm now proposing we go back to the Option 1 formulation (see my Diffserv WG message "Model draft - model for algorithmic droppers" from 12/5, as well as subsequent discussion, for my reasoning). You said: > We can't place the > dropper after the queue -- both the Informal Model and > the MIB explicitly rule this out but, of course, we are at liberty to change these explicit statements if the WG so desires. For Option 1, you would have to allow the Algorithmic Dropper to go after the queue in order to represent Head Drop (those explicit statements, in the Model draft at least, *were* updated to match the Option 2 representation). Apologies for the inconsistency in the current Model draft text/figures. Andrew Smith (Model draft editor) Robert Moore wrote: > After reading through the -05 Informal Model, and comparing > it with the new -02 QDDIM, it appears that neither of us is > quite there yet on modeling the relationship between an > algorithmic dropper and a queue. There are (at least!) two > ways of modeling these two elements, and both documents > contain elements of both approaches. > > Option 1: an algorithmic dropper sits before its queue > in the data path, and based on what it sees in the > queue, it discards "packets that arrive at its input" > (Informal Model, p. 27). This is what the Informal Model > describes as the alternative it has chosen. It is the > basis for the NextService association in QDDIM and the > Next pointer in the -06 MIB, which show a progression > from -to-AlgorithmicDropper-to-queue. > > Option 2: an algorithmic dropper sits beside its queue, > outside the data path, and based on what it sees in the > queue, it discards packets "from the head, tail, or other > part of the associated queue" (Informal Model, p. 29). > Figure 5 in the Informal Model shows this interpretation > very clearly, and it's also represented in the QDDIM > by the HeadTailDropQueueBinding association. > > If we look at the example TCB in section 8.2 of the > informal model, we see that the droppers are all placed > before their associated queues, as Option 1 requires. > But they're also dropping from the tails of the queues, > which, given the picture, isn't too much of a stretch: > if the observed properties of the queue tell it to, > the dropper drops a packet that it's holding, rather > than putting it onto the tail of the queue. > > What would the picture look like if the dropping were > from the head of one of the queues? We can't place the > dropper after the queue -- both the Informal Model and > the MIB explicitly rule this out. The only picture > that works is the one for Option 2. But here the > dropper is plainly not dropping a packet that "arrives > at its input" -- it's dropping a packet from the head > of the queue. > > I'm not sure what's the best way to clarify all of this. > My inclination, though, would be to say that Option 2 > is the right way to think of this relationship, with > the *convention* that the chain of Next pointers / > NextService associations always goes > -->AlgorithmicDropper-->queue. > > I'm also wondering whether, in the QDDIM, we should > have made HeadTailDropQueueBinding a subclass of > NextService, This would embody the convention that > I just described, without requiring a separate NextService > association between the dropper and the queue, alongside > the HeadTailDropQueueBinding. (This assumes that the > queue that a HeadTailDropper monitors is always the > same one from which it causes packets to be dropped -- > I haven't seen anything to indicate that this is not > the case.) > > 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://www2.ietf.org/mail-archive/working-groups/diffserv/current/maillist.html From diffserv-admin@ietf.org Thu Dec 7 15:16:40 2000 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with SMTP id PAA27277 for ; Thu, 7 Dec 2000 15:16:40 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id OAA14768; Thu, 7 Dec 2000 14:56:59 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id OAA14740 for ; Thu, 7 Dec 2000 14:56:55 -0500 (EST) Received: from mta5.snfc21.pbi.net (mta5.snfc21.pbi.net [206.13.28.241]) by ietf.org (8.9.1a/8.9.1a) with SMTP id OAA24692 for ; Thu, 7 Dec 2000 14:56:54 -0500 (EST) Received: from allegronetworks.com ([206.170.1.27]) by mta5.snfc21.pbi.net (Sun Internet Mail Server sims.3.5.2000.01.05.12.18.p9) with ESMTP id <0G57008E0QEYHJ@mta5.snfc21.pbi.net> for diffserv@ietf.org; Thu, 7 Dec 2000 11:35:25 -0800 (PST) Date: Thu, 07 Dec 2000 11:43:09 -0800 From: Andrew Smith Subject: Re: [Diffserv] Model draft - sharing elements on multiple interfaces To: Robert Moore Cc: diffserv Message-id: <3A2FE84D.7040204@allegronetworks.com> Organization: Allegro Networks MIME-version: 1.0 Content-type: text/plain; charset=us-ascii; format=flowed Content-transfer-encoding: 7bit User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; m18) Gecko/20001108 Netscape6/6.0 X-Accept-Language: en References: Content-Transfer-Encoding: 7bit Sender: diffserv-admin@ietf.org Errors-To: diffserv-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Diffserv Discussion List X-BeenThere: diffserv@ietf.org Content-Transfer-Encoding: 7bit Bob, Without diving into the details for now, can we agree that, if the "ingress SLS shared over multiple interfaces" idea is interesting, then so is the *egress* one? Seems like some operations folks out there might be very interested in this .... no? (think: multi-tenant buildings, metro services?) Now diving into the details, the egress picture I would draw would be more like: +---------+ +----------+ | |i/f 1---\ | |--> i/f 1 | | \ |Another | |Routing |i/f 2----->meter-->|Routing |--> i/f 2 |Core | / |Core | | |i/f 3---/ | |--> i/f 3 +---------+ +----------+ It is of no business to the Diffserv elements how the traffic gets split back out to the interfaces on the r.h.s. so it is appropriate to model that function as a black box (in this Model document). A "Classifier" at that point is not the right functional block to perform the routing functions (which may be as simple as "do the same thing as the prior Routing Core did" - it's not our business to describe how it might do that). Andrew Robert Moore wrote: > Andrew, > > I'm still having trouble with the egress half of your > symmetric solution. Here's how I visualize your idea > of metering aggregated traffic across a set of egress > interfaces: > > +---------+ +----------+ > | |i/f 1---\ | |--> i/f 1 > | | \ | | > |Routing |i/f 2----->meter-->|classifier|--> i/f 2 > |Core | / | | > | |i/f 3---/ | |--> i/f 3 > +---------+ +----------+ > > In words, the Routing Core does whatever it does to > route packets (which is *outside* the scope of > DiffServ), and for each packet selects egress i/f > 1, 2, or 3. The data paths for these three egress > interfaces then merge into a single meter, to > provide the metering for the aggregated traffic. > The meter is followed by a classifier, which fans > the packets back out to their respective interfaces > for queueing, scheduling, etc. > > It's the classifier that I don't understand. If the > Routing Core selects an egress interface for a packet > based on routing criteria that are outside the scope of > DiffServ, then how can the classifier get each packet > back to the correct interface? What is it filtering > on? It can't base its decision on which interface > the packet traversed just before the meter, because > the model stipulates that a packet doesn't "remember" > where it has been. > > Do you have a different way of thinking about this > situation, one that doesn't run into this problem? > > Regards, > Bob > > Bob Moore > IBM Networking Software > +1-919-254-4436 > remoore@us.ibm.com > > > > Andrew Smith on 12/06/2000 01:38:08 PM > > To: Robert Moore/Raleigh/IBM@IBMUS > cc: diffserv > Subject: Re: [Diffserv] Model draft - sharing elements on multiple > interfaces > > > > Bob, > > I think you're trying to craft a compromise with Keith here but what you > propose > is inconsistent. [Note that I didn't mention the MIB in my message: the MIB > can > implement a subset of the model if it so chooses, so long as it is not > inconsistent with the model, but that's not the point I raised - by all > means > discuss the impact of this issue on the MIB in a separate thread but don't > let > that confuse this discussion of the model]. > > The point in question is whether "shared-between-multiple-interfaces" > elements > are both (a) useful for implementing specific services and (b) likely to be > implemented by more than one vendor and (c) without this change, does it > make it > impossible/unlikely that the model can be used to represent a significant > set of > devices? I believe that, for (a), the model needs to be symmetric: if such > a > service is useful for "in" then it is also for "out" e.g. metering on a > collection of interfaces representing one customer is just as useful in > both > directions. As regards (b), I'd like to hear some more opinions: so far the > exit > poll (3 opinions) seems to read: > > In? Out? > Y/N Y/N > 2/1 1/2 > > (if that notation makes sense). And for (c) I'm not sure we have any data > points. > > > Andrew > > > Robert Moore wrote: > > >> Keith, >> >> If I'm understanding you correctly, then I think I agree >> with you. We can allow the sharing of conditioning >> elements in the ingress case, but continue to rule it out >> for egress. This covers a case like a single meter that >> processes traffic aggregated from several ingress >> interfaces, which seems like something we want to allow. >> But it doesn't complicate the MIB in the egress case. >> >> If we allow sharing of conditioning elements for ingress >> interfaces, I think there are two cases that need to be >> mentioned in the MIB: >> >> - Two DataPathStart pointers pointing to the same >> element. If we leave it at that, we have no answer >> to the question "Which data path is the element >> *really* on?" But I think this is OK -- we can >> say that it's equally on both data paths. >> - A "next" pointer in a conditioning element pointing >> to a next conditioning element on a different >> data path. >> >> The MIB would also have to say clearly that these two >> options are *not* allowed for egress data paths. >> >> For Andrew's picture, I think it would be fine to >> combine the new version for the ingress side with the >> old version for the egress side. >> >> Does this sound good to everybody? >> >> Regards, >> Bob >> >> Bob Moore >> IBM Networking Software >> +1-919-254-4436 >> remoore@us.ibm.com >> >> >> >> Keith McCloghrie @ietf.org on 12/05/2000 05:19:33 PM >> >> Sent by: diffserv-admin@ietf.org >> >> >> To: Robert Moore/Raleigh/IBM@IBMUS >> cc: kzm@cisco.com (Keith McCloghrie), andrew@allegronetworks.com > > (Andrew > >> Smith), diffserv@ietf.org (diffserv) >> Subject: Re: [Diffserv] Model draft - sharing elements on multiple >> interfaces >> >> >> >> Bob, >> >> I was arguing against additional complexity, which was what I believed >> would ensue from Andrew's proposed change from: >> >> >> >>>> -> I -> core -> E -> >>>> >>>> The proposal would be to modify this to something like: >>>> >>>> -> I -+-> I -> core -> E -+-> E -> >>>> | | >>>> -> I -+ +-> E -> >>> >> I think it would be possible to allow merging on ingress just by >> removing the restriction on two data paths merging, which is stated >> in this ASN.1 comment (I think that's the only place it's specified): >> >> -- The use of next pointer to point to diffserv functional datapath >> -- element of a different datapath is not allowed >> >> I agree it's harder for egress which requries splitting, for which >> I think the current MIB structure is insufficient, and my concern is >> that a MIB structure which would allow it is going to be more complex. >> >> Keith. >> >> >> >> >>> Keith, >>> >>> I'm not sure what you're arguing for here. At least >>> on the ingress side, sharing an element (say a >>> Classifier) between two ingress interfaces amounts >>> to having the dataPathStart pointers for two entries >>> in the dataPathTable point to the same entry in the >>> diffServClassifier table. Are you saying that the MIB >>> currently rules this out? If so, I've missed it. Or >>> are you saying that while the MIB doesn't currently >>> rule it out, it should be changed so that it does? >>> >>> It's a little harder to describe for egress, but I >>> think the idea would be that two Data Paths start out >>> together, but then somehow diverge before they're done. >>> I'm not sure exactly how to express this in terms of >>> the Next pointers, but the same question I asked you >>> above applies here as well: do you think that the MIB >>> currently does outlaw this setup, or do you think that >>> it should (but doesn't now)? >>> >>> Thanks. >>> >>> 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://www2.ietf.org/mail-archive/working-groups/diffserv/current/maillist.html From diffserv-admin@ietf.org Thu Dec 7 15:26:28 2000 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with SMTP id PAA29174 for ; Thu, 7 Dec 2000 15:26:28 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id PAA15102; Thu, 7 Dec 2000 15:06:06 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id PAA15070 for ; Thu, 7 Dec 2000 15:06:01 -0500 (EST) Received: from zrtps06s.us.nortel.com (h50s48a140n47.user.nortelnetworks.com [47.140.48.50]) by ietf.org (8.9.1a/8.9.1a) with SMTP id PAA25855 for ; Thu, 7 Dec 2000 15:06:00 -0500 (EST) Message-Id: <200012072006.PAA25855@ietf.org> Received: from zbl6c016.corpeast.baynetworks.com by zrtps06s.us.nortel.com; Thu, 7 Dec 2000 14:51:39 -0500 Received: from zbl6c002.corpeast.baynetworks.com ([132.245.205.52]) by zbl6c016.corpeast.baynetworks.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2652.39) id W8KSPZ9Z; Thu, 7 Dec 2000 14:51:30 -0500 Received: from tweedy (dhcp223-142.engeast.baynetworks.com [192.32.223.142]) by zbl6c002.corpeast.baynetworks.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2652.39) id YJ8X7YLM; Thu, 7 Dec 2000 14:51:30 -0500 X-Sender: khchan@zbl6c002.corpeast.baynetworks.com X-Mailer: QUALCOMM Windows Eudora Pro Version 4.0 Date: Thu, 07 Dec 2000 14:50:13 -0500 To: "Iliff, Tina" X-Sybari-Space: 00000000 00000000 00000000 From: "Kwok-Ho Chan" Subject: RE: [Diffserv] diffsev-pib-02: qosQSchdParam Cc: "Kwok-Ho Chan" , "'diffserv@ietf.org'" In-Reply-To: <492EB4A3F68CD411ABE800508B69362E14B3D1@RIPEXCH002.wcomnet. com> Mime-Version: 1.0 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable X-Orig: Content-Transfer-Encoding: quoted-printable Sender: diffserv-admin@ietf.org Errors-To: diffserv-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Diffserv Discussion List X-BeenThere: diffserv@ietf.org Content-Transfer-Encoding: quoted-printable Tina:
If we remove SchdParam attribute from qosQ, then you are proposing moving
the MinRate and MaxRate parameters from SchdParam Table entry into qosQ
also.  Correct?  Functionally, what will this achieve?

One can say that Priority is a characteristic of a specific queue that is used
by the scheduler to perform scheduling functionality.  And the priority for each
queue is a relative characteristic with respect to all the other queues serviced
by the same scheduler.
-- Kwok --


At 09:11 PM 12/6/00 +0000, Iliff, Tina wrote:
Kwok,
=A0
I understand the "Fan-In" concept and architecture.=A0 However, how about considering this suggestion:=A0 add a priority attribute to qosQ, remove the SchdParam attribute and remove the priority attribute from qosSchdParam since priority is a Queue specific "tag" and not Scheduler specific.
=A0
Tina
-----Original Message-----
From: Kwok-Ho Chan [mailto:khchan@nortelnetworks.com]
Sent: Wednesday, December 06, 2000 1:28 PM
To: Iliff, Tina
Cc: 'diffserv@ietf.org'
Subject: Re: [Diffserv] diffsev-pib-02: qosQSchdParam
Tina:
Because a scheduler is a "Fan-In" element, many input, single output;
the queues that fan-into a scheduler will each need a SchdParam entry
to specify its scheduling order with respect to the other queues that feed
into the same scheduler.
It is also possible to have scheduler feeding into scheduler, hence the
SchdParam entry associated with a scheduler entry.
Hope this clear things up for you, please let me know.
-- Kwok --

At 04:37 PM 12/6/00 +0000, Iliff, Tina wrote:

All,

I have a concern regarding the structure of the qosQ table.=A0 It contains an attribute named SchdParam which provides the parameters used by the scheduler element for this particular queue.=A0 My concern is that there is also a SchdParam attribute in the qosScheduler table.=A0 It makes more sense to leave the parameter in the qosScheduler table and not in the qosQ table.=A0 It seems it is a duplication of information.
Tina Iliff

_______________________________________________ diffserv mailing list diffserv@ietf.org http://www1.ietf.org/mailman/listinfo/diffserv Archive: http://www2.ietf.org/mail-archive/working-groups/diffserv/current/maillist.html From diffserv-admin@ietf.org Thu Dec 7 15:45: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 SMTP id PAA03058 for ; Thu, 7 Dec 2000 15:45:40 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id PAA15580; Thu, 7 Dec 2000 15:25:46 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id PAA15549 for ; Thu, 7 Dec 2000 15:25:42 -0500 (EST) Received: from mta5.snfc21.pbi.net (mta5.snfc21.pbi.net [206.13.28.241]) by ietf.org (8.9.1a/8.9.1a) with SMTP id PAA28992 for ; Thu, 7 Dec 2000 15:25:40 -0500 (EST) Received: from allegronetworks.com ([206.170.1.27]) by mta5.snfc21.pbi.net (Sun Internet Mail Server sims.3.5.2000.01.05.12.18.p9) with ESMTP id <0G57008G2QV89M@mta5.snfc21.pbi.net> for diffserv@ietf.org; Thu, 7 Dec 2000 11:45:10 -0800 (PST) Date: Thu, 07 Dec 2000 11:52:55 -0800 From: Andrew Smith To: Robert Moore Cc: "'diffserv@ietf.org'" , policy@raleigh.ibm.com Message-id: <3A2FEA97.7040705@allegronetworks.com> Organization: Allegro Networks MIME-version: 1.0 Content-type: text/plain; charset=us-ascii; format=flowed Content-transfer-encoding: 7bit User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; m18) Gecko/20001108 Netscape6/6.0 X-Accept-Language: en References: Content-Transfer-Encoding: 7bit Subject: [Diffserv] Re: DSCP marking versus DSCP remarking Sender: diffserv-admin@ietf.org Errors-To: diffserv-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Diffserv Discussion List X-BeenThere: diffserv@ietf.org Content-Transfer-Encoding: 7bit I'm slightly confused as to whether I need to change anything in the Model draft here: I think, to paraphrase Brian's answer, that there *is* such a thing, conceptually, as an unmarked packet. You can tell, by implicit context, whether a packet is or is not already "marked" (it's a "policy" or "trust" thing, in the abstract sense of those terms). Do I have this right? Andrew Smith (Diffserv Model draft editor) Robert Moore wrote: > In the DiffServ Informal Model, MIB, and PIB, there > is a distinction drawn between a marker that marks > unmarked packets, and one that remarks packets that > had been marked previously. This distinction appears > most clearly in section 6.1 of the Informal Model. > The MIB and the PIB make it implicitly, by importing > the terms "mark" and "remark" from the Informal Model. > This distinction presupposes that among the packets > coming into a marker, some can be identified as > already marked, and others can be identified as > unmarked. I don't believe that this is the case. > > In QDDIM, we have come down squarely on the side that > says there is no such thing as an unmarked packet, and > thus no distinction between packet marking and packet > remarking. Every packet has one of 64 values, decimal > 0 - 63, in the DSCP field. Each of these values, > including 0, is a legitimate DSCP. So a DSCP marker > always takes in a packet that is already marked with a > DSCP, and marks (or remarks - which word we choose isn't > important) the packet with another DSCP, which may or > may not be the same DSCP as the one the packet had > when it came into the marker. Based on this view, we > removed from the MarkerService class in QDDIM a boolean > property CanRemark, which said whether a marker was > allowed to mark all packets, or only packets that were > not already marked when they got to it. > > This is *almost* just a question of wordsmithing in the > three diffserv WG documents. But not quite. If there is > actual disagreement in the WG about whether there is such > a thing as an unmarked packet, that is, a packet that's > not marked with any DSCP, then the question should be > discussed until the WG reaches a consensus one way or the > other. Does everybody agree with the QDDIM team that > there is no such thing as a packet unmarked with any DSCP? > > 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://www2.ietf.org/mail-archive/working-groups/diffserv/current/maillist.html From diffserv-admin@ietf.org Thu Dec 7 16:08: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 SMTP id QAA05973 for ; Thu, 7 Dec 2000 16:08:59 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id PAA16057; Thu, 7 Dec 2000 15:47:07 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id PAA16026 for ; Thu, 7 Dec 2000 15:47:03 -0500 (EST) Received: from diablo.cisco.com (diablo.cisco.com [171.68.224.210]) by ietf.org (8.9.1a/8.9.1a) with SMTP id PAA03219 for ; Thu, 7 Dec 2000 15:47:01 -0500 (EST) Received: from jschnizl1-pc (jschnizl-isdn1.cisco.com [171.68.12.74]) by diablo.cisco.com (8.8.6 (PHNE_14041)/CISCO.SERVER.1.2) with SMTP id MAA21363 for ; Thu, 7 Dec 2000 12:46:15 -0800 (PST) Message-Id: <4.1.20001207153949.00c69960@diablo.cisco.com> X-Sender: jschnizl@diablo.cisco.com X-Mailer: QUALCOMM Windows Eudora Pro Version 4.1 Date: Thu, 07 Dec 2000 15:46:22 -0500 To: diffserv@ietf.org From: John Schnizlein Subject: RE: [Diffserv] Re: I-D ACTION:draft-ietf-diffserv-model-05.txt (on Metering) In-Reply-To: <9DC5E2ABE65BD54CA9088DA3194461D6010C9ADC@BBY1EXM01> 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 10:21 AM 12/07/2000 -0800, Shahram Davari wrote: > >Will IETF approve a document that has rough consensus >but can be proved to have technical error? Clarification from the back row: In the IETF all we have is rough consensus. Rough consensus is what we accept as proof. The role of the chair is to report the fact (or not) of the consensus view, not to evaluate the correctness of a proof. The assumption is that the participants can tell what is true from what is not. Occasionally we need things explained. John _______________________________________________ diffserv mailing list diffserv@ietf.org http://www1.ietf.org/mailman/listinfo/diffserv Archive: http://www2.ietf.org/mail-archive/working-groups/diffserv/current/maillist.html From diffserv-admin@ietf.org Thu Dec 7 16:13: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 SMTP id QAA06761 for ; Thu, 7 Dec 2000 16:13:04 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id PAA16250; Thu, 7 Dec 2000 15:54:05 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id PAA16119 for ; Thu, 7 Dec 2000 15:53:55 -0500 (EST) Received: from mta6.snfc21.pbi.net (mta6.snfc21.pbi.net [206.13.28.240]) by ietf.org (8.9.1a/8.9.1a) with SMTP id PAA04054 for ; Thu, 7 Dec 2000 15:53:53 -0500 (EST) Received: from allegronetworks.com ([206.170.1.27]) by mta6.snfc21.pbi.net (Sun Internet Mail Server sims.3.5.2000.01.05.12.18.p9) with ESMTP id <0G5700A1IR8GR1@mta6.snfc21.pbi.net> for diffserv@ietf.org; Thu, 7 Dec 2000 11:53:06 -0800 (PST) Date: Thu, 07 Dec 2000 12:01:17 -0800 From: Andrew Smith Subject: Re: [Diffserv] Model draft - model for algorithmic droppers To: "Weiss, Walter" Cc: diffserv Message-id: <3A2FEC8D.4090800@allegronetworks.com> Organization: Allegro Networks MIME-version: 1.0 Content-type: text/plain; charset=us-ascii; format=flowed Content-transfer-encoding: 7bit User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; m18) Gecko/20001108 Netscape6/6.0 X-Accept-Language: en References: Content-Transfer-Encoding: 7bit Sender: diffserv-admin@ietf.org Errors-To: diffserv-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Diffserv Discussion List X-BeenThere: diffserv@ietf.org Content-Transfer-Encoding: 7bit Walter - good points, all of them. I'm not quite comfortable with a "MUST" there though - I wouldn't want to prejudice what ECN or some other congestion control algorithms might say about binding back to the same queue. But some additional text there would be a good thing. Andrew Weiss, Walter wrote: > Andrew, > > > The example diagram (for a tail dropper), replacing current > > figure 5, would then be: > > > > +----------------+ +-----------+ > > | +-------+ | n |smoothing | > > | |trigger|<------/--|function(s)| > > | |alg. | | |(optional) | > > | +-------+ | +-----------+ > > | | | ^ > > | v | |Depth > > Input | +-------+ no | ------------+ to next > > ---------->|action |-----------> |x|x|x|x|-------> > > | | ? | | ------------+ e.g. Scheduler > > | +-------+ | FIFO > > +------|---------+ > > Algorithmic |yes > > Dropper v > > +------+ > > |Next |e.g. AbsDrop,Mark > > |Action| > > +------+ > > > I like this picture better than the previous version. However, I have a > couple of observations. First, there is a fairly lengthy discussion of > queuing blocks (algorithmic droppers, queues, and schedulers) and the > relationships between them. When you seperate the drop function from the > triggering function, you introduce the possibility if an action in the > middle of queuing block, creating a number of inconsistencies in this > portion of the text. It may be helpful to add some additional text > recognizing that a Marking action would (MUST?) be bound back to the > same FIFO as the no path. > > > This still leaves the problem of the name: everybody seems to > > complain about > > "Algorithmic Dropper" but nobody has/had a better name. And > > now it can do things > > other than Drop. How about "Algorithmic", "Algorithmic > > Element", "Algorithmic > > Trigger", "Trigger Condition", "Trigger Element" or "Trigger > > Action"? Vote early > > and often (assuming you like the proposed revision of course). > > Whatever this new block does, it will now have to be defined as a > logically seperate block. Staying with the theme of other terms > (Classifier, Meter, Dropper, etc.) I am fine with the term "Trigger". > > regards, > > -Walter _______________________________________________ diffserv mailing list diffserv@ietf.org http://www1.ietf.org/mailman/listinfo/diffserv Archive: http://www2.ietf.org/mail-archive/working-groups/diffserv/current/maillist.html From diffserv-admin@ietf.org Thu Dec 7 16:13: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 SMTP id QAA06946 for ; Thu, 7 Dec 2000 16:13:45 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id PAA16260; Thu, 7 Dec 2000 15:54:06 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id PAA16117 for ; Thu, 7 Dec 2000 15:53:54 -0500 (EST) Received: from mta6.snfc21.pbi.net (mta6.snfc21.pbi.net [206.13.28.240]) by ietf.org (8.9.1a/8.9.1a) with SMTP id PAA04053 for ; Thu, 7 Dec 2000 15:53:53 -0500 (EST) Received: from allegronetworks.com ([206.170.1.27]) by mta6.snfc21.pbi.net (Sun Internet Mail Server sims.3.5.2000.01.05.12.18.p9) with ESMTP id <0G57007BLREGWW@mta6.snfc21.pbi.net> for diffserv@ietf.org; Thu, 7 Dec 2000 11:56:42 -0800 (PST) Date: Thu, 07 Dec 2000 12:04:54 -0800 From: Andrew Smith Subject: Re: [Diffserv] Model draft - sharing elements on multiple interfaces To: Brian E Carpenter Cc: diffserv Message-id: <3A2FED66.2020800@allegronetworks.com> Organization: Allegro Networks MIME-version: 1.0 Content-type: text/plain; charset=us-ascii; format=flowed Content-transfer-encoding: 7bit User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; m18) Gecko/20001108 Netscape6/6.0 X-Accept-Language: en References: <200012052219.OAA22003@cisco.com> <3A2FBBE4.58F0DF4D@hursley.ibm.com> Content-Transfer-Encoding: 7bit Sender: diffserv-admin@ietf.org Errors-To: diffserv-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Diffserv Discussion List X-BeenThere: diffserv@ietf.org Content-Transfer-Encoding: 7bit Brian, That almost works. We'd still have to fix up several places where it is implied that elements are scoped to a single interface. I think we ought only explicitly to include the more complex model if there are people who really want it in there - and I'm not hearing any public calls to do so at present. However, if the MIB (or PIB or QDIM or ...) explicitly permits this sharing then I think a "does not exclude" disclaimer is not sufficient and it should be "included" explicitly in the Model. That is the only way to be consistent about a "specific standards-track instantiations may implement subsets of the Model but they shouldn't add new stuff" policy for this set of documents. Andrew Brian E Carpenter wrote: > How about covering this by a text note in the document, not by > drawing the picture. > > "this model does not exclude the sharing of elements by more than > one ingress, or even by more than one egress, but this is not > explicitly modelled by the current document." > > Brian > _______________________________________________ diffserv mailing list diffserv@ietf.org http://www1.ietf.org/mailman/listinfo/diffserv Archive: http://www2.ietf.org/mail-archive/working-groups/diffserv/current/maillist.html From diffserv-admin@ietf.org Thu Dec 7 16:26: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 SMTP id QAA09709 for ; Thu, 7 Dec 2000 16:26:18 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id QAA16675; Thu, 7 Dec 2000 16:06:46 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id QAA16650 for ; Thu, 7 Dec 2000 16:06:42 -0500 (EST) Received: from mta6.snfc21.pbi.net (mta6.snfc21.pbi.net [206.13.28.240]) by ietf.org (8.9.1a/8.9.1a) with SMTP id QAA05698 for ; Thu, 7 Dec 2000 16:06:42 -0500 (EST) Received: from allegronetworks.com ([206.170.1.27]) by mta6.snfc21.pbi.net (Sun Internet Mail Server sims.3.5.2000.01.05.12.18.p9) with ESMTP id <0G570040KPV7RC@mta6.snfc21.pbi.net> for diffserv@ietf.org; Thu, 7 Dec 2000 11:23:33 -0800 (PST) Date: Thu, 07 Dec 2000 11:31:44 -0800 From: Andrew Smith Subject: Re: [Diffserv] Model draft - model for algorithmic droppers To: Robert Moore Cc: diffserv Message-id: <3A2FE5A0.3060006@allegronetworks.com> Organization: Allegro Networks MIME-version: 1.0 Content-type: text/plain; charset=us-ascii; format=flowed Content-transfer-encoding: 7bit User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; m18) Gecko/20001108 Netscape6/6.0 X-Accept-Language: en References: Content-Transfer-Encoding: 7bit Sender: diffserv-admin@ietf.org Errors-To: diffserv-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Diffserv Discussion List X-BeenThere: diffserv@ietf.org Content-Transfer-Encoding: 7bit Bob, I'm not sure it needs to be thought of in this way: I think of the dropper as something fairly stateless in the data plane, at least as far as not needing it to "contain a packet" for any finite length of time. We can describe the tail-dropper as "as the packet arrives at its input .... drop it or allow it through to the follwing element (e.g. the FIFO)" without needing to have the last FIFO position inside the dropper. Similarly for head-drop: "as the packet is removed from the FIFO .... drop it or allow the it through to the next element (e.g. a scheduler)" without the first FIFO position needing to be "in the dropper". I agree with you that it would be too clumsy if that were needed. Agree about amending the "canonical" rules. Andrew Robert Moore wrote: > I also raised questions related to this topic on the list, > last Friday. Interestingly, I concluded that the existing > Figure 5 gave the more useful view. The problem I have with > the direction you're proposing now is not the picture, but > the words that you use to describe the operation of an > algorithmic dropper. In trying to emphasize its similarity > with other conditioning elements, you say that a dropper makes > a drop decision on a packet that "arrive[s] at its input." > But I see a difference between dropping a packet that's "in" > the dropper, and dropping a packet that's sitting at some > specified position in a queue (which is a different > conditioning element). The only way to make it right, and I'm > *not* going to try to draw this, would be to say that when > there's a tail dropper involved, the last position in the > queue is *in* the tail dropper, rather than in the queue > object. Similarly, a head dropper would contain the first > position in the queue. With this arrangement, putting a > packet onto the tail of a queue would be identical to having > it arrive at the tail dropper's input. And moving up from > position 2 to position 1 in a queue would be identical to > arriving at the head dropper's input. > > I don't like this formulation at all: it's ugly to have > the queue element represent most, but not quite all, of the > positions in a queue. And the "next" associations between > a tail dropper and its queue, and between a queue and its > head dropper, become very different from the other "next" > associations in the model. But if you're going to put the > algorithmic droppers in the data path, and if you're going > to say that they act on packets that arrive at their inputs, > then I think you have to say something like this. > > A somewhat independent point: if you're going to represent > head droppers in the way you propose, then you're going to > have to amend the "canonical" orders of conditioning elements > in a queuing block and in a TCB. In both cases these > canonical orders exclude the case of a queue followed > immediately by an algorithmic dropper. > > Regards, > Bob _______________________________________________ diffserv mailing list diffserv@ietf.org http://www1.ietf.org/mailman/listinfo/diffserv Archive: http://www2.ietf.org/mail-archive/working-groups/diffserv/current/maillist.html From diffserv-admin@ietf.org Thu Dec 7 16:29: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 SMTP id QAA10422 for ; Thu, 7 Dec 2000 16:29:37 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id QAA16715; Thu, 7 Dec 2000 16:06:57 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id QAA16685 for ; Thu, 7 Dec 2000 16:06:52 -0500 (EST) Received: from bor.ellacoya.com (216-064-109-139.inaddr.vitts.com [216.64.109.139]) by ietf.org (8.9.1a/8.9.1a) with SMTP id QAA05717 for ; Thu, 7 Dec 2000 16:06:51 -0500 (EST) Received: by BOR with Internet Mail Service (5.5.2650.21) id ; Thu, 7 Dec 2000 15:59:39 -0500 Message-ID: From: "Weiss, Walter" To: "'diffserv'" Subject: RE: [Diffserv] Model draft - sharing elements on multiple interfa ces Date: Thu, 7 Dec 2000 15:59:35 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C06090.9C7E0CBC" Sender: diffserv-admin@ietf.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_01C06090.9C7E0CBC Content-Type: text/plain; charset="ISO-8859-1" Andrew, To your first question, I think it is important to support the ability to aggregate multiple interfaces to a single forwarding engine since I know many implementations that work this way. However, the question of symmetry struck a stronger cord with me. In your alternate picture: > -> I -+-> I -> core -> E -+-> E -> > | | > -> I -+ +-> E -> It struck me that the egress is a bit more odd because I am struggling to figure out what a fan-out on the egress means. Do you have a use case in mind? Is this describing a possible scenario where for example a classifier is selecting between multiple interfaces? regards, -Walter > -----Original Message----- > From: Andrew Smith [mailto:andrew@allegronetworks.com] > Sent: Wednesday, December 06, 2000 1:38 PM > To: Robert Moore > Cc: diffserv > Subject: Re: [Diffserv] Model draft - sharing elements on multiple > interfaces > > > Bob, > > I think you're trying to craft a compromise with Keith here > but what you propose > is inconsistent. [Note that I didn't mention the MIB in my > message: the MIB can > implement a subset of the model if it so chooses, so long as > it is not > inconsistent with the model, but that's not the point I > raised - by all means > discuss the impact of this issue on the MIB in a separate > thread but don't let > that confuse this discussion of the model]. > > The point in question is whether > "shared-between-multiple-interfaces" elements > are both (a) useful for implementing specific services and > (b) likely to be > implemented by more than one vendor and (c) without this > change, does it make it > impossible/unlikely that the model can be used to represent a > significant set of > devices? I believe that, for (a), the model needs to be > symmetric: if such a > service is useful for "in" then it is also for "out" e.g. > metering on a > collection of interfaces representing one customer is just as > useful in both > directions. As regards (b), I'd like to hear some more > opinions: so far the exit > poll (3 opinions) seems to read: > > In? Out? > Y/N Y/N > 2/1 1/2 > > (if that notation makes sense). And for (c) I'm not sure we > have any data points. > > > Andrew ------_=_NextPart_001_01C06090.9C7E0CBC Content-Type: text/html; charset="ISO-8859-1" Content-Transfer-Encoding: quoted-printable RE: [Diffserv] Model draft - sharing elements on multiple = interfaces

Andrew,

To your first question, I think it is important to = support the ability to aggregate multiple interfaces to a single = forwarding engine since I know many implementations that work this way. = However, the question of symmetry struck a stronger cord with me. In = your alternate picture:

> -> I -+-> I -> core -> E -+-> E = ->
>       = |            = ;       |
> -> I = -+           &nbs= p;       +-> E ->

It struck me that the egress is a bit more odd = because I am struggling to figure out what a fan-out on the egress = means. Do you have a use case in mind? Is this describing a possible = scenario where for example a classifier is selecting between multiple = interfaces?

regards,

-Walter

> -----Original Message-----
> From: Andrew Smith [mailto:andrew@allegronetworks= .com]
> Sent: Wednesday, December 06, 2000 1:38 = PM
> To: Robert Moore
> Cc: diffserv
> Subject: Re: [Diffserv] Model draft - sharing = elements on multiple
> interfaces
>
>
> Bob,
>
> I think you're trying to craft a compromise = with Keith here
> but what you propose
> is inconsistent. [Note that I didn't mention = the MIB in my
> message: the MIB can
> implement a subset of the model if it so = chooses, so long as
> it is not
> inconsistent with the model, but that's not the = point I
> raised - by all means
> discuss the impact of this issue on the MIB in = a separate
> thread but don't let
> that confuse this discussion of the = model].
>
> The point in question is whether
> "shared-between-multiple-interfaces" = elements
> are both (a) useful for implementing specific = services and
> (b) likely to be
> implemented by more than one vendor and (c) = without this
> change, does it make it
> impossible/unlikely that the model can be used = to represent a
> significant set of
> devices? I believe that, for (a), the model = needs to be
> symmetric: if such a
> service is useful for "in" then it is = also for "out" e.g.
> metering on a
> collection of interfaces representing one = customer is just as
> useful in both
> directions. As regards (b), I'd like to hear = some more
> opinions: so far the exit
> poll (3 opinions) seems to read:
>
>    In?   Out?
>    Y/N   Y/N
>    2/1   1/2
>
> (if that notation makes sense). And for (c) I'm = not sure we
> have any data points.
>
>
> Andrew

------_=_NextPart_001_01C06090.9C7E0CBC-- _______________________________________________ diffserv mailing list diffserv@ietf.org http://www1.ietf.org/mailman/listinfo/diffserv Archive: http://www2.ietf.org/mail-archive/working-groups/diffserv/current/maillist.html From diffserv-admin@ietf.org Thu Dec 7 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 SMTP id QAA10895 for ; Thu, 7 Dec 2000 16:31:47 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id QAA16889; Thu, 7 Dec 2000 16:13:28 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id QAA16858 for ; Thu, 7 Dec 2000 16:13:23 -0500 (EST) Received: from longsys.com (dmz.longsys.com [63.111.150.5]) by ietf.org (8.9.1a/8.9.1a) with SMTP id QAA06847 for ; Thu, 7 Dec 2000 16:13:23 -0500 (EST) Received: from joel (discordian.longsys.com [63.111.150.74]) by longsys.com (8.10.0/8.10.0) with ESMTP id eB7LDGI15038; Thu, 7 Dec 2000 21:13:17 GMT Message-Id: <4.2.2.20001207160640.00b32220@localhost> X-Sender: joel@localhost X-Mailer: QUALCOMM Windows Eudora Pro Version 4.2.2 Date: Thu, 07 Dec 2000 16:11:05 -0500 To: Brian E Carpenter , Kathleen Nichols From: "Joel M. Halpern" Subject: Re: [Diffserv] DSCP marking versus DSCP remarking Cc: "'diffserv@ietf.org'" , policy@raleigh.ibm.com In-Reply-To: <3A2FB980.14BEAD33@hursley.ibm.com> References: <3A2D4EE0.EBFEAE43@packetdesign.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: diffserv-admin@ietf.org Errors-To: diffserv-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Diffserv Discussion List X-BeenThere: diffserv@ietf.org Actually, I believe that this misses the point of the issue Bob is raising. From the point of view of the processing elements, I can find no difference between a marker and a remarker. If one places the processing element on a data path such that the packet is coming from outside diffserv, then it is a marker. If it could have been previously remarked. The problem is that the informal model actually says that one might have a processing element that was allowed to be a marker, but not a remarker. That would require the processing element to know the history of the packet. It would need to know whether the packet arrived over an interface considered to be inside or outside the diffserv domain. For those arriving over an outside interface that was not considered to be applying useful diffserv markings, it would have to know if the current value in the DSCP came from the input or was put there by an earlier marker in the processing stream. These are things that the "marker" element has no way to determine. The human being placing it there may have a way to tell. But then, the human being can put in a classifier if he is concerned about what value is in the field. It is NOT up to a marker to look at the packet and decide if it should stamp the value. If the packet gets to the marker, mark it. Yours, Joel M. Halpern At 10:23 AM 12/7/00 -0600, Brian E Carpenter wrote: >I believe this is quite clearly discussed in RFC 2474/5. >Packets arriving from a non-DS domain can't be regarded >as containing a meaningful DSCP value until they have >been classified and marked. > >I don't think that Policy WG documents should be in the >business of tweaking the diffserv architecture. > > Brian > >Kathleen Nichols wrote: > > > > Robert Moore wrote: > > > > > ... > > > > > > This is *almost* just a question of wordsmithing in the > > > three diffserv WG documents. But not quite. If there is > > > actual disagreement in the WG about whether there is such > > > a thing as an unmarked packet, that is, a packet that's > > > not marked with any DSCP, then the question should be > > > discussed until the WG reaches a consensus one way or the > > > other. Does everybody agree with the QDDIM team that > > > there is no such thing as a packet unmarked with any DSCP? > > > > > > > With my WG co-chair hat OFF, I agree that we should just have > > a "marker" as a primitive element. I would not phrase this as > > saying "there is no such thing as a packet unmarked with any > > DSCP". If someone chooses to use that phrase to describe > > packets marked with an unknown, illegal, or unverified DSCP, > > it should not have any architectural effect. > > > > Kathie > > > > _______________________________________________ > > diffserv mailing list > > diffserv@ietf.org > > http://www1.ietf.org/mailman/listinfo/diffserv > > Archive: > http://www2.ietf.org/mail-archive/working-groups/diffserv/current/maillist.html > >_______________________________________________ >diffserv mailing list >diffserv@ietf.org >http://www1.ietf.org/mailman/listinfo/diffserv >Archive: >http://www2.ietf.org/mail-archive/working-groups/diffserv/current/maillist.html _______________________________________________ diffserv mailing list diffserv@ietf.org http://www1.ietf.org/mailman/listinfo/diffserv Archive: http://www2.ietf.org/mail-archive/working-groups/diffserv/current/maillist.html From diffserv-admin@ietf.org Thu Dec 7 17:17:59 2000 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with SMTP id RAA17320 for ; Thu, 7 Dec 2000 17:17:58 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id QAA17773; Thu, 7 Dec 2000 16:55:58 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id QAA17744 for ; Thu, 7 Dec 2000 16:55:54 -0500 (EST) Received: from mailman.packetdesign.com (dns.PACKETDESIGN.NET [216.15.46.10]) by ietf.org (8.9.1a/8.9.1a) with SMTP id QAA13838 for ; Thu, 7 Dec 2000 16:55:53 -0500 (EST) Received: from packetdesign.com (dhcp-168-0-13.packetdesign.com [192.168.0.13]) by mailman.packetdesign.com (8.11.0/8.11.0) with ESMTP id eB7LskQ13399; Thu, 7 Dec 2000 13:54:46 -0800 (PST) (envelope-from nichols@packetdesign.com) Message-ID: <3A3009E9.B345D1BA@packetdesign.com> Date: Thu, 07 Dec 2000 14:06:33 -0800 From: Kathleen Nichols X-Mailer: Mozilla 4.73 [en] (X11; I; Linux 2.2.12 i386) X-Accept-Language: en MIME-Version: 1.0 To: demir CC: John Schnizlein , Brian E Carpenter , diffserv@ietf.org Subject: Re: [Diffserv] EFRESOLVE definition in the presence of excess inputburstiness References: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: diffserv-admin@ietf.org Errors-To: diffserv-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Diffserv Discussion List X-BeenThere: diffserv@ietf.org Content-Transfer-Encoding: 7bit demir wrote: > ... > - My general point was about "what you hope". To me, EFRESOLVE has a risk > of embedding services into EF PHB. S term is very risky (Intuitively, I > feel that bounding delay at a hop in an efficient way might be a > problem). Not does only it might depend on "network topology", but also it > closely depends on the "scheduling" mechanisms used in a hop (This can be > okay for a hop. I still see it as "embedding services" into the PHB. If > someone comes up with a "bright" idea to achieve this goal on a PHB, that > would be great. PDBs can handle it in the future because, the current EF > PHB doesn't have any risk. Hmm, okay, I don't see it that way. I don't think EF resolve adds topology dependence. It does break out more parameters in how you write/think of the boundedness of the PHB's delay variation, but that doesn't change things fundamentally. In fact, it does clarify them. I'm glad you like the original EF PHB, but even as a co-author, I have to say that EFresolve lays things out more clearly. Still, I think the words in the 2598 should make the intent clear and with EFresolve making a clearer definition of the bound, this is a good thing. > - My suggestion: To keep the current EF PHB the way it is. > - I emailed a new suggestion that EF MAY have "queuing and > discard" behavior for EF PHB (my previous email). This won't change the > current trend. It will leave an open window for "qualitative" services and > it will help when "trafic conditioners" fail. Brian refered it as > "fundamental" change (I assume he refered as "fundamental change" for > EF). I agree. However, it would have been nice. If someone doesn't like > it, he/she doesn't use it in a Diffserv domain. I'm afraid I've missed that email, but I believe I agree with Brian. We've had these discussions before. > - Toplogy dependent parameters should be avoided ina PHB. Yes, I agree. If there IS topology dependence it should be in a PDB. But I don't think EFresolve is dependent on network topology. > - Currently, unaccepted terminology such as "burstiness" should be avoided > in a PHB definition. PDBs can do that however they like. > - I think current EF PHB is fine. > Since the EFresolve team defined what they meant by "burstiness", I don't have a problem with this. It's basically saying that the vendor has to expose the buffer available if there are simultaneous arrivals. Again, I'm glad you think the current EF PHB is fine, but I think the EFresolve version is equivalent. And I hope I'm not so enamored of words I've co-authored that I can't accept their clarifications! Kathie _______________________________________________ diffserv mailing list diffserv@ietf.org http://www1.ietf.org/mailman/listinfo/diffserv Archive: http://www2.ietf.org/mail-archive/working-groups/diffserv/current/maillist.html From diffserv-admin@ietf.org Thu Dec 7 17:54:22 2000 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with SMTP id RAA21958 for ; Thu, 7 Dec 2000 17:54:18 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id RAA18363; Thu, 7 Dec 2000 17:26:54 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id RAA18339 for ; Thu, 7 Dec 2000 17:26:50 -0500 (EST) Received: from longsys.com (dmz.longsys.com [63.111.150.5]) by ietf.org (8.9.1a/8.9.1a) with SMTP id RAA18494 for ; Thu, 7 Dec 2000 17:26:49 -0500 (EST) Received: from joel (discordian.longsys.com [63.111.150.74]) by longsys.com (8.10.0/8.10.0) with ESMTP id eB7MQjW16778; Thu, 7 Dec 2000 22:26:45 GMT Message-Id: <4.2.2.20001207172221.00b49520@localhost> X-Sender: joel@localhost X-Mailer: QUALCOMM Windows Eudora Pro Version 4.2.2 Date: Thu, 07 Dec 2000 17:24:33 -0500 To: Andrew Smith From: "Joel M. Halpern" Subject: Re: [Diffserv] Re: DSCP marking versus DSCP remarking Cc: "'diffserv@ietf.org'" , policy@raleigh.ibm.com In-Reply-To: <3A2FEA97.7040705@allegronetworks.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 As I said in another recent reply, I really believe that this is not the case. Even a human being looking from outside the box might well have trouble telling if a packet sitting at a marker is already marked or not. Suppose that one of the several paths to this marker goes through an earlier marker/meter sequence. Suppose that the customer SLA says that the customers diffserv marking will be respected. The device component is certainly in no position to tell the difference. It seems to me that this distinction is distracting and error prone. It can not translate to a difference in resulting behavior. Yours, Joel M. Halpern At 11:52 AM 12/7/00 -0800, Andrew Smith wrote: >I'm slightly confused as to whether I need to change anything in the Model >draft here: I think, to paraphrase Brian's answer, that there *is* such a >thing, conceptually, as an unmarked packet. You can tell, by implicit >context, whether a packet is or is not already "marked" (it's a "policy" >or "trust" thing, in the abstract sense of those terms). > >Do I have this right? > >Andrew Smith >(Diffserv Model draft editor) > > >Robert Moore wrote: > >>In the DiffServ Informal Model, MIB, and PIB, there >>is a distinction drawn between a marker that marks >>unmarked packets, and one that remarks packets that >>had been marked previously. This distinction appears >>most clearly in section 6.1 of the Informal Model. >>The MIB and the PIB make it implicitly, by importing >>the terms "mark" and "remark" from the Informal Model. >>This distinction presupposes that among the packets >>coming into a marker, some can be identified as >>already marked, and others can be identified as >>unmarked. I don't believe that this is the case. >>In QDDIM, we have come down squarely on the side that >>says there is no such thing as an unmarked packet, and >>thus no distinction between packet marking and packet >>remarking. Every packet has one of 64 values, decimal >>0 - 63, in the DSCP field. Each of these values, >>including 0, is a legitimate DSCP. So a DSCP marker >>always takes in a packet that is already marked with a >>DSCP, and marks (or remarks - which word we choose isn't >>important) the packet with another DSCP, which may or >>may not be the same DSCP as the one the packet had >>when it came into the marker. Based on this view, we >>removed from the MarkerService class in QDDIM a boolean >>property CanRemark, which said whether a marker was >>allowed to mark all packets, or only packets that were >>not already marked when they got to it. >>This is *almost* just a question of wordsmithing in the >>three diffserv WG documents. But not quite. If there is >>actual disagreement in the WG about whether there is such >>a thing as an unmarked packet, that is, a packet that's >>not marked with any DSCP, then the question should be >>discussed until the WG reaches a consensus one way or the >>other. Does everybody agree with the QDDIM team that >>there is no such thing as a packet unmarked with any DSCP? >>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://www2.ietf.org/mail-archive/working-groups/diffserv/current/maillist.html _______________________________________________ diffserv mailing list diffserv@ietf.org http://www1.ietf.org/mailman/listinfo/diffserv Archive: http://www2.ietf.org/mail-archive/working-groups/diffserv/current/maillist.html From diffserv-admin@ietf.org Thu Dec 7 18:05: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 SMTP id SAA23265 for ; Thu, 7 Dec 2000 18:05:02 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id RAA18852; Thu, 7 Dec 2000 17:46:54 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id RAA18745 for ; Thu, 7 Dec 2000 17:46:47 -0500 (EST) Received: from bor.ellacoya.com (216-064-109-139.inaddr.vitts.com [216.64.109.139]) by ietf.org (8.9.1a/8.9.1a) with SMTP id RAA20986 for ; Thu, 7 Dec 2000 17:46:41 -0500 (EST) Received: by BOR with Internet Mail Service (5.5.2650.21) id ; Thu, 7 Dec 2000 17:38:21 -0500 Message-ID: From: "Weiss, Walter" To: "'Andrew Smith'" , Brian E Carpenter Cc: diffserv Subject: RE: [Diffserv] Model draft - sharing elements on multiple interfa ces Date: Thu, 7 Dec 2000 17:38:19 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C0609E.6649EC16" Sender: diffserv-admin@ietf.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_01C0609E.6649EC16 Content-Type: text/plain; charset="ISO-8859-1" Couldn't you satisfy this policy by making Brian's text a positive? "[while the simple example in figure 2 does not show this explicitly] this model allows for the sharing of elements by more than one ingress, or even by more than one egress." regards, -Walter > -----Original Message----- > From: Andrew Smith [mailto:andrew@allegronetworks.com] > Sent: Thursday, December 07, 2000 3:05 PM > To: Brian E Carpenter > Cc: diffserv > Subject: Re: [Diffserv] Model draft - sharing elements on multiple > interfaces > > > Brian, > > That almost works. We'd still have to fix up several places > where it is implied > that elements are scoped to a single interface. I think we > ought only explicitly > to include the more complex model if there are people who > really want it in > there - and I'm not hearing any public calls to do so at present. > > However, if the MIB (or PIB or QDIM or ...) explicitly > permits this sharing then > I think a "does not exclude" disclaimer is not sufficient and > it should be > "included" explicitly in the Model. That is the only way to > be consistent about > a "specific standards-track instantiations may implement > subsets of the Model > but they shouldn't add new stuff" policy for this set of documents. > > Andrew > > Brian E Carpenter wrote: > > > How about covering this by a text note in the document, not by > > drawing the picture. > > > > "this model does not exclude the sharing of elements by more than > > one ingress, or even by more than one egress, but this is not > > explicitly modelled by the current document." > > > > Brian > > > > > > _______________________________________________ > diffserv mailing list > diffserv@ietf.org > http://www1.ietf.org/mailman/listinfo/diffserv > Archive: http://www2.ietf.org/mail-archive/working-groups/diffserv/current/maillist.h tml ------_=_NextPart_001_01C0609E.6649EC16 Content-Type: text/html; charset="ISO-8859-1" Content-Transfer-Encoding: quoted-printable RE: [Diffserv] Model draft - sharing elements on multiple = interfaces

Couldn't you satisfy this policy by making Brian's = text a positive?

"[while the simple example in figure 2 does not = show this explicitly] this model allows for the sharing of elements by = more than one ingress, or even by more than one = egress."

regards,

-Walter

> -----Original Message-----
> From: Andrew Smith [mailto:andrew@allegronetworks= .com]
> Sent: Thursday, December 07, 2000 3:05 = PM
> To: Brian E Carpenter
> Cc: diffserv
> Subject: Re: [Diffserv] Model draft - sharing = elements on multiple
> interfaces
>
>
> Brian,
>
> That almost works. We'd still have to fix up = several places
> where it is implied
> that elements are scoped to a single interface. = I think we
> ought only explicitly
> to include the more complex model if there are = people who
> really want it in
> there - and I'm not hearing any public calls to = do so at present.
>
> However, if the MIB (or PIB or QDIM or ...) = explicitly
> permits this sharing then
> I think a "does not exclude" = disclaimer is not sufficient and
> it should be
> "included" explicitly in the Model. = That is the only way to
> be consistent about
> a "specific standards-track instantiations = may implement
> subsets of the Model
> but they shouldn't add new stuff" policy = for this set of documents.
>
> Andrew
>
> Brian E Carpenter wrote:
>
> > How about covering this by a text note in = the document, not by
> > drawing the picture.
> >
> > "this model does not exclude the = sharing of elements by more than
> > one ingress, or even by more than one = egress, but this is not
> > explicitly modelled by the current = document."
> >
> >   Brian
> >
>
>
>
> = _______________________________________________
> diffserv mailing list
> diffserv@ietf.org
> http://www1.ietf.org/mailman/listinfo/diffserv
> Archive:
http://www2.ietf.org/mail-archive/working-groups/diffs= erv/current/maillist.html

------_=_NextPart_001_01C0609E.6649EC16-- _______________________________________________ diffserv mailing list diffserv@ietf.org http://www1.ietf.org/mailman/listinfo/diffserv Archive: http://www2.ietf.org/mail-archive/working-groups/diffserv/current/maillist.html From diffserv-admin@ietf.org Thu Dec 7 18:27:44 2000 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with SMTP id SAA24569 for ; Thu, 7 Dec 2000 18:27:44 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id SAA19219; Thu, 7 Dec 2000 18:04:19 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id SAA19194 for ; Thu, 7 Dec 2000 18:04:14 -0500 (EST) Received: from bor.ellacoya.com (216-064-109-139.inaddr.vitts.com [216.64.109.139]) by ietf.org (8.9.1a/8.9.1a) with SMTP id SAA23160 for ; Thu, 7 Dec 2000 18:04:12 -0500 (EST) Received: by BOR with Internet Mail Service (5.5.2650.21) id ; Thu, 7 Dec 2000 17:57:11 -0500 Message-ID: From: "Weiss, Walter" To: "'Joel M. Halpern'" , Brian E Carpenter , Kathleen Nichols Cc: "'diffserv@ietf.org'" , policy@raleigh.ibm.com Subject: RE: [Diffserv] DSCP marking versus DSCP remarking Date: Thu, 7 Dec 2000 17:57:03 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C060A1.080B7586" Sender: diffserv-admin@ietf.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_01C060A1.080B7586 Content-Type: text/plain; charset="ISO-8859-1" I agree with Joel. I was thinking about the scenario where a DS edge router may also be transiting traffic between two non DS domains and it occured to me that one may want to mark as DS on ingress and (re)mark to non-DS on egress or do nothing at all depending on how the classifiers and markers were configured and where they were located in the data path. A remarker is inherently ambiguous because it has been used at times to describe a mapping from one DSCP to another (map AF1 to EF) and at other times to enforce an SLS (remark non-conforming AF11 traffic to AF12). It is clear that a marker just assigns a dscp for the first time. However, would we consider a mapping from TOS precedence 3 low delay to EF as a remarking or a marking function? It seems more convenient to me to punt on the distinction then to draw out and distinguish each unique case. regards, -Walter > -----Original Message----- > From: Joel M. Halpern [mailto:joel@longsys.com] > Sent: Thursday, December 07, 2000 4:11 PM > To: Brian E Carpenter; Kathleen Nichols > Cc: 'diffserv@ietf.org'; policy@raleigh.ibm.com > Subject: Re: [Diffserv] DSCP marking versus DSCP remarking > > > Actually, I believe that this misses the point of the issue Bob is > raising. From the point of view of the processing elements, > I can find no > difference between a marker and a remarker. If one places > the processing > element on a data path such that the packet is coming from outside > diffserv, then it is a marker. If it could have been > previously remarked. > > The problem is that the informal model actually says that one > might have a > processing element that was allowed to be a marker, but not a > remarker. That would require the processing element to know > the history of > the packet. It would need to know whether the packet arrived over an > interface considered to be inside or outside the diffserv > domain. For > those arriving over an outside interface that was not > considered to be > applying useful diffserv markings, it would have to know if > the current > value in the DSCP came from the input or was put there by an > earlier marker > in the processing stream. > > These are things that the "marker" element has no way to > determine. The > human being placing it there may have a way to tell. But > then, the human > being can put in a classifier if he is concerned about what > value is in the > field. It is NOT up to a marker to look at the packet and > decide if it > should stamp the value. If the packet gets to the marker, mark it. > > Yours, > Joel M. Halpern > > At 10:23 AM 12/7/00 -0600, Brian E Carpenter wrote: > >I believe this is quite clearly discussed in RFC 2474/5. > >Packets arriving from a non-DS domain can't be regarded > >as containing a meaningful DSCP value until they have > >been classified and marked. > > > >I don't think that Policy WG documents should be in the > >business of tweaking the diffserv architecture. > > > > Brian > > > >Kathleen Nichols wrote: > > > > > > Robert Moore wrote: > > > > > > > ... > > > > > > > > This is *almost* just a question of wordsmithing in the > > > > three diffserv WG documents. But not quite. If there is > > > > actual disagreement in the WG about whether there is such > > > > a thing as an unmarked packet, that is, a packet that's > > > > not marked with any DSCP, then the question should be > > > > discussed until the WG reaches a consensus one way or the > > > > other. Does everybody agree with the QDDIM team that > > > > there is no such thing as a packet unmarked with any DSCP? > > > > > > > > > > With my WG co-chair hat OFF, I agree that we should just have > > > a "marker" as a primitive element. I would not phrase this as > > > saying "there is no such thing as a packet unmarked with any > > > DSCP". If someone chooses to use that phrase to describe > > > packets marked with an unknown, illegal, or unverified DSCP, > > > it should not have any architectural effect. > > > > > > Kathie > > > > > > _______________________________________________ > > > diffserv mailing list > > > diffserv@ietf.org > > > http://www1.ietf.org/mailman/listinfo/diffserv > > > Archive: > > http://www2.ietf.org/mail-archive/working-groups/diffserv/current/maillist.h tml > >_______________________________________________ >diffserv mailing list >diffserv@ietf.org >http://www1.ietf.org/mailman/listinfo/diffserv >Archive: >http://www2.ietf.org/mail-archive/working-groups/diffserv/current/maillist. html ------_=_NextPart_001_01C060A1.080B7586 Content-Type: text/html; charset="ISO-8859-1" Content-Transfer-Encoding: quoted-printable RE: [Diffserv] DSCP marking versus DSCP remarking

I agree with Joel. I was thinking about the scenario = where a DS edge router may also be transiting traffic between two non = DS domains and it occured to me that one may want to mark  as DS = on ingress and (re)mark to non-DS on egress or do nothing at all = depending on how the classifiers and markers were configured and where = they were located in the data path.

A remarker is inherently ambiguous because it has = been used at times to describe a mapping from one DSCP to another (map = AF1 to EF) and at other times to enforce an SLS (remark non-conforming = AF11 traffic to AF12). It is clear that a marker just assigns a dscp = for the first time. However, would we consider a mapping from TOS = precedence 3 low delay to EF as a remarking or a marking function? It = seems more convenient to me to punt on the distinction then to draw out = and distinguish each unique case.

regards,

-Walter

> -----Original Message-----
> From: Joel M. Halpern [mailto:joel@longsys.com]
> Sent: Thursday, December 07, 2000 4:11 = PM
> To: Brian E Carpenter; Kathleen Nichols
> Cc: 'diffserv@ietf.org'; = policy@raleigh.ibm.com
> Subject: Re: [Diffserv] DSCP marking versus = DSCP remarking
>
>
> Actually, I believe that this misses the point = of the issue Bob is
> raising.  From the point of view of the = processing elements,
> I can find no
> difference between a marker and a = remarker.  If one places
> the processing
> element on a data path such that the packet is = coming from outside
> diffserv, then it is a marker.  If it = could have been
> previously remarked.
>
> The problem is that the informal model actually = says that one
> might have a
> processing element that was allowed to be a = marker, but not a
> remarker.  That would require the = processing element to know
> the history of
> the packet.  It would need to know whether = the packet arrived over an
> interface considered to be inside or outside = the diffserv
> domain.  For
> those arriving over an outside interface that = was not
> considered to be
> applying useful diffserv markings, it would = have to know if
> the current
> value in the DSCP came from the input or was = put there by an
> earlier marker
> in the processing stream.
>
> These are things that the "marker" = element has no way to
> determine.  The
> human being placing it there may have a way to = tell.  But
> then, the human
> being can put in a classifier if he is = concerned about what
> value is in the
> field.  It is NOT up to a marker to look = at the packet and
> decide if it
> should stamp the value.  If the packet = gets to the marker, mark it.
>
> Yours,
> Joel M. Halpern
>
> At 10:23 AM 12/7/00 -0600, Brian E Carpenter = wrote:
> >I believe this is quite clearly discussed = in RFC 2474/5.
> >Packets arriving from a non-DS domain can't = be regarded
> >as containing a meaningful DSCP value until = they have
> >been classified and marked.
> >
> >I don't think that Policy WG documents = should be in the
> >business of tweaking the diffserv = architecture.
> >
> >   Brian
> >
> >Kathleen Nichols wrote:
> > >
> > > Robert Moore wrote:
> > > >
> > > ...
> > > >
> > > > This is *almost* just a question = of wordsmithing in the
> > > > three diffserv WG = documents.  But not quite.  If there is
> > > > actual disagreement in the WG = about whether there is such
> > > > a thing as an unmarked packet, = that is, a packet that's
> > > > not marked with any DSCP, then = the question should be
> > > > discussed until the WG reaches a = consensus one way or the
> > > > other.  Does everybody = agree with the QDDIM team that
> > > > there is no such thing as a = packet unmarked with any DSCP?
> > > >
> > >
> > > With my WG co-chair hat OFF, I agree = that we should just have
> > > a "marker" as a primitive = element. I would not phrase this as
> > > saying "there is no such thing = as a packet unmarked with any
> > > DSCP". If someone chooses to use = that phrase to describe
> > > packets marked with an unknown, = illegal, or unverified DSCP,
> > > it should not have any architectural = effect.
> > >
> > = >         Kathie
> > >
> > > = _______________________________________________
> > > diffserv mailing list
> > > diffserv@ietf.org
> > > http://www1.ietf.org/mailman/listinfo/diffserv
> > > Archive:
> >
http://www2.ietf.org/mail-archive/working-groups/diffs= erv/current/maillist.html
>
>_______________________________________________
>diffserv mailing list
>diffserv@ietf.org
>http://www1.ietf.org/mailman/listinfo/diffserv
>Archive:
>http://www2.ietf.org/mail-archive/working-groups/diffs= erv/current/maillist.html

------_=_NextPart_001_01C060A1.080B7586-- _______________________________________________ diffserv mailing list diffserv@ietf.org http://www1.ietf.org/mailman/listinfo/diffserv Archive: http://www2.ietf.org/mail-archive/working-groups/diffserv/current/maillist.html From diffserv-admin@ietf.org Thu Dec 7 19:02:54 2000 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with SMTP id TAA04191 for ; Thu, 7 Dec 2000 19:02:54 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id SAA19831; Thu, 7 Dec 2000 18:44:14 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id SAA19729 for ; Thu, 7 Dec 2000 18:44:07 -0500 (EST) Received: from bor.ellacoya.com (216-064-109-139.inaddr.vitts.com [216.64.109.139]) by ietf.org (8.9.1a/8.9.1a) with SMTP id SAA29601 for ; Thu, 7 Dec 2000 18:44:04 -0500 (EST) Received: by BOR with Internet Mail Service (5.5.2650.21) id ; Thu, 7 Dec 2000 18:37:02 -0500 Message-ID: From: "Weiss, Walter" To: "'Andrew Smith'" , Brian E Carpenter Cc: Robert Moore , "'diffserv@ietf.org'" Subject: RE: [Diffserv] Degree of detail in the DiffServ MIB Date: Thu, 7 Dec 2000 18:36:54 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C060A6.98FF09A4" Sender: diffserv-admin@ietf.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_01C060A6.98FF09A4 Content-Type: text/plain; charset="ISO-8859-1" Hmm. So with my DiffServ hat on, I find myself agreeing and disagreeing with Brian and Andrew. I would agree that any Policy work (QDIM or not) is obliged to be consistent with the Informal Model. Further, non-DS works should not dictate the DS specific contents of DS works (in this case the MIB). I disagree with Brian and Andrew that the text is too specific. Here is the text again and we can go through it line for line: (1)This property is an unsigned 8-bit integer, representing a value to be used for marking the DSCP within the DS field in an IPv4 or IPv6 packet header. (2)Since the DSCP consists of 6 bits, the values for this property are limited to the range 0..63. (3)When the DSCP is marked, the remaining two bit in the DS field are left unchanged. Sentence 1 is a no brainer. For sentence 2, I would say that a currently valid range for a DSCP is 0-63. This is clearly stated in 2474: "Six bits of the DS field are used as a codepoint (DSCP) to select the PHB a packet experienes at each node." Sentence 3 is also entirely consistent with 2474: "The value of the CU bits are ignored by differentiated services-compliant nodes when determining the per-hop behavior to apply to a received packet." I frankly don't see anything wrong with this text. I would view Bob's comment as a suggestion to the MIB and PIB. However, I don't see it as a big deal if the MIB text is not changed. The MIB explicitly mentions the DSCP, which is in turn explicitly defined in 2474 as a 6 bit field. regards, -Walter > -----Original Message----- > From: Andrew Smith [mailto:andrew@allegronetworks.com] > Sent: Thursday, December 07, 2000 1:47 PM > To: Brian E Carpenter > Cc: Robert Moore; 'diffserv@ietf.org' > Subject: Re: [Diffserv] Degree of detail in the DiffServ MIB > > > I guess I'm a Diffserver, not a Policier. I think that the > QDDIM text is too > specific - this is a good example of a case where importing > by reference rather > than by value is a good thing. If you make sure that the > reference is precise > enough (e.g. find the right paragraph in the appropriate DS > base RFC - BTW, that > would be a good "REFERENCE" clause addition to the Dscp TC in > the MIB) then > you've done sufficient. In particular, the CU bits should not > be referenced at all. > > I sympathise with the desire to include more detailed > information, particularly > in a machine-parsable form (e.g. a DESCRIPTION clause in a > MIB), but that does a > disservice when it can easily become out of date and yet it > remains built in to > the "Help" files of a management tool, for example. > > Andrew Smith > > Brian E Carpenter wrote: > > > Bob, > > > > My question is explicitly about the level of detail in QDDIM. > > I don't understand why something called a policy model would > > even attempt to model or describe these details. It's a WG question > > because it creates a level of dependency of Policy documents > > on Diffserv documents that concerns me. I don't want to hear that > > we need to hold up Diffserv documents because of this dependency. > > > > It's intentional that we say nothing whatever about the Currently > > Unused bits in DiffServ documents. They don't belong to DiffServ so > > we should say nothing about them. > > > > Brian > > > > Robert Moore wrote: > > > >> Brian, > >> > >> I think that the WG question is a red herring here. The > >> important question is whether the MIB and PIB need to have > >> this level of detail. Whether they include it directly, > >> or import it by reference from a document like QDDIM, is a > >> secondary question. > >> > >> So why *wouldn't* you want this level of detail in the MIB > >> and the PIB? I don't think it's because you want to leave > >> vendors room to innovate in how they do DSCP marking. The > >> only other argument I can think of is that the detail is > >> unnecessary, i.e., that everybody will implement it > >> correctly, even without the additional detail. Since we've > >> had cases in the past where "obvious" things were > >> interpreted, and thus implemented, in unexpected ways, > >> my inclination is to err on the side of too much detail > >> rather than too little. The additional detail doesn't hurt > >> anything, and it might help. > >> > >> Regards, > >> Bob > >> > >> Bob Moore > >> IBM Networking Software > >> +1-919-254-4436 > >> remoore@us.ibm.com > >> > >> Brian E Carpenter @ietf.org on > 12/07/2000 11:12:11 > >> AM > >> > >> Sent by: diffserv-admin@ietf.org > >> > >> To: "'diffserv@ietf.org'" > >> cc: > >> Subject: Re: [Diffserv] Degree of detail in the DiffServ MIB > >> > >> I'd like opinions from diffservers whether the Policy WG > is or is not > >> getting into too much detail in this case. > >> > >> Brian > >> > >> Robert Moore wrote: > >> > >>> Here is the DiffServ MIB's text describing the DSCP Mark > Action Table: > >>> > >>> 3.4.1. DSCP Mark Action Table > >>> > >>> This Action is applied to traffic in order to mark it > with a Diffserv > >>> Codepoint (DSCP) value, specified in the > diffServDscpMarkActTable. > >> > >> Other > >> > >>> marking actions might be specified elsewhere - these > are outside the > >>> scope of this MIB. > >>> > >>> And here is the text from QDDIM describing the property in > >>> a DSCP marker that holds the DSCP value: > >>> > >>> 4.4.16.1 The Property DSCPValue > >>> > >>> This property is an unsigned 8-bit integer, > representing a value to be > >>> used for marking the DSCP within the DS field in an > IPv4 or IPv6 packet > >>> header. Since the DSCP consists of 6 bits, the values for this > >> > >> property > >> > >>> are limited to the range 0..63. When the DSCP is > marked, the remaining > >>> two bit in the DS field are left unchanged. > >>> > >>> Clearly there is an additional detail in the QDDIM version: > >>> the statement that the remaining two bits are left unchanged. > >>> (The range limitation 0..63 is handled in the MIB by the > >>> Dscp Textual Convention (-1 | 0..63), combined with the > >>> description text for the object, saying that the value -1 > >>> is not allowed.) In the ordinary Policy Framework treatment > >>> ("ordinary" based on one partially completed example of PCIM > >>> and PCLS, but never mind that:-), this level of detail would > >>> be documented in the Information Model (QDDIM in this case), > >>> and then incorporated by reference into the Data Models (the > >>> MIB and the PIB) derived from it. But in this case the Data > >>> Models are much more mature, and thus closer to completion, > >>> than the QDDIM. The only remaining alternatives are either > >>> not to have the detail at all in the MIB and PIB, or else to > >>> copy the QDDIM text into them. I vote for copying the text > >>> in, because of past history of cases in which "everybody knows > >>> what that means" being exposed as cases in which different > >>> people "know" different things. > >>> > >>> I don't have a complete list, but I'm sure this is not the > >>> only instance where the QDDIM has more detail than the two > >>> diffserv Data Models. > >>> > >>> 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://www2.ietf.org/mail-archive/working-groups/diffserv/current/maillist.h tml > > > _______________________________________________ > diffserv mailing list > diffserv@ietf.org > http://www1.ietf.org/mailman/listinfo/diffserv > Archive: http://www2.ietf.org/mail-archive/working-groups/diffserv/current/maillist.h tml _______________________________________________ diffserv mailing list diffserv@ietf.org http://www1.ietf.org/mailman/listinfo/diffserv Archive: http://www2.ietf.org/mail-archive/working-groups/diffserv/current/maillist.h tml ------_=_NextPart_001_01C060A6.98FF09A4 Content-Type: text/html; charset="ISO-8859-1" Content-Transfer-Encoding: quoted-printable RE: [Diffserv] Degree of detail in the DiffServ MIB

Hmm. So with my DiffServ hat on, I find myself = agreeing and disagreeing with Brian and Andrew. I would agree that any = Policy work (QDIM or not) is obliged to be consistent with the Informal = Model. Further, non-DS works should not dictate the DS specific = contents of DS works (in this case the MIB).

I disagree with Brian and Andrew that the text is too = specific. Here is the text again and we can go through it line for = line:

(1)This property is an unsigned 8-bit integer, = representing a value to be used for marking the DSCP within the DS = field in an IPv4 or IPv6 packet header. (2)Since the DSCP consists of 6 = bits, the values for this property are limited to the range 0..63. = (3)When the DSCP is marked, the remaining two bit in the DS field are = left unchanged.

Sentence 1 is a no brainer. For sentence 2, I would = say that a currently valid range for a DSCP is 0-63. This is clearly = stated in 2474:

"Six bits of the DS field are used as a = codepoint (DSCP) to select the PHB a packet experienes at each = node."

Sentence 3 is also entirely consistent with = 2474:

"The value of the CU bits are ignored by = differentiated services-compliant nodes when determining the per-hop = behavior to apply to a received packet."

I frankly don't see anything wrong with this text. I = would view Bob's comment as a suggestion to the MIB and PIB. However, I = don't see it as a big deal if the MIB text is not changed. The MIB = explicitly mentions the DSCP, which is in turn explicitly defined in = 2474 as a 6 bit field.

regards,

-Walter

> -----Original Message-----
> From: Andrew Smith [mailto:andrew@allegronetworks= .com]
> Sent: Thursday, December 07, 2000 1:47 = PM
> To: Brian E Carpenter
> Cc: Robert Moore; 'diffserv@ietf.org'
> Subject: Re: [Diffserv] Degree of detail in the = DiffServ MIB
>
>
> I guess I'm a Diffserver, not a Policier. I = think that the
> QDDIM text is too
> specific - this is a good example of a case = where importing
> by reference rather
> than by value is a good thing. If you make sure = that the
> reference is precise
> enough (e.g. find the right paragraph in the = appropriate DS
> base RFC - BTW, that
> would be a good "REFERENCE" clause = addition to the Dscp TC in
> the MIB) then
> you've done sufficient. In particular, the CU = bits should not
> be referenced at all.
>
> I sympathise with the desire to include more = detailed
> information, particularly
> in a machine-parsable form (e.g. a DESCRIPTION = clause in a
> MIB), but that does a
> disservice when it can easily become out of = date and yet it
> remains built in to
> the "Help" files of a management = tool, for example.
>
> Andrew Smith
>
> Brian E Carpenter wrote:
>
> > Bob,
> >
> > My question is explicitly about the level = of detail in QDDIM.
> > I don't understand why something called a = policy model would
> > even attempt to model or describe these = details. It's a WG question
> > because it creates a level of dependency = of Policy documents
> > on Diffserv documents that concerns me. I = don't want to hear that
> > we need to hold up Diffserv documents = because of this dependency.
> >
> > It's intentional that we say nothing = whatever about the Currently
> > Unused bits in DiffServ documents. They = don't belong to DiffServ so
> > we should say nothing about them.
> >
> >   Brian
> >
> > Robert Moore wrote:
> >
> >> Brian,
> >>
> >> I think that the WG question is a red = herring here.  The
> >> important question is whether the MIB = and PIB need to have
> >> this level of detail.  Whether = they include it directly,
> >> or import it by reference from a = document like QDDIM, is a
> >> secondary question.
> >>
> >> So why *wouldn't* you want this level = of detail in the MIB
> >> and the PIB?  I don't think it's = because you want to leave
> >> vendors room to innovate in how they = do DSCP marking.  The
> >> only other argument I can think of is = that the detail is
> >> unnecessary, i.e., that everybody will = implement it
> >> correctly, even without the additional = detail.  Since we've
> >> had cases in the past where = "obvious" things were
> >> interpreted, and thus implemented, in = unexpected ways,
> >> my inclination is to err on the side = of too much detail
> >> rather than too little.  The = additional detail doesn't hurt
> >> anything, and it might help.
> >>
> >> Regards,
> >> Bob
> >>
> >> Bob Moore
> >> IBM Networking Software
> >> +1-919-254-4436
> >> remoore@us.ibm.com
> >>
> >> Brian E Carpenter = <brian@hursley.ibm.com>@ietf.org on
> 12/07/2000 11:12:11
> >> AM
> >>
> >> Sent by:  = diffserv-admin@ietf.org
> >>
> >> To:   = "'diffserv@ietf.org'" <diffserv@ietf.org>
> >> cc:
> >> Subject:  Re: [Diffserv] Degree = of detail in the DiffServ MIB
> >>
> >> I'd like opinions from diffservers = whether the Policy WG
> is or is not
> >> getting into too much detail in this = case.
> >>
> >>    Brian
> >>
> >> Robert Moore wrote:
> >>
> >>> Here is the DiffServ MIB's text = describing the DSCP Mark
> Action Table:
> >>>
> >>> 3.4.1.  DSCP Mark Action = Table
> >>>
> >>>    This Action is = applied to traffic in order to mark it
> with a Diffserv
> >>>    Codepoint (DSCP) = value, specified in the
> diffServDscpMarkActTable.
> >>
> >> Other
> >>
> >>>    marking actions = might be specified elsewhere - these
> are outside the
> >>>    scope of this = MIB.
> >>>
> >>> And here is the text from QDDIM = describing the property in
> >>> a DSCP marker that holds the DSCP = value:
> >>>
> >>> 4.4.16.1 The Property = DSCPValue
> >>>
> >>>   This property is an = unsigned 8-bit integer,
> representing a value to be
> >>>   used for marking the = DSCP within the DS field in an
> IPv4 or IPv6 packet
> >>>   header.  Since = the DSCP consists of 6 bits, the values for this
> >>
> >> property
> >>
> >>>   are limited to the = range 0..63.  When the DSCP is
> marked, the remaining
> >>>   two bit in the DS = field are left unchanged.
> >>>
> >>> Clearly there is an additional = detail in the QDDIM version:
> >>> the statement that the remaining = two bits are left unchanged.
> >>> (The range limitation 0..63 is = handled in the MIB by the
> >>> Dscp Textual Convention (-1 | = 0..63), combined with the
> >>> description text for the object, = saying that the value -1
> >>> is not allowed.)  In the = ordinary Policy Framework treatment
> >>> ("ordinary" based on one = partially completed example of PCIM
> >>> and PCLS, but never mind that:-), = this level of detail would
> >>> be documented in the Information = Model (QDDIM in this case),
> >>> and then incorporated by reference = into the Data Models (the
> >>> MIB and the PIB) derived from = it.  But in this case the Data
> >>> Models are much more mature, and = thus closer to completion,
> >>> than the QDDIM.  The only = remaining alternatives are either
> >>> not to have the detail at all in = the MIB and PIB, or else to
> >>> copy the QDDIM text into = them.  I vote for copying the text
> >>> in, because of past history of = cases in which "everybody knows
> >>> what that means" being = exposed as cases in which different
> >>> people "know" different = things.
> >>>
> >>> I don't have a complete list, but = I'm sure this is not the
> >>> only instance where the QDDIM has = more detail than the two
> >>> diffserv Data Models.
> >>>
> >>> 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://www2.ietf.org/mail-archive/working-groups/diffs= erv/current/maillist.html
>
>
> = _______________________________________________
> diffserv mailing list
> diffserv@ietf.org
> http://www1.ietf.org/mailman/listinfo/diffserv
> Archive: http://www2.ietf.org/mail-archive/working-groups/diffs= erv/current/maillist.html


_______________________________________________
diffserv mailing list
diffserv@ietf.org
http://www1.ietf.org/mailman/listinfo/diffserv
Archive: http://www2.ietf.org/mail-archive/working-groups/diffs= erv/current/maillist.html

------_=_NextPart_001_01C060A6.98FF09A4-- _______________________________________________ diffserv mailing list diffserv@ietf.org http://www1.ietf.org/mailman/listinfo/diffserv Archive: http://www2.ietf.org/mail-archive/working-groups/diffserv/current/maillist.html From diffserv-admin@ietf.org Thu Dec 7 19:12:56 2000 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with SMTP id TAA06374 for ; Thu, 7 Dec 2000 19:12:56 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id SAA19897; Thu, 7 Dec 2000 18:46:04 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id SAA19875 for ; Thu, 7 Dec 2000 18:46:01 -0500 (EST) 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 SAA00205 for ; Thu, 7 Dec 2000 18:46:01 -0500 (EST) Received: from bronx.dnrc.bell-labs.com ([135.180.160.8]) by dirty; Thu Dec 7 18:44:59 EST 2000 Received: from dnrc.bell-labs.com (enrique-pcho [135.180.130.173]) by bronx.dnrc.bell-labs.com (8.9.3/8.9.3) with ESMTP id SAA09008; Thu, 7 Dec 2000 18:44:58 -0500 (EST) Message-ID: <3A302114.39AA99E6@dnrc.bell-labs.com> Date: Thu, 07 Dec 2000 18:45:24 -0500 From: Enrique Hernandez-Valencia Reply-To: enrique@bell-labs.com Organization: Bell Laboratories, Lucent Technologies X-Mailer: Mozilla 4.61 [en] (WinNT; U) X-Accept-Language: en MIME-Version: 1.0 To: "Joel M. Halpern" CC: Andrew Smith , "'diffserv@ietf.org'" , policy@raleigh.ibm.com Subject: Re: [Diffserv] Re: DSCP marking versus DSCP remarking References: <4.2.2.20001207172221.00b49520@localhost> 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 Indeed, and an edge box all packets are "marked" by virtue that the DSCP field MUST contain some codepoint, no matter how the source chose that codepoint. Even if the customer that generates such flow has an SLA with a network, it is still the responsibility of the network to make sure that in fact the codepoint(s) in that flow are consistent with that SLA. "Joel M. Halpern" wrote: > > As I said in another recent reply, I really believe that this is not the case. > Even a human being looking from outside the box might well have trouble > telling if a packet sitting at a marker is already marked or not. Suppose > that one of the several paths to this marker goes through an earlier > marker/meter sequence. Suppose that the customer SLA says that the > customers diffserv marking will be respected. > The device component is certainly in no position to tell the difference. > It seems to me that this distinction is distracting and error prone. It > can not translate to a difference in resulting behavior. If the customer has an SLA that indicates "the customer diffserv marking will be preserved", it seems that the only way for an ISP to provide such a service over its "diffserv domain" is to "tunnel" the customer flow -using its preferred tunneling mechanism-, since there is no way an edge box can guarantee/trust that a customer indeed will mark its flow consistently with the usage within a given ISP "diffserv domain". Enrique _______________________________________________ diffserv mailing list diffserv@ietf.org http://www1.ietf.org/mailman/listinfo/diffserv Archive: http://www2.ietf.org/mail-archive/working-groups/diffserv/current/maillist.html From diffserv-admin@ietf.org Thu Dec 7 19:57: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 SMTP id TAA06394 for ; Thu, 7 Dec 2000 19:12:57 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id SAA19984; Thu, 7 Dec 2000 18:48:54 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id SAA19954 for ; Thu, 7 Dec 2000 18:48:50 -0500 (EST) Received: from mailhub1.almaden.ibm.com (mailhub1.almaden.ibm.com [198.4.83.44]) by ietf.org (8.9.1a/8.9.1a) with SMTP id SAA00889 for ; Thu, 7 Dec 2000 18:48:50 -0500 (EST) Received: from maui.almaden.ibm.com (maui.almaden.ibm.com [9.1.24.92]) by mailhub1.almaden.ibm.com (8.8.8/8.8.8) with ESMTP id PAA41864; Thu, 7 Dec 2000 15:46:43 -0800 Received: from hursley.ibm.com (gsine04.us.sine.ibm.com [9.14.6.44]) by maui.almaden.ibm.com (AIX4.3/8.9.3/8.7) with ESMTP id PAA20916; Thu, 7 Dec 2000 15:47:45 -0800 Message-ID: <3A3020F1.B1448231@hursley.ibm.com> Date: Thu, 07 Dec 2000 17:44:49 -0600 From: Brian E Carpenter Organization: IBM X-Mailer: Mozilla 4.61 [en] (Win98; I) X-Accept-Language: en,fr MIME-Version: 1.0 To: "Joel M. Halpern" CC: Andrew Smith , "'diffserv@ietf.org'" , policy@raleigh.ibm.com Subject: Re: [Diffserv] Re: DSCP marking versus DSCP remarking References: <4.2.2.20001207172221.00b49520@localhost> 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 certainly agree that the marker itself can have no idea, and need have no idea, whether it is the first marker to mark a given packet - i.e. there is no functional difference between marking and remarking. It's only if you could watch the packets from a helicopter, and observe them passing from a non-DS domain into a DS domain, that you would know the difference. It's certainly a good idea to reflect this in the documents. Brian "Joel M. Halpern" wrote: > > As I said in another recent reply, I really believe that this is not the case. > Even a human being looking from outside the box might well have trouble > telling if a packet sitting at a marker is already marked or not. Suppose > that one of the several paths to this marker goes through an earlier > marker/meter sequence. Suppose that the customer SLA says that the > customers diffserv marking will be respected. > The device component is certainly in no position to tell the difference. > It seems to me that this distinction is distracting and error prone. It > can not translate to a difference in resulting behavior. > > Yours, > Joel M. Halpern > > At 11:52 AM 12/7/00 -0800, Andrew Smith wrote: > > >I'm slightly confused as to whether I need to change anything in the Model > >draft here: I think, to paraphrase Brian's answer, that there *is* such a > >thing, conceptually, as an unmarked packet. You can tell, by implicit > >context, whether a packet is or is not already "marked" (it's a "policy" > >or "trust" thing, in the abstract sense of those terms). > > > >Do I have this right? > > > >Andrew Smith > >(Diffserv Model draft editor) > > > > > >Robert Moore wrote: > > > >>In the DiffServ Informal Model, MIB, and PIB, there > >>is a distinction drawn between a marker that marks > >>unmarked packets, and one that remarks packets that > >>had been marked previously. This distinction appears > >>most clearly in section 6.1 of the Informal Model. > >>The MIB and the PIB make it implicitly, by importing > >>the terms "mark" and "remark" from the Informal Model. > >>This distinction presupposes that among the packets > >>coming into a marker, some can be identified as > >>already marked, and others can be identified as > >>unmarked. I don't believe that this is the case. > >>In QDDIM, we have come down squarely on the side that > >>says there is no such thing as an unmarked packet, and > >>thus no distinction between packet marking and packet > >>remarking. Every packet has one of 64 values, decimal > >>0 - 63, in the DSCP field. Each of these values, > >>including 0, is a legitimate DSCP. So a DSCP marker > >>always takes in a packet that is already marked with a > >>DSCP, and marks (or remarks - which word we choose isn't > >>important) the packet with another DSCP, which may or > >>may not be the same DSCP as the one the packet had > >>when it came into the marker. Based on this view, we > >>removed from the MarkerService class in QDDIM a boolean > >>property CanRemark, which said whether a marker was > >>allowed to mark all packets, or only packets that were > >>not already marked when they got to it. > >>This is *almost* just a question of wordsmithing in the > >>three diffserv WG documents. But not quite. If there is > >>actual disagreement in the WG about whether there is such > >>a thing as an unmarked packet, that is, a packet that's > >>not marked with any DSCP, then the question should be > >>discussed until the WG reaches a consensus one way or the > >>other. Does everybody agree with the QDDIM team that > >>there is no such thing as a packet unmarked with any DSCP? > >>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://www2.ietf.org/mail-archive/working-groups/diffserv/current/maillist.html > > _______________________________________________ > diffserv mailing list > diffserv@ietf.org > http://www1.ietf.org/mailman/listinfo/diffserv > Archive: http://www2.ietf.org/mail-archive/working-groups/diffserv/current/maillist.html -- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - Brian E Carpenter Program Director, Internet Standards & Technology, IBM On assignment for IBM at http://www.iCAIR.org Board Chairman, Internet Society http://www.isoc.org Non-IBM email: brian@icair.org _______________________________________________ diffserv mailing list diffserv@ietf.org http://www1.ietf.org/mailman/listinfo/diffserv Archive: http://www2.ietf.org/mail-archive/working-groups/diffserv/current/maillist.html From diffserv-admin@ietf.org Thu Dec 7 20: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 SMTP id UAA21236 for ; Thu, 7 Dec 2000 20:16:00 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id TAA20744; Thu, 7 Dec 2000 19:46:16 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id TAA20714 for ; Thu, 7 Dec 2000 19:46:12 -0500 (EST) Received: from usc.edu (root@usc.edu [128.125.253.136]) by ietf.org (8.9.1a/8.9.1a) with SMTP id TAA14251 for ; Thu, 7 Dec 2000 19:46:12 -0500 (EST) Received: from aludra.usc.edu (demir@aludra.usc.edu [128.125.253.184]) by usc.edu (8.9.3.1/8.9.3/usc) with ESMTP id QAA27030; Thu, 7 Dec 2000 16:46:11 -0800 (PST) Received: from localhost (demir@localhost) by aludra.usc.edu (8.9.3.1/8.9.3/usc) with ESMTP id QAA05934; Thu, 7 Dec 2000 16:46:10 -0800 (PST) Date: Thu, 7 Dec 2000 16:46:10 -0800 (PST) From: demir To: Kathleen Nichols cc: diffserv@ietf.org Subject: Re: [Diffserv] EFRESOLVE definition in the presence of excess inputburstiness In-Reply-To: <3A3009E9.B345D1BA@packetdesign.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: diffserv-admin@ietf.org Errors-To: diffserv-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Diffserv Discussion List X-BeenThere: diffserv@ietf.org Katie, > Hmm, okay, I don't see it that way. I don't think EF resolve adds > topology dependence. It does break out more parameters in how you > write/think of the boundedness of the PHB's delay variation, but that > doesn't change things fundamentally. In fact, it does clarify them. > I'm glad you like the original EF PHB, but even as a co-author, I > have to say that EFresolve lays things out more clearly. Still, I > think the words in the 2598 should make the intent clear and with > EFresolve making a clearer definition of the bound, this is a good > thing. I am not saying EFRESOLVE adds "topology dependence. S term has a risk if one wants to bound the delay in an "efficient" way. As Anna pointed out, It is a "philosolphical" change. That's how I see it. And the easiest way to achieve this is: D(i) < max_delay_bound(i) max_delay_bound(i) = a_constant This is not efficient. Current EFResolve has the same problem when scheduling mechanisms are not embedded/misinterpreted/etc into calculation of S(i). > I'm afraid I've missed that email, but I believe I agree with Brian. > We've had these discussions before. Then, sorry to bring it up again. I wasn't aware of. I thought "leaving an open window" would have been nice. > Yes, I agree. If there IS topology dependence it should be in a PDB. > But I don't think EFresolve is dependent on network topology. It might not. But if someone "realy" wants to achieve D(i) - S(i), "he" could face with this peoblem. This all has been discussed I guess. I don't know what the current aggrement is. Any idea? > Since the EFresolve team defined what they meant by "burstiness", I > don't have a problem with this. It's basically saying that the vendor > has to expose the buffer available if there are simultaneous arrivals. What is "exposing buffer"? > Again, I'm glad you think the current EF PHB is fine, but I think the > EFresolve version is equivalent. And I hope I'm not so enamored of I guess I can't see the "equivalance". With current EF PHB, one might end up defining a PDB using the ideas from EFResolve. Is it "equivalent"? Or/ am I missing a point here? Alper K. Demir _______________________________________________ diffserv mailing list diffserv@ietf.org http://www1.ietf.org/mailman/listinfo/diffserv Archive: http://www2.ietf.org/mail-archive/working-groups/diffserv/current/maillist.html From diffserv-admin@ietf.org Thu Dec 7 23:43:44 2000 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with SMTP id XAA12407 for ; Thu, 7 Dec 2000 23:43:39 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id XAA22708; Thu, 7 Dec 2000 23:20:07 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id XAA22683 for ; Thu, 7 Dec 2000 23:20:03 -0500 (EST) Received: from pilgrim.cisco.com (pilgrim.cisco.com [171.69.204.12]) by ietf.org (8.9.1a/8.9.1a) with SMTP id XAA05659 for ; Thu, 7 Dec 2000 23:20:00 -0500 (EST) Received: from bdaviepc.cisco.com ([171.69.210.246]) by pilgrim.cisco.com (8.8.8-Cisco List Logging/8.8.8) with SMTP id XAA18772; Thu, 7 Dec 2000 23:19:30 -0500 (EST) From: "Bruce Davie" To: Date: Thu, 7 Dec 2000 23:19:46 -0500 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2910.0) Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2314.1300 Content-Transfer-Encoding: 7bit Subject: [Diffserv] Possible compromise between EFRESOLVE and draft-charny Sender: diffserv-admin@ietf.org Errors-To: diffserv-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Diffserv Discussion List X-BeenThere: diffserv@ietf.org Content-Transfer-Encoding: 7bit We (the draft-charny authors) would like to propose a possible compromise EF definition which we think should reconcile the differences between the current definitions of draft-charny and EFRESOLVE. We think that it addresses all the criticisms that have been raised to date of both existing definitions, and satisfies the goals expressed in both drafts and RFC 2598. The major criticism of draft-charny was that it didn't provide any bound on the delay of an individual packet. This is because the definition only requires that EF packets leave the node at something close to the configured rate R. There is no requirement that EF packets are served in FIFO order, and thus, as long as new packets keep arriving fast enough, an individual packet could live inside a node forever without violating the definition. (This property is shared by RFC 2598). Among the criticisms of EFRESOLVE were - it doesn't define behavior of a node outside of its operating region - non-FIFO treatment of EF will typically lead to a large value of S - S is not a good figure of merit, since non-ideal scheduling and non-FIFO service are lumped in the same parameter; also very good devices with large number of ports will look worse than small devices with bad scheduling implementations - it is not yet clear how to generalize the defintion to the multiple input, multiple output case - it allows arbitrarily large fixed delay (which isn't visible in a figure of merit) While we stand by these criticisms, we also recognize that the ability to describe the delay bound on a per-packet basis under certain operating conditions may be quite useful in constructing certain PDB's based on EF. To address this, we propose to "clone" the original equations of draft-charny. The original equations remain part of the definition, and we now rename the error term E as E_a (aggregate error). We call this the "colorblind" definition because it pays no attention to individual EF packets. This part of the definition simply tells you how well the device does at serving aggregate EF traffic at the configured rate - small E_a means a better scheduler in this regard. (See the new draft-charny-ef-definition-01.txt for more on the intuitive meaning of the definition.) This part of the definition closely approximates the original RFC 2598 definition, in that it admits all the implementations that were mentioned in that RFC; it also gives a better figure of merit to implementations that are intuitively "better" at delivering EF service at a configured rate, e.g. a priority queue. The extra set of new equations looks just like the old ones but with one difference: this second part of the definition pays attention to individual packets so that we can bound the delay experienced by an individual packet. We call this the "color-aware" definition, because you can think of each packet as being uniquely colored as it enters a node and then the time at which that actual packet leaves the node is noted. The new error term from these equations is called E_p (packet error, as distinct from E_a). With this second part of the definition, the delay experienced by a single packet is bounded by B/R +E_p, where B is the bound on the burstiness of the input traffic and R is the configured rate. Hence, as long as the rate and burstiness of traffic that arrives at an output are bounded, the delay is also bounded. This additional part of the definition bears many similarities to the EFRESOLVE definition. To get bounded and well-defined behavior under EFRESOLVE, there need to be some constraints on the total offered traffic destined for an output in terms of rate and burstiness. Under such conditions, the per-packet delay is S*MTU/R plus the minimum fixed delay of the device. Similarly, under our "color-aware" definition when the offered load to an output is bounded by rate R and burst size B, the maximum per-packet delay is B/R + E_p. Clearly both definitions provide bounded delay under well-defined operating conditions. The second part of our definition addresses the intent of EFRESOLVE, but differs from EFRESOLVE in that it provides well-defined behavior for arbitrary inputs. In addition while EFRESOLVE gives a fixed delay within a specified operating region, our new definition allows an operator to achieve different performance goals by specifying different ranges of B and R that achieve the desired delay bounds. The first part of the definition allows existing and operational rate-based implementations and deployments of the EF PHB to continue to be deployed and operated (e.g EF implementation in Internet 2 managed by Bandwidth Brokers). The second part of the definition provides the machinery for computing the delay bound as a function of the operating conditions. In summary, we think this addition to draft-charny addresses all the criticisms made of that draft (except that it was too hard to understand) and also avoids the problems of EFRESOLVE, while addressing its goals. We'll address the "hard to understand" part in the WG meeting and, if necessary, in another version of the draft. We're hoping that we might be able to get WG consensus behind this compromise. Bruce Davie (on behalf of 12 co-authors of draft-charny) ---------- Equations for those who care: The original colorblind equations from draft-charny-...-01 are eq_1a and eq_2a. The new ones that achieve the compromise are eq_1b and eq_2b. Although the latter equations are not in draft-charny...01, the intuitive description of the equations in that draft may still be helpful in understanding the equations. D(j) <= F(j) + E_a (eq_1a) d(j) <= f(j) + E_p (eq_1b) where F(j) and f(j) are defined iteratively by F(0)=0, D(0) = 0 f(0)=0, d(0) = 0 F(j)=max(a(j), min(D(j-1), F(j-1)))+ L(j)/R, for all j>0 (eq_2a) f(j)=max(a(j), min(d(j-1), f(j-1)))+ l(j)/R for all j>0 (eq_2b) Here: D(j) is the time that the last bit of the j-th EF packet to depart from I actually leaves the node. d(j) is the time the last bit of the j-th packet to arrive for I from any input interface actually leaves the node. F(j) is the target departure (finishing) time for the j-th EF packet to depart from I. f(j) is the target departure (finishing) time for the departure of the j-th packet in an ideal FIFO server. a(j) is the time that the last bit of the j-th EF packet destined for I to arrive to the device actually arrives at the node. L(j) is the size of the j-th EF packet to depart from I. l(j) is the size of the j-th EF packet destined for I to arrive to the device. R is the EF configured rate at I (in bits/second) _______________________________________________ diffserv mailing list diffserv@ietf.org http://www1.ietf.org/mailman/listinfo/diffserv Archive: http://www2.ietf.org/mail-archive/working-groups/diffserv/current/maillist.html From diffserv-admin@ietf.org Fri Dec 8 00:34: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 SMTP id AAA00103 for ; Fri, 8 Dec 2000 00:34:56 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id AAA23442; Fri, 8 Dec 2000 00:15:34 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id AAA23413 for ; Fri, 8 Dec 2000 00:15:29 -0500 (EST) Received: from mta5.snfc21.pbi.net (mta5.snfc21.pbi.net [206.13.28.241]) by ietf.org (8.9.1a/8.9.1a) with SMTP id AAA22076 for ; Fri, 8 Dec 2000 00:15:30 -0500 (EST) Received: from allegronetworks.com ([206.170.1.233]) by mta5.snfc21.pbi.net (Sun Internet Mail Server sims.3.5.2000.01.05.12.18.p9) with ESMTP id <0G58003A4GD6DB@mta5.snfc21.pbi.net> for diffserv@ietf.org; Thu, 7 Dec 2000 20:55:57 -0800 (PST) Date: Thu, 07 Dec 2000 21:03:41 -0800 From: Andrew Smith Subject: Re: [Diffserv] Re: DSCP marking versus DSCP remarking To: Brian E Carpenter , "Joel M. Halpern" Cc: Walter Weiss , "'diffserv@ietf.org'" , policy@raleigh.ibm.com Message-id: <3A306BAD.5090308@allegronetworks.com> Organization: Allegro Networks MIME-version: 1.0 Content-type: text/plain; charset=us-ascii; format=flowed Content-transfer-encoding: 7bit User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; m18) Gecko/20001108 Netscape6/6.0 X-Accept-Language: en References: <4.2.2.20001207172221.00b49520@localhost> <3A3020F1.B1448231@hursley.ibm.com> Content-Transfer-Encoding: 7bit Sender: diffserv-admin@ietf.org Errors-To: diffserv-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Diffserv Discussion List X-BeenThere: diffserv@ietf.org Content-Transfer-Encoding: 7bit That's also exactly what I meant in my response. The "you" in my statement was meant to be Brian's helicopter, not a Marker element in the Model. But I'm still unclear if the Model draft needs to change. The only re-marking described is in 6.1 in the context of the things that a DSCP Marker element might do: "DSCP Markers are 1:1 elements which set a codepoint (e.g. the DSCP in an IP header). DSCP Markers may also act on unmarked packets (e.g. those submitted with DSCP of zero) or may re-mark previously marked packets." Would it be clearer instead to say something like: "DSCP Markers are 1:1 elements which set the DSCP in an IP header. DSCP Markers might, for example, act on packets that a previous Classifier element has deemed to be unmarked (e.g. because they were received from a non-Diffserv domain). They might also re-mark previously marked packets (e.g. those that a previous Classifier element has recognised as having valid DSCP values but which now need to be marked with a different one, perhaps because they failed to conform to a Meter)." Or should the Model, at this point, just not go there and say merely: "DSCP Markers are 1:1 elements which set the DSCP in an IP header." Joel wrote: > The problem is that the informal model actually says that one > might have a processing element that was allowed to be a marker, > but not a remarker I'm not quite sure which part of the Informal Model draft Joel is referring to (is it the "or" that you don't like? It was not meant to be an "exclusive or", just an "and/or") but perhaps my proposed re-wording above (using "also") helps clarify? But that still sits uneasily with Walter's statement that "It is clear that a marker just assigns a dscp for the first time" (perhaps I'm reading that statement in the wrong context?). Any more thoughts on this? I think we're in a rat-hole - should we perhaps work offline to clarify what it is that we're all mis-understanding? Andrew Brian E Carpenter wrote: > I certainly agree that the marker itself can have no idea, and need have > no idea, whether it is the first marker to mark a given packet - i.e. > there is no functional difference between marking and remarking. It's > only if you could watch the packets from a helicopter, and observe > them passing from a non-DS domain into a DS domain, that you would know > the difference. It's certainly a good idea to reflect this in the > documents. > > Brian > > "Joel M. Halpern" wrote: > >> As I said in another recent reply, I really believe that this is not the case. >> Even a human being looking from outside the box might well have trouble >> telling if a packet sitting at a marker is already marked or not. Suppose >> that one of the several paths to this marker goes through an earlier >> marker/meter sequence. Suppose that the customer SLA says that the >> customers diffserv marking will be respected. >> The device component is certainly in no position to tell the difference. >> It seems to me that this distinction is distracting and error prone. It >> can not translate to a difference in resulting behavior. >> >> Yours, >> Joel M. Halpern >> >> At 11:52 AM 12/7/00 -0800, Andrew Smith wrote: >> >> >>> I'm slightly confused as to whether I need to change anything in the Model >>> draft here: I think, to paraphrase Brian's answer, that there *is* such a >>> thing, conceptually, as an unmarked packet. You can tell, by implicit >>> context, whether a packet is or is not already "marked" (it's a "policy" >>> or "trust" thing, in the abstract sense of those terms). >>> >>> Do I have this right? >>> >>> Andrew Smith >>> (Diffserv Model draft editor) >>> >>> >>> Robert Moore wrote: >>> >>> >>>> In the DiffServ Informal Model, MIB, and PIB, there >>>> is a distinction drawn between a marker that marks >>>> unmarked packets, and one that remarks packets that >>>> had been marked previously. This distinction appears >>>> most clearly in section 6.1 of the Informal Model. >>>> The MIB and the PIB make it implicitly, by importing >>>> the terms "mark" and "remark" from the Informal Model. >>>> This distinction presupposes that among the packets >>>> coming into a marker, some can be identified as >>>> already marked, and others can be identified as >>>> unmarked. I don't believe that this is the case. >>>> In QDDIM, we have come down squarely on the side that >>>> says there is no such thing as an unmarked packet, and >>>> thus no distinction between packet marking and packet >>>> remarking. Every packet has one of 64 values, decimal >>>> 0 - 63, in the DSCP field. Each of these values, >>>> including 0, is a legitimate DSCP. So a DSCP marker >>>> always takes in a packet that is already marked with a >>>> DSCP, and marks (or remarks - which word we choose isn't >>>> important) the packet with another DSCP, which may or >>>> may not be the same DSCP as the one the packet had >>>> when it came into the marker. Based on this view, we >>>> removed from the MarkerService class in QDDIM a boolean >>>> property CanRemark, which said whether a marker was >>>> allowed to mark all packets, or only packets that were >>>> not already marked when they got to it. >>>> This is *almost* just a question of wordsmithing in the >>>> three diffserv WG documents. But not quite. If there is >>>> actual disagreement in the WG about whether there is such >>>> a thing as an unmarked packet, that is, a packet that's >>>> not marked with any DSCP, then the question should be >>>> discussed until the WG reaches a consensus one way or the >>>> other. Does everybody agree with the QDDIM team that >>>> there is no such thing as a packet unmarked with any DSCP? >>>> 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://www2.ietf.org/mail-archive/working-groups/diffserv/current/maillist.html From diffserv-admin@ietf.org Fri Dec 8 02:16:24 2000 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with SMTP id CAA19762 for ; Fri, 8 Dec 2000 02:16:24 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id BAA00422; Fri, 8 Dec 2000 01:56:22 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id BAA00393 for ; Fri, 8 Dec 2000 01:56:18 -0500 (EST) Received: from cisco.com (sigma.cisco.com [171.69.63.142]) by ietf.org (8.9.1a/8.9.1a) with SMTP id BAA06505 for ; Fri, 8 Dec 2000 01:56:18 -0500 (EST) Received: from andreawlap (sj-dial-4-8.cisco.com [171.68.181.137]) by cisco.com (8.8.8-Cisco List Logging/8.8.8) with SMTP id WAA16895; Thu, 7 Dec 2000 22:55:42 -0800 (PST) From: "Andrea Westerinen" To: "Robert Moore" , "Brian E Carpenter" Cc: Subject: RE: [Diffserv] Degree of detail in the DiffServ MIB Date: Thu, 7 Dec 2000 23:00:02 -0800 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2910.0) Importance: Normal In-Reply-To: X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2919.6700 Content-Transfer-Encoding: 7bit Sender: diffserv-admin@ietf.org Errors-To: diffserv-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Diffserv Discussion List X-BeenThere: diffserv@ietf.org Content-Transfer-Encoding: 7bit To comment on "how to do modeling" - modeling works best as a cooperative effort between the subject matter experts and the modeling experts. It requires use cases and clearly defined "goals." For example, the goal of QDDIM is to model "meters, markers, droppers, ... that participate in conditioning traffic." BTW, I thought that the informal model was very helpful in describing what happens in "conditioning traffic". An information model should do the same thing - only more "formally." Bob basically says this in his mail, below. Another advantage of having an information model is that you can use the model to organize the disparate data that comes from different MIBs/PIBs/.... The model puts the pieces in the right places and creates "the big picture." This is very valuable for a customer trying to do "network management" as opposed to only looking at "diffserv managment." Modeling assumes that there are similar concepts (systems/devices with services and interfaces) in all networking areas - and these "superclasses" should be defined and reused. Then, there are specific differences in specific domains (for example, meter and marker services versus IPsec protocol services). The modelers are there to help in the reuse and the organization of the classes. Often, questions that the modelers ask clarify the different assumptions and opinions of the subject matter experts. Note that the modeling process is also iterative (as all I-Ds seem to be :-). The modelers work with the experts and then jointly create a first pass definition - from there, you iterate until the model covers what is needed, and can be explained (and not apologized for :-). Andrea -----Original Message----- From: diffserv-admin@ietf.org [mailto:diffserv-admin@ietf.org]On Behalf Of Robert Moore Sent: Thursday, December 07, 2000 10:30 AM To: Brian E Carpenter Cc: 'diffserv@ietf.org' Subject: Re: [Diffserv] Degree of detail in the DiffServ MIB Brian, Part of the confusion here is that QDDIM is *not* a policy model, nor is it called one: its full name is "Information Model for Describing Network Device QoS Mechanisms for Differentiated Services." It came about as a result of two different impulses: 1. As a part of the Policy Framework WG's proof-of-concept "worked example," where we would show how to apply Core Policy to some specific domain. In this role it is a companion document to QPIM (which *is* a policy model), to let us illustrate the process by which a high-level policy gets mapped to lower-level device configuration. 2. In response to the desire for something more formal than "most of the authors overlap" to insure that the DiffServ MIB and PIB be consistent with each other. The Informal Model accomplishes this to some extent, but there has been interest in something more formal. This was part of the impetus behind NIM, which has now largely transferred over to SMIng. And it's the essence of what we have been doing in the Policy Framework WG: defining information models, which are then mapped to data models. By having a common starting point, it's guaranteed that the data models will all be consistent with each other. So that's what QDDIM is: the information model not for DiffServ policy, but for representing and configuring DiffServ mechanisms. Organizationally, we've got exactly the same question for information models that we had/have for MIBs, for PIBs, for LDAP schemas, for SMIng specifications, for...: who should define them -- the subject matter experts/WG, or a separate WG of experts in the particular modeling technology? As you know, there's no agreed-upon answer to this question. Two additional points: - I'm not in any way suggesting that you hold up the DiffServ documents -- just that the Diffserv WG consider updating then to reflect some of the things we did in QDDIM. - Given that DiffServ has no business touching the two Currently Unused bits, I'd *still* be more comfortable with an explicit statement that they're supposed to be left alone, rather than leaving it up to DiffServ implementers to reach this conclusion. Regards, Bob Bob Moore IBM Networking Software +1-919-254-4436 remoore@us.ibm.com Brian E Carpenter on 12/07/2000 12:48:25 PM To: Robert Moore/Raleigh/IBM@IBMUS cc: "'diffserv@ietf.org'" Subject: Re: [Diffserv] Degree of detail in the DiffServ MIB Bob, My question is explicitly about the level of detail in QDDIM. I don't understand why something called a policy model would even attempt to model or describe these details. It's a WG question because it creates a level of dependency of Policy documents on Diffserv documents that concerns me. I don't want to hear that we need to hold up Diffserv documents because of this dependency. It's intentional that we say nothing whatever about the Currently Unused bits in DiffServ documents. They don't belong to DiffServ so we should say nothing about them. Brian _______________________________________________ diffserv mailing list diffserv@ietf.org http://www1.ietf.org/mailman/listinfo/diffserv Archive: http://www2.ietf.org/mail-archive/working-groups/diffserv/current/maillist.html From diffserv-admin@ietf.org Fri Dec 8 09:06: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 SMTP id JAA18631 for ; Fri, 8 Dec 2000 09:06:48 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id IAA04553; Fri, 8 Dec 2000 08:39:06 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id IAA04453 for ; Fri, 8 Dec 2000 08:38:59 -0500 (EST) Received: from e21.nc.us.ibm.com (e21.nc.us.ibm.com [32.97.136.227]) by ietf.org (8.9.1a/8.9.1a) with SMTP id IAA15432 for ; Fri, 8 Dec 2000 08:38:56 -0500 (EST) Received: from southrelay02.raleigh.ibm.com (southrelay02.raleigh.ibm.com [9.37.3.209]) by e21.nc.us.ibm.com (8.9.3/8.9.3) with ESMTP id IAA52374; Fri, 8 Dec 2000 08:36:03 -0600 Received: from d04nm200.raleigh.ibm.com (d04nm200.raleigh.ibm.com [9.67.228.37]) by southrelay02.raleigh.ibm.com (8.8.8m3/NCO v4.95) with ESMTP id IAA128794; Fri, 8 Dec 2000 08:38:24 -0500 Importance: Normal Subject: Re: [Diffserv] Re: DSCP marking versus DSCP remarking To: Andrew Smith Cc: Brian E Carpenter , "Joel M. Halpern" , Walter Weiss , "'diffserv@ietf.org'" , policy@raleigh.ibm.com X-Mailer: Lotus Notes Release 5.0.3 (Intl) 21 March 2000 Message-ID: From: "Robert Moore" Date: Fri, 8 Dec 2000 08:43:05 -0500 X-MIMETrack: Serialize by Router on D04NM200/04/M/IBM(Release 5.0.3 (Intl)|21 March 2000) at 12/08/2000 08:38:54 AM 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 Andrew, My vote is definitely for the one-line version you give below. The problem with the paragraph version is that a Classifier is just as ignorant as a Marker about whether a packet is marked or unmarked. All the Classifier knows is that a packet does or does not match a filter like "DSCP = 13" or "DSCP = 0". Brian's helicopter might know whether a packet that matches one of these filters is marked. But the Classifier doesn't know this. Regards, Bob Bob Moore IBM Networking Software +1-919-254-4436 remoore@us.ibm.com Andrew Smith @ietf.org on 12/08/2000 12:03:41 AM Sent by: diffserv-admin@ietf.org To: Brian E Carpenter , "Joel M. Halpern" cc: Walter Weiss , "'diffserv@ietf.org'" , policy@raleigh.ibm.com Subject: Re: [Diffserv] Re: DSCP marking versus DSCP remarking That's also exactly what I meant in my response. The "you" in my statement was meant to be Brian's helicopter, not a Marker element in the Model. But I'm still unclear if the Model draft needs to change. The only re-marking described is in 6.1 in the context of the things that a DSCP Marker element might do: "DSCP Markers are 1:1 elements which set a codepoint (e.g. the DSCP in an IP header). DSCP Markers may also act on unmarked packets (e.g. those submitted with DSCP of zero) or may re-mark previously marked packets." Would it be clearer instead to say something like: "DSCP Markers are 1:1 elements which set the DSCP in an IP header. DSCP Markers might, for example, act on packets that a previous Classifier element has deemed to be unmarked (e.g. because they were received from a non-Diffserv domain). They might also re-mark previously marked packets (e.g. those that a previous Classifier element has recognised as having valid DSCP values but which now need to be marked with a different one, perhaps because they failed to conform to a Meter)." Or should the Model, at this point, just not go there and say merely: "DSCP Markers are 1:1 elements which set the DSCP in an IP header." Joel wrote: > The problem is that the informal model actually says that one > might have a processing element that was allowed to be a marker, > but not a remarker I'm not quite sure which part of the Informal Model draft Joel is referring to (is it the "or" that you don't like? It was not meant to be an "exclusive or", just an "and/or") but perhaps my proposed re-wording above (using "also") helps clarify? But that still sits uneasily with Walter's statement that "It is clear that a marker just assigns a dscp for the first time" (perhaps I'm reading that statement in the wrong context?). Any more thoughts on this? I think we're in a rat-hole - should we perhaps work offline to clarify what it is that we're all mis-understanding? Andrew Brian E Carpenter wrote: > I certainly agree that the marker itself can have no idea, and need have > no idea, whether it is the first marker to mark a given packet - i.e. > there is no functional difference between marking and remarking. It's > only if you could watch the packets from a helicopter, and observe > them passing from a non-DS domain into a DS domain, that you would know > the difference. It's certainly a good idea to reflect this in the > documents. > > Brian > > "Joel M. Halpern" wrote: > >> As I said in another recent reply, I really believe that this is not the case. >> Even a human being looking from outside the box might well have trouble >> telling if a packet sitting at a marker is already marked or not. Suppose >> that one of the several paths to this marker goes through an earlier >> marker/meter sequence. Suppose that the customer SLA says that the >> customers diffserv marking will be respected. >> The device component is certainly in no position to tell the difference. >> It seems to me that this distinction is distracting and error prone. It >> can not translate to a difference in resulting behavior. >> >> Yours, >> Joel M. Halpern >> >> At 11:52 AM 12/7/00 -0800, Andrew Smith wrote: >> >> >>> I'm slightly confused as to whether I need to change anything in the Model >>> draft here: I think, to paraphrase Brian's answer, that there *is* such a >>> thing, conceptually, as an unmarked packet. You can tell, by implicit >>> context, whether a packet is or is not already "marked" (it's a "policy" >>> or "trust" thing, in the abstract sense of those terms). >>> >>> Do I have this right? >>> >>> Andrew Smith >>> (Diffserv Model draft editor) >>> >>> >>> Robert Moore wrote: >>> >>> >>>> In the DiffServ Informal Model, MIB, and PIB, there >>>> is a distinction drawn between a marker that marks >>>> unmarked packets, and one that remarks packets that >>>> had been marked previously. This distinction appears >>>> most clearly in section 6.1 of the Informal Model. >>>> The MIB and the PIB make it implicitly, by importing >>>> the terms "mark" and "remark" from the Informal Model. >>>> This distinction presupposes that among the packets >>>> coming into a marker, some can be identified as >>>> already marked, and others can be identified as >>>> unmarked. I don't believe that this is the case. >>>> In QDDIM, we have come down squarely on the side that >>>> says there is no such thing as an unmarked packet, and >>>> thus no distinction between packet marking and packet >>>> remarking. Every packet has one of 64 values, decimal >>>> 0 - 63, in the DSCP field. Each of these values, >>>> including 0, is a legitimate DSCP. So a DSCP marker >>>> always takes in a packet that is already marked with a >>>> DSCP, and marks (or remarks - which word we choose isn't >>>> important) the packet with another DSCP, which may or >>>> may not be the same DSCP as the one the packet had >>>> when it came into the marker. Based on this view, we >>>> removed from the MarkerService class in QDDIM a boolean >>>> property CanRemark, which said whether a marker was >>>> allowed to mark all packets, or only packets that were >>>> not already marked when they got to it. >>>> This is *almost* just a question of wordsmithing in the >>>> three diffserv WG documents. But not quite. If there is >>>> actual disagreement in the WG about whether there is such >>>> a thing as an unmarked packet, that is, a packet that's >>>> not marked with any DSCP, then the question should be >>>> discussed until the WG reaches a consensus one way or the >>>> other. Does everybody agree with the QDDIM team that >>>> there is no such thing as a packet unmarked with any DSCP? >>>> 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://www2.ietf.org/mail-archive/working-groups/diffserv/current/maillist.html _______________________________________________ diffserv mailing list diffserv@ietf.org http://www1.ietf.org/mailman/listinfo/diffserv Archive: http://www2.ietf.org/mail-archive/working-groups/diffserv/current/maillist.html From diffserv-admin@ietf.org Fri Dec 8 10:02: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 SMTP id KAA25197 for ; Fri, 8 Dec 2000 10:02:03 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id JAA05255; Fri, 8 Dec 2000 09:32:35 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id JAA05223 for ; Fri, 8 Dec 2000 09:32:31 -0500 (EST) 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 SMTP id JAA21605 for ; Fri, 8 Dec 2000 09:32:31 -0500 (EST) 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 JAA10870; Fri, 8 Dec 2000 09:33:56 -0600 Received: from d04nm200.raleigh.ibm.com (d04nm200.raleigh.ibm.com [9.67.228.37]) by southrelay02.raleigh.ibm.com (8.8.8m3/NCO v4.95) with ESMTP id JAA97316; Fri, 8 Dec 2000 09:32:00 -0500 Importance: Normal Subject: Re: [Diffserv] Model draft - sharing elements on multiple interfaces To: Andrew Smith Cc: diffserv X-Mailer: Lotus Notes Release 5.0.3 (Intl) 21 March 2000 Message-ID: From: "Robert Moore" Date: Fri, 8 Dec 2000 09:36:41 -0500 X-MIMETrack: Serialize by Router on D04NM200/04/M/IBM(Release 5.0.3 (Intl)|21 March 2000) at 12/08/2000 09:32:30 AM 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 Andrew, OK, I like this picture a lot better than I liked mine. It does raise a question, though. What's the direction for those three interfaces that sit between the routing cores? Intuitively, they're egress from the point of view of "Routing Core", and ingress from the point of view of "Another Routing Core." So what do we call them? The question becomes harder when we look at the MIB. The diffServDataPathTable has two indexes: ifIndex and diffServDataPathIfDirection. For a given ifIndex, you're going to use up the two Direction values for the "real" ingress path on the interface (not shown in your picture), and for the egress path shown at the right in your picture. The only way out that I see is to define a third "direction," something like coreToCore, to identify the data paths in the middle of your picture. I recognize that this would be a fairly significant change to the model. But without it, I think you will have a picture of a configuration that the MIB is incapable of representing. Regards, Bob Bob Moore IBM Networking Software +1-919-254-4436 remoore@us.ibm.com Andrew Smith on 12/07/2000 02:43:09 PM To: Robert Moore/Raleigh/IBM@IBMUS cc: diffserv Subject: Re: [Diffserv] Model draft - sharing elements on multiple interfaces Bob, Without diving into the details for now, can we agree that, if the "ingress SLS shared over multiple interfaces" idea is interesting, then so is the *egress* one? Seems like some operations folks out there might be very interested in this .... no? (think: multi-tenant buildings, metro services?) Now diving into the details, the egress picture I would draw would be more like: +---------+ +----------+ | |i/f 1---\ | |--> i/f 1 | | \ |Another | |Routing |i/f 2----->meter-->|Routing |--> i/f 2 |Core | / |Core | | |i/f 3---/ | |--> i/f 3 +---------+ +----------+ It is of no business to the Diffserv elements how the traffic gets split back out to the interfaces on the r.h.s. so it is appropriate to model that function as a black box (in this Model document). A "Classifier" at that point is not the right functional block to perform the routing functions (which may be as simple as "do the same thing as the prior Routing Core did" - it's not our business to describe how it might do that). Andrew Robert Moore wrote: > Andrew, > > I'm still having trouble with the egress half of your > symmetric solution. Here's how I visualize your idea > of metering aggregated traffic across a set of egress > interfaces: > > +---------+ +----------+ > | |i/f 1---\ | |--> i/f 1 > | | \ | | > |Routing |i/f 2----->meter-->|classifier|--> i/f 2 > |Core | / | | > | |i/f 3---/ | |--> i/f 3 > +---------+ +----------+ > > In words, the Routing Core does whatever it does to > route packets (which is *outside* the scope of > DiffServ), and for each packet selects egress i/f > 1, 2, or 3. The data paths for these three egress > interfaces then merge into a single meter, to > provide the metering for the aggregated traffic. > The meter is followed by a classifier, which fans > the packets back out to their respective interfaces > for queueing, scheduling, etc. > > It's the classifier that I don't understand. If the > Routing Core selects an egress interface for a packet > based on routing criteria that are outside the scope of > DiffServ, then how can the classifier get each packet > back to the correct interface? What is it filtering > on? It can't base its decision on which interface > the packet traversed just before the meter, because > the model stipulates that a packet doesn't "remember" > where it has been. > > Do you have a different way of thinking about this > situation, one that doesn't run into this problem? > > Regards, > Bob > > Bob Moore > IBM Networking Software > +1-919-254-4436 > remoore@us.ibm.com > > > > Andrew Smith on 12/06/2000 01:38:08 PM > > To: Robert Moore/Raleigh/IBM@IBMUS > cc: diffserv > Subject: Re: [Diffserv] Model draft - sharing elements on multiple > interfaces > > > > Bob, > > I think you're trying to craft a compromise with Keith here but what you > propose > is inconsistent. [Note that I didn't mention the MIB in my message: the MIB > can > implement a subset of the model if it so chooses, so long as it is not > inconsistent with the model, but that's not the point I raised - by all > means > discuss the impact of this issue on the MIB in a separate thread but don't > let > that confuse this discussion of the model]. > > The point in question is whether "shared-between-multiple-interfaces" > elements > are both (a) useful for implementing specific services and (b) likely to be > implemented by more than one vendor and (c) without this change, does it > make it > impossible/unlikely that the model can be used to represent a significant > set of > devices? I believe that, for (a), the model needs to be symmetric: if such > a > service is useful for "in" then it is also for "out" e.g. metering on a > collection of interfaces representing one customer is just as useful in > both > directions. As regards (b), I'd like to hear some more opinions: so far the > exit > poll (3 opinions) seems to read: > > In? Out? > Y/N Y/N > 2/1 1/2 > > (if that notation makes sense). And for (c) I'm not sure we have any data > points. > > > Andrew > > > Robert Moore wrote: > > >> Keith, >> >> If I'm understanding you correctly, then I think I agree >> with you. We can allow the sharing of conditioning >> elements in the ingress case, but continue to rule it out >> for egress. This covers a case like a single meter that >> processes traffic aggregated from several ingress >> interfaces, which seems like something we want to allow. >> But it doesn't complicate the MIB in the egress case. >> >> If we allow sharing of conditioning elements for ingress >> interfaces, I think there are two cases that need to be >> mentioned in the MIB: >> >> - Two DataPathStart pointers pointing to the same >> element. If we leave it at that, we have no answer >> to the question "Which data path is the element >> *really* on?" But I think this is OK -- we can >> say that it's equally on both data paths. >> - A "next" pointer in a conditioning element pointing >> to a next conditioning element on a different >> data path. >> >> The MIB would also have to say clearly that these two >> options are *not* allowed for egress data paths. >> >> For Andrew's picture, I think it would be fine to >> combine the new version for the ingress side with the >> old version for the egress side. >> >> Does this sound good to everybody? >> >> Regards, >> Bob >> >> Bob Moore >> IBM Networking Software >> +1-919-254-4436 >> remoore@us.ibm.com >> >> >> >> Keith McCloghrie @ietf.org on 12/05/2000 05:19:33 PM >> >> Sent by: diffserv-admin@ietf.org >> >> >> To: Robert Moore/Raleigh/IBM@IBMUS >> cc: kzm@cisco.com (Keith McCloghrie), andrew@allegronetworks.com > > (Andrew > >> Smith), diffserv@ietf.org (diffserv) >> Subject: Re: [Diffserv] Model draft - sharing elements on multiple >> interfaces >> >> >> >> Bob, >> >> I was arguing against additional complexity, which was what I believed >> would ensue from Andrew's proposed change from: >> >> >> >>>> -> I -> core -> E -> >>>> >>>> The proposal would be to modify this to something like: >>>> >>>> -> I -+-> I -> core -> E -+-> E -> >>>> | | >>>> -> I -+ +-> E -> >>> >> I think it would be possible to allow merging on ingress just by >> removing the restriction on two data paths merging, which is stated >> in this ASN.1 comment (I think that's the only place it's specified): >> >> -- The use of next pointer to point to diffserv functional datapath >> -- element of a different datapath is not allowed >> >> I agree it's harder for egress which requries splitting, for which >> I think the current MIB structure is insufficient, and my concern is >> that a MIB structure which would allow it is going to be more complex. >> >> Keith. >> >> >> >> >>> Keith, >>> >>> I'm not sure what you're arguing for here. At least >>> on the ingress side, sharing an element (say a >>> Classifier) between two ingress interfaces amounts >>> to having the dataPathStart pointers for two entries >>> in the dataPathTable point to the same entry in the >>> diffServClassifier table. Are you saying that the MIB >>> currently rules this out? If so, I've missed it. Or >>> are you saying that while the MIB doesn't currently >>> rule it out, it should be changed so that it does? >>> >>> It's a little harder to describe for egress, but I >>> think the idea would be that two Data Paths start out >>> together, but then somehow diverge before they're done. >>> I'm not sure exactly how to express this in terms of >>> the Next pointers, but the same question I asked you >>> above applies here as well: do you think that the MIB >>> currently does outlaw this setup, or do you think that >>> it should (but doesn't now)? >>> >>> Thanks. >>> >>> 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://www2.ietf.org/mail-archive/working-groups/diffserv/current/maillist.html From diffserv-admin@ietf.org Fri Dec 8 10:24: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 SMTP id KAA27795 for ; Fri, 8 Dec 2000 10:24:32 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id JAA05643; Fri, 8 Dec 2000 09:59:54 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id JAA05616 for ; Fri, 8 Dec 2000 09:59:49 -0500 (EST) Received: from longsys.com (dmz.longsys.com [63.111.150.5]) by ietf.org (8.9.1a/8.9.1a) with SMTP id JAA24912 for ; Fri, 8 Dec 2000 09:59:49 -0500 (EST) Received: from joel (discordian.longsys.com [63.111.150.74]) by longsys.com (8.10.0/8.10.0) with ESMTP id eB8ExZ928653; Fri, 8 Dec 2000 14:59:35 GMT Message-Id: <4.2.2.20001208095537.00b67390@localhost> X-Sender: joel@localhost X-Mailer: QUALCOMM Windows Eudora Pro Version 4.2.2 Date: Fri, 08 Dec 2000 09:57:23 -0500 To: Andrew Smith , Brian E Carpenter From: "Joel M. Halpern" Subject: Re: [Diffserv] Re: DSCP marking versus DSCP remarking Cc: Walter Weiss , "'diffserv@ietf.org'" , policy@raleigh.ibm.com In-Reply-To: <3A306BAD.5090308@allegronetworks.com> References: <4.2.2.20001207172221.00b49520@localhost> <3A3020F1.B1448231@hursley.ibm.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: diffserv-admin@ietf.org Errors-To: diffserv-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Diffserv Discussion List X-BeenThere: diffserv@ietf.org On the question fo whether to refer to markers and re-markers in teh description of the marker action element, I would prefer that we went with: At 09:03 PM 12/7/00 -0800, Andrew Smith wrote: >Or should the Model, at this point, just not go there and say merely: > "DSCP Markers are 1:1 elements which set the DSCP in an IP header." If we want to mention the omniscient view-point distinction petween marking and remarking it would go in some text that talks about the fact that the entire processing stream may be different for packets considered to have been processed (marked) from those which have not been sanitized as it were. Yours, Joel M. Halpern _______________________________________________ diffserv mailing list diffserv@ietf.org http://www1.ietf.org/mailman/listinfo/diffserv Archive: http://www2.ietf.org/mail-archive/working-groups/diffserv/current/maillist.html From diffserv-admin@ietf.org Fri Dec 8 12:27: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 SMTP id MAA20895 for ; Fri, 8 Dec 2000 12:27:39 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id LAA07265; Fri, 8 Dec 2000 11:18:45 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id LAA07234 for ; Fri, 8 Dec 2000 11:18:41 -0500 (EST) Received: from usc.edu (root@usc.edu [128.125.253.136]) by ietf.org (8.9.1a/8.9.1a) with SMTP id LAA04964 for ; Fri, 8 Dec 2000 11:18:38 -0500 (EST) Received: from aludra.usc.edu (demir@aludra.usc.edu [128.125.253.184]) by usc.edu (8.9.3.1/8.9.3/usc) with ESMTP id IAA06203; Fri, 8 Dec 2000 08:18:40 -0800 (PST) Received: from localhost (demir@localhost) by aludra.usc.edu (8.9.3.1/8.9.3/usc) with ESMTP id IAA27208; Fri, 8 Dec 2000 08:18:39 -0800 (PST) Date: Fri, 8 Dec 2000 08:18:39 -0800 (PST) From: demir To: Bruce Davie cc: diffserv@ietf.org Subject: Re: [Diffserv] Possible compromise between EFRESOLVE and draft-charny In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: diffserv-admin@ietf.org Errors-To: diffserv-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Diffserv Discussion List X-BeenThere: diffserv@ietf.org I think to understand "burstiness" requires understanding the network toplogy and "burstiness" on a hop. Using B instead of MTU (in EFRESOLVE) solves the "burstiness" problem. However, I think it won't achieve "optimum" delay bound (should I say "efficient", "well defined"?) without "understanding" support and achieving this requires some research. How I see the new B is, it takesEFRESOLVE one step further. The easiest way to bound delay is: D(i) < bound_function(i, ...) bound_function(i) = a_constant To me new suggestion takes one step more on the way, but still has the problem of "sacrifice". It seems it is more general to leave the bound_function alone. I assume there would be a trend on selecting a bound_function. It could be the this new suggested one. However, it seems it has "danger(s)" to be standardized. - I have made this point before (I hope Brian won't get mad at me): AF PHB has only "queuing and discard" behavior. Whereas "EF" is obseses with "delay bound" (That is fine with me). It is okay to "drop" packets (I assume this is valid for all PHBs). To me, this is a "base" behavior and it should be okay to combine some set of PHBs if one wants to describe a new behavior (object-oriented approach). It seems, this is missing. Each PHB is isolating itself from each other. This can be a "fundamental" change. I think this is a nice property and "makes the archirecture" more general. Alper K. Demir On Thu, 7 Dec 2000, Bruce Davie wrote: > > We (the draft-charny authors) would like to propose a possible compromise > EF definition which we think should reconcile the differences between the > current definitions of draft-charny and EFRESOLVE. We think that it > addresses all the criticisms that have been raised to date of both existing > definitions, and satisfies the goals expressed in both drafts and RFC 2598. > > The major criticism of draft-charny was that it didn't provide any bound on > the delay of an individual packet. This is because the definition only > requires that EF packets leave the node at something close to the > configured rate R. There is no requirement that EF packets are served in > FIFO order, and thus, as long as new packets keep arriving fast enough, an > individual packet could live inside a node forever without violating the > definition. (This property is shared by RFC 2598). > > Among the criticisms of EFRESOLVE were > > - it doesn't define behavior of a node outside of its operating region > - non-FIFO treatment of EF will typically lead to a large value of S > - S is not a good figure of merit, since non-ideal scheduling and non-FIFO > service are lumped in the same parameter; also very good devices with large > number of ports will look worse than small devices with bad scheduling > implementations > - it is not yet clear how to generalize the defintion to the multiple input, > multiple output case > - it allows arbitrarily large fixed delay (which isn't visible in a figure > of merit) > > While we stand by these criticisms, we also recognize that the ability to > describe the delay bound on a per-packet basis under certain operating > conditions may be quite useful in constructing certain PDB's based on EF. > To address this, we propose to "clone" the original equations of > draft-charny. The original equations remain part of the definition, and we > now rename the error term E as E_a (aggregate error). We call this the > "colorblind" definition because it pays no attention to individual EF > packets. This part of the definition simply tells you how well the device > does at serving aggregate EF traffic at the configured rate - small E_a > means a better scheduler in this regard. (See the new > draft-charny-ef-definition-01.txt for more on the intuitive meaning of the > definition.) This part of the definition closely approximates the original > RFC 2598 definition, in that it admits all the implementations that were > mentioned in that RFC; it also gives a better figure of merit to > implementations that are intuitively "better" at delivering EF service at a > configured rate, e.g. a priority queue. > > The extra set of new equations looks just like the old ones but with one > difference: this second part of the definition pays attention to individual > packets so that we can bound the delay experienced by an individual packet. > We call this the "color-aware" definition, because you can think of each > packet as being uniquely colored as it enters a node and then the time at > which that > actual packet leaves the node is noted. The new error term from these > equations is called E_p (packet error, as distinct from E_a). With this > second part of the definition, the delay experienced by a single packet is > bounded by B/R +E_p, where B is the bound on the burstiness of the input > traffic and R is the configured rate. Hence, as long as the rate and > burstiness of traffic that arrives at an output are bounded, the delay is > also bounded. > > This additional part of the definition bears many similarities to the > EFRESOLVE definition. To get bounded and well-defined behavior under > EFRESOLVE, there need to be some constraints on the total offered traffic > destined for an output in terms of rate and burstiness. Under such > conditions, the per-packet delay is S*MTU/R plus the minimum fixed delay of > the device. Similarly, under our "color-aware" definition when the offered > load to an output is bounded by rate R and burst size B, the maximum > per-packet delay is B/R + E_p. Clearly both definitions provide bounded > delay under well-defined operating conditions. The second part of our > definition addresses the intent of EFRESOLVE, but differs from EFRESOLVE in > that it provides well-defined behavior for arbitrary inputs. In addition > while EFRESOLVE gives a fixed delay within a specified operating region, > our new definition allows an operator to achieve different performance goals > by specifying different ranges of B and R that achieve the desired delay > bounds. > > The first part of the definition allows existing and operational rate-based > implementations and deployments of the EF PHB to continue to be deployed > and operated (e.g EF implementation in Internet 2 managed by Bandwidth > Brokers). The second part of the definition provides the machinery for > computing the delay bound as a function of the operating conditions. > > In summary, we think this addition to draft-charny addresses all the > criticisms made of that draft (except that it was too hard to understand) > and also avoids the problems of EFRESOLVE, while addressing its goals. We'll > address the "hard to understand" part in the WG meeting and, if necessary, > in another version of the draft. > > We're hoping that we might be able to get WG consensus behind this > compromise. > > Bruce Davie (on behalf of 12 co-authors of draft-charny) > > > ---------- > Equations for those who care: > > The original colorblind equations from draft-charny-...-01 are eq_1a and > eq_2a. The new ones that achieve the compromise are eq_1b and eq_2b. > Although the latter equations are not in draft-charny...01, the intuitive > description of the equations in that draft may still be helpful in > understanding the equations. > > D(j) <= F(j) + E_a (eq_1a) > d(j) <= f(j) + E_p (eq_1b) > > where F(j) and f(j) are defined iteratively by > > F(0)=0, D(0) = 0 > f(0)=0, d(0) = 0 > > > F(j)=max(a(j), min(D(j-1), F(j-1)))+ L(j)/R, for all j>0 (eq_2a) > f(j)=max(a(j), min(d(j-1), f(j-1)))+ l(j)/R for all j>0 (eq_2b) > > > Here: > > D(j) is the time that the last bit of the j-th EF packet to depart from I > actually leaves the node. > d(j) is the time the last bit of the j-th packet to arrive for I from any > input interface actually leaves the node. > F(j) is the target departure (finishing) time for the j-th EF packet to > depart from I. > f(j) is the target departure (finishing) time for the departure of the j-th > packet in an ideal FIFO server. > a(j) is the time that the last bit of the j-th EF packet destined for I to > arrive to the device actually arrives at the node. > L(j) is the size of the j-th EF packet to depart from I. > l(j) is the size of the j-th EF packet destined for I to arrive to the > device. > R is the EF configured rate at I (in bits/second) > > > > _______________________________________________ > diffserv mailing list > diffserv@ietf.org > http://www1.ietf.org/mailman/listinfo/diffserv > Archive: http://www2.ietf.org/mail-archive/working-groups/diffserv/current/maillist.html > _______________________________________________ diffserv mailing list diffserv@ietf.org http://www1.ietf.org/mailman/listinfo/diffserv Archive: http://www2.ietf.org/mail-archive/working-groups/diffserv/current/maillist.html From diffserv-admin@ietf.org Fri Dec 8 13:36: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 SMTP id NAA01955 for ; Fri, 8 Dec 2000 13:36:19 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id MAA08597; Fri, 8 Dec 2000 12:56:06 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id MAA08565 for ; Fri, 8 Dec 2000 12:56:02 -0500 (EST) 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 MAA27139 for ; Fri, 8 Dec 2000 12:56:02 -0500 (EST) Received: from grubby.research.bell-labs.com ([135.104.2.9]) by dirty; Fri Dec 8 12:55:25 EST 2000 Received: from mail1.pa.bell-labs.com ([135.250.8.11]) by grubby; Fri Dec 8 12:55:24 EST 2000 Received: from research.bell-labs.com (ex-vpn65.pa.bell-labs.com [135.250.1.65]) by mail1.pa.bell-labs.com (Mirapoint) with ESMTP id AAW12851 (AUTH gja); Fri, 8 Dec 2000 09:55:21 -0800 (PST) Message-ID: <3A3120D4.25BB521@research.bell-labs.com> Date: Fri, 08 Dec 2000 09:56:36 -0800 From: Grenville Armitage Organization: Bell Labs Research Silicon Valley X-Mailer: Mozilla 4.61 [en] (WinNT; U) X-Accept-Language: en MIME-Version: 1.0 To: "'diffserv@ietf.org'" CC: policy@raleigh.ibm.com Subject: Re: [Diffserv] Re: DSCP marking versus DSCP remarking References: <4.2.2.20001207172221.00b49520@localhost> <3A3020F1.B1448231@hursley.ibm.com> <4.2.2.20001208095537.00b67390@localhost> 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 concur with the Joel's support for the short form text Andrew proposed below. Arguably the DSCP is always set by someone, it is merely a question of whether you (the router) agree with the value to which it was set. 'Marking' reflects a belief that the current DSCP was initialized by a NON-diffserv-aware/compliant process (e.g. accidentally in someone's OS, etc...). 'Remarking' reflects the belief that the DSCP was previously set by a diffserv-aware process, but you now possibly disagree with the choice of DSCP (e.g. your metering stage indicates packet should have a different drop precedence, etc) Yet in either case, the functional element is simply assigning a DSCP to a packet (with no inherent sense of a packet's temporal or topological history). cheers, gja "Joel M. Halpern" wrote: > > On the question fo whether to refer to markers and re-markers in teh > description of the marker action element, I would prefer that we went with: > > At 09:03 PM 12/7/00 -0800, Andrew Smith wrote: > >Or should the Model, at this point, just not go there and say merely: > > "DSCP Markers are 1:1 elements which set the DSCP in an IP header." > > If we want to mention the omniscient view-point distinction petween marking > and remarking it would go in some text that talks about the fact that the > entire processing stream may be different for packets considered to have > been processed (marked) from those which have not been sanitized as it were. > > Yours, > Joel M. Halpern > > _______________________________________________ > diffserv mailing list > diffserv@ietf.org > http://www1.ietf.org/mailman/listinfo/diffserv > Archive: http://www2.ietf.org/mail-archive/working-groups/diffserv/current/maillist.html -- ________________________________________________________________________ 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://www2.ietf.org/mail-archive/working-groups/diffserv/current/maillist.html From diffserv-admin@ietf.org Fri Dec 8 14:05:31 2000 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with SMTP id OAA10928 for ; Fri, 8 Dec 2000 14:05:31 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id NAA09243; Fri, 8 Dec 2000 13:36:08 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id NAA09222 for ; Fri, 8 Dec 2000 13:36:04 -0500 (EST) Received: from mailman.packetdesign.com (dns.PACKETDESIGN.NET [216.15.46.10]) by ietf.org (8.9.1a/8.9.1a) with SMTP id NAA01920 for ; Fri, 8 Dec 2000 13:36:03 -0500 (EST) Received: from packetdesign.com (dhcp-168-0-13.packetdesign.com [192.168.0.13]) by mailman.packetdesign.com (8.11.0/8.11.0) with ESMTP id eB8IZUQ23101; Fri, 8 Dec 2000 10:35:30 -0800 (PST) (envelope-from nichols@packetdesign.com) Message-ID: <3A312CBD.D2F5CD2F@packetdesign.com> Date: Fri, 08 Dec 2000 10:47:25 -0800 From: Kathleen Nichols X-Mailer: Mozilla 4.73 [en] (X11; I; Linux 2.2.12 i386) X-Accept-Language: en MIME-Version: 1.0 To: Bruce Davie CC: diffserv@ietf.org Subject: Re: [Diffserv] Possible compromise between EFRESOLVE and draft-charny References: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: diffserv-admin@ietf.org Errors-To: diffserv-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Diffserv Discussion List X-BeenThere: diffserv@ietf.org Content-Transfer-Encoding: 7bit Bruce Davie wrote: > > We (the draft-charny authors) would like to propose a possible compromise > EF definition which we think should reconcile the differences between the > current definitions of draft-charny and EFRESOLVE. We think that it > addresses all the criticisms that have been raised to date of both existing > definitions, and satisfies the goals expressed in both drafts and RFC 2598. But the EFresolve document does specify the PHB intended in 2598, so it is "complete". So why is a "compromise document" needed? After all, the EFresolve team WAS the "compromise". What purpose do you have in prolonging this? If you do not like the PHB of 2598/EFresolve, you may certainly propose yours. The criticisms of draft-charny have to do with it not being EF, which it purports to be. It is completely reasonable to rewrite 2598 to say what was intended, but it is really too late to take the existing well-established name and attach it to something else. >The major criticism of draft-charny was that it didn't provide any bound on >the delay of an individual packet. ... No, a *major* difference of draft-charny and EF is that the PHB proposed by draft-charny doesn't bound the delay variation. This is what both Guven and Van said in Pittsburgh. ... > > Among the criticisms of EFRESOLVE were > > - it doesn't define behavior of a node outside of its operating region Do you really mean what the above statement says? (I used to wonder why they put those stickers on hair dryers that say "do not operate underwater".) > - non-FIFO treatment of EF will typically lead to a large value of S > - S is not a good figure of merit, since non-ideal scheduling and non-FIFO > service are lumped in the same parameter; also very good devices with large > number of ports will look worse than small devices with bad scheduling > implementations It doesn't matter what the value is, it DOES matter that the potential user know what it is so as to know if it will suffice for the purpose desired. A device is not "bad" if it serves the purpose; a device is not "good" if it doesn't serve the purpose. This is very key to the intention of the EF PHB. A device should deliver that behavior under whatever configuration it is to be used in. > - it is not yet clear how to generalize the defintion to the multiple input, > multiple output case > - it allows arbitrarily large fixed delay (which isn't visible in a figure > of merit) This is a red herring: first, "arbitrarily large" delays do show up in the internet: transcontinental links are not banned or limited in length. Further, it is not important for a differentiated services PHB to bound the delay if it isn't a critical property of the PHB. A box with a delay that is not appropriate and competitive is not going to find a market for long. Diffserv PHBs are not meant to replace the other standards by which vendors and their customers buy a box. If so, we'd have to put a long list of specs that aren't about what *distinguishes* this PHB. Kathie (speaking only for myself at present) _______________________________________________ diffserv mailing list diffserv@ietf.org http://www1.ietf.org/mailman/listinfo/diffserv Archive: http://www2.ietf.org/mail-archive/working-groups/diffserv/current/maillist.html From diffserv-admin@ietf.org Fri Dec 8 15:20: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 SMTP id PAA09511 for ; Fri, 8 Dec 2000 15:20:13 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id OAA10614; Fri, 8 Dec 2000 14:40:49 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id OAA10583 for ; Fri, 8 Dec 2000 14:40:45 -0500 (EST) Received: from pilgrim.cisco.com (pilgrim.cisco.com [171.69.204.12]) by ietf.org (8.9.1a/8.9.1a) with SMTP id OAA24187 for ; Fri, 8 Dec 2000 14:40:43 -0500 (EST) Received: from bdaviepc.cisco.com (ch2-dhcp134-176.cisco.com [161.44.134.176]) by pilgrim.cisco.com (8.8.8-Cisco List Logging/8.8.8) with SMTP id OAA21937; Fri, 8 Dec 2000 14:40:07 -0500 (EST) From: "Bruce Davie" To: Cc: Subject: RE: [Diffserv] Possible compromise between EFRESOLVE and draft-charny Date: Fri, 8 Dec 2000 14:40:23 -0500 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2910.0) In-Reply-To: <3A312CBD.D2F5CD2F@packetdesign.com> Importance: Normal 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 Kathie, > > But the EFresolve document does specify the PHB intended in 2598, so it > is "complete". That is your opinion. My opinion is that it does not. You may claim to know the intent of RFC2598 better than I do, since you were a co-author, but since the RFC is the product of a working group, I think it is the job of the WG to decide whether EFRESOLVE adequately defines the PHB intended when the WG agreed to advance the RFC to proposed standard. At least 12 members of the WG have not yet reached the conclusion that it does. > So why is a "compromise document" needed? After all, the > EFresolve team WAS the "compromise". What purpose do you have in > prolonging > this? If you do not like the PHB of 2598/EFresolve, you may certainly > propose yours. The criticisms of draft-charny have to do with it not > being EF, which it purports to be. It is completely reasonable to > rewrite > 2598 to say what was intended, but it is really too late to take the > existing well-established name and attach it to something else. Again, this is just my opinion, but I think that EFRESOLVE does exactly that - takes the PHB name of RFC2598 and attaches it to something else. > > >The major criticism of draft-charny was that it didn't provide > any bound on > >the delay of an individual packet. ... > > No, a *major* difference of draft-charny and EF is that the PHB proposed > by draft-charny doesn't bound the delay variation. This is what both > Guven and Van said in Pittsburgh. Apologies for the confusion. It has been criticized both for its inability to bound per-packet delay and its inability to bound the variation of that delay. The new compromise definition provides both these bounds. > > ... > > > > Among the criticisms of EFRESOLVE were > > > > - it doesn't define behavior of a node outside of its operating region > > Do you really mean what the above statement says? (I used to wonder why > they put those stickers on hair dryers that say "do not operate > underwater".) I'm not sure how far we want to go with that analogy. I would be interested in a hair dryer warning that said "underwater use may lead to electrocution" and another one that said "underwater use is safe for you but bad for the hairdryer". The problem with EFRESOLVE is that it may be quite valid to use the device outside of the restricted region that the draft allows (e.g. due to rare but possible arrivals outside the maximum burst tolerace) and it would seem better to have some idea of what happens in that case. > > > - non-FIFO treatment of EF will typically lead to a large value of S > > - S is not a good figure of merit, since non-ideal scheduling > and non-FIFO > > service are lumped in the same parameter; also very good > devices with large > > number of ports will look worse than small devices with bad scheduling > > implementations > > It doesn't matter what the value is, it DOES matter that the potential > user know what it is so as to know if it will suffice for the purpose > desired. > A device is not "bad" if it serves the purpose; a device is not "good" > if it doesn't serve the purpose. This is very key to the intention of > the EF PHB. A device should deliver that behavior under whatever > configuration it is to be used in. And the problem is that because S covers so many different forms of deviation from "ideal" behavior I can't tell if a device is suitable for my purposes or not just by knowing S. > > > - it is not yet clear how to generalize the defintion to the > multiple input, > > multiple output case > > - it allows arbitrarily large fixed delay (which isn't visible > in a figure > > of merit) > > This is a red herring: first, "arbitrarily large" delays do show up in > the internet: transcontinental links are not banned or limited in > length. > Further, it is not important for a differentiated services > PHB to bound the delay if it isn't a critical property of the PHB. A > box with a delay that is not appropriate and competitive is not going to > find a market for long. Diffserv PHBs are not meant to replace the other > standards by which vendors and their customers buy a box. If so, we'd > have to put a long list of specs that aren't about what *distinguishes* > this PHB. Fair enough. Bruce > > Kathie (speaking only for myself at present) > _______________________________________________ diffserv mailing list diffserv@ietf.org http://www1.ietf.org/mailman/listinfo/diffserv Archive: http://www2.ietf.org/mail-archive/working-groups/diffserv/current/maillist.html From diffserv-admin@ietf.org Fri Dec 8 18:08:33 2000 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with SMTP id SAA24887 for ; Fri, 8 Dec 2000 18:08:33 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id RAA12971; Fri, 8 Dec 2000 17:38:52 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id RAA12944 for ; Fri, 8 Dec 2000 17:38:48 -0500 (EST) Received: from usc.edu (root@usc.edu [128.125.253.136]) by ietf.org (8.9.1a/8.9.1a) with SMTP id RAA17951 for ; Fri, 8 Dec 2000 17:38:47 -0500 (EST) Received: from sal-sun005.usc.edu (demir@sal-sun005.usc.edu [128.125.5.75]) by usc.edu (8.9.3.1/8.9.3/usc) with ESMTP id OAA14558; Fri, 8 Dec 2000 14:38:46 -0800 (PST) Received: from localhost (demir@localhost) by sal-sun005.usc.edu (8.9.3.1/8.9.3/usc) with ESMTP id OAA08083; Fri, 8 Dec 2000 14:38:46 -0800 (PST) Date: Fri, 8 Dec 2000 14:38:46 -0800 (PST) From: demir To: Bruce Davie cc: diffserv@ietf.org Subject: Re: [Diffserv] Possible compromise between EFRESOLVE and draft-charny In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: diffserv-admin@ietf.org Errors-To: diffserv-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Diffserv Discussion List X-BeenThere: diffserv@ietf.org > I think to understand "burstiness" requires understanding the network > toplogy and "burstiness" on a hop. Using B instead of MTU (in Ooops. I meant using B instead of S*MTU+E(i)*R.... Alper K. Demir _______________________________________________ diffserv mailing list diffserv@ietf.org http://www1.ietf.org/mailman/listinfo/diffserv Archive: http://www2.ietf.org/mail-archive/working-groups/diffserv/current/maillist.html From diffserv-admin@ietf.org Fri Dec 8 19:00:52 2000 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with SMTP id TAA12223 for ; Fri, 8 Dec 2000 19:00:52 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id SAA13673; Fri, 8 Dec 2000 18:40:28 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id SAA13644 for ; Fri, 8 Dec 2000 18:40:24 -0500 (EST) Received: from usc.edu (root@usc.edu [128.125.253.136]) by ietf.org (8.9.1a/8.9.1a) with SMTP id SAA05697 for ; Fri, 8 Dec 2000 18:40:22 -0500 (EST) Received: from koh-sun005.usc.edu (demir@koh-sun005.usc.edu [128.125.5.185]) by usc.edu (8.9.3.1/8.9.3/usc) with ESMTP id PAA05876; Fri, 8 Dec 2000 15:40:21 -0800 (PST) Received: from localhost (demir@localhost) by koh-sun005.usc.edu (8.9.3.1/8.9.3/usc) with ESMTP id PAA17977; Fri, 8 Dec 2000 15:40:20 -0800 (PST) Date: Fri, 8 Dec 2000 15:40:19 -0800 (PST) From: demir To: Bruce Davie cc: diffserv@ietf.org Subject: Re: [Diffserv] Possible compromise between EFRESOLVE and draft-charny In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: diffserv-admin@ietf.org Errors-To: diffserv-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Diffserv Discussion List X-BeenThere: diffserv@ietf.org I agrre with Katie's points. In addition to that, I think it should be "avoided" using "topology-dependent" parameters. - Let's assume that B = EF_buffer_size (why an operator choses such a thing? I don't know. I guess laziness). This will operate same as without using any "delay constraints". - B on a hop depends on the B(s) from where traffic comes and so on + traffic contitioning actions taken at the edge. In order to "utilize" the the "delay" using B, a PHB should aware of both previous B(s) + traffic contidioning actions taken for the aggregate + how this traffic is distributed to output interfaces within the hop (this is not a problem, but requires some additional mechanisms). - It seems this is a parameter that can be used by a PDB not by a PHB. - My question: is this fine with Diffserv Architecture? If so, there could be two different PHBs. One is "unutilized delay bound" PHB and the other one is "unutilized delay variance" PHB (in general this is the subset of the previous PHB). However, I think both will be subset of current EF PHB with supporting PDBs. - I believe that though current EF has its problems on achieving "delay bound", this problem can be attacked by a PDB. I don't understand why this is an "obsession" for EF PHB (I am aware of service requirement. My point is why "embed" the "service" into a PHB. Diffserv PHB is more than that, isn't it?). Alper K. Demir _______________________________________________ diffserv mailing list diffserv@ietf.org http://www1.ietf.org/mailman/listinfo/diffserv Archive: http://www2.ietf.org/mail-archive/working-groups/diffserv/current/maillist.html From diffserv-admin@ietf.org Fri Dec 8 20:44: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 SMTP id UAA03086 for ; Fri, 8 Dec 2000 20:44:59 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id UAA14771; Fri, 8 Dec 2000 20:23:47 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id UAA14744 for ; Fri, 8 Dec 2000 20:23:42 -0500 (EST) Received: from mercury.lcs.mit.edu (mercury.lcs.mit.edu [18.26.0.122]) by ietf.org (8.9.1a/8.9.1a) with SMTP id UAA00628 for ; Fri, 8 Dec 2000 20:23:41 -0500 (EST) Received: from [18.26.0.167] (sinope.lcs.mit.edu [18.26.0.167]) by mercury.lcs.mit.edu (8.9.1/8.9.1) with ESMTP id UAA17336; Fri, 8 Dec 2000 20:23:20 -0500 (EST) Mime-Version: 1.0 X-Sender: jtw_ds@mercury.lcs.mit.edu Message-Id: In-Reply-To: <3A2FC261.6FE20BA2@hursley.ibm.com> References: <3A2EC561.41FE1997@packetdesign.com> <3A2FC261.6FE20BA2@hursley.ibm.com> Date: Fri, 8 Dec 2000 20:25:14 -0500 To: Brian E Carpenter , Kathleen Nichols From: John Wroclawski Subject: Re: [Diffserv] EFRESOLVE definition in the presence of excess inputburstiness Cc: demir , John Schnizlein , diffserv@ietf.org Content-Type: text/plain; charset="us-ascii" ; format="flowed" Sender: diffserv-admin@ietf.org Errors-To: diffserv-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Diffserv Discussion List X-BeenThere: diffserv@ietf.org At 11:01 AM -0600 12/7/00, Brian E Carpenter wrote: >And don't forget that DiffServ totally inverts the meaning of the words >"service" and "behavior" compared to IntServ. > > Brian This is true. Just wanted to note that the text snippet quoted below was using meanings much closer to the diffserv terminology than the intserv terminology. (BTW not intentionally; we meant to stick as close to intserv terminology as we could so as not to create the inversion you point out, but screwed up.) It does seem to me that there is a difference of tone between EF and the other PHB's, in that EF _was_ proposed "with a particular service in mind", so it seems completely reasonable to be sure that the definition is above all well and carefully suited for that service. Nothing wrong with that, particularly if the service is a widely popular one. In contrast, the AF precursor we wrote about was proposed with the goal of being a flexible building block for a wider range of less closely related services. Examples include olympic, quantitative capacity profiles, a statistically strong low-delay service, etc. For a PHB with this bias, the definition ought to be targeted more at wide reuse than at having a particular service in mind. But I don't think this difference in bias makes such a PHB either more or less appropriate than a PHB that needs to be narrowly targeted to do what it was designed for. They're just different critters, is all. John >Kathleen Nichols wrote: >> >> demir wrote: >> > >> ... I agree that Diffserv chose to define a >> > small set of mechanisms first, not services. That's how a QoS architecture >> > should be. I am arguing about this "implicit agreement" if there is >> > such a thing. If there is, it should be an "explicit aggrement". >> >> I may be missing the point here, but I think if you read the diffserv >> charter, this is made explicit: >> http://ietf.org/html.charters/diffserv-charter.html >> >> or, at least, our intent in that charter, approved by the IESG, was to >> be explicit in what diffserv was about and was to accomplish. Perhaps >> we are not as clear as we'd like to be? >> >> ...orking group. >> > > >> > > At 03:15 PM 12/04/2000 -0800, demir wrote: >> > > >... I am pointing out a "PHB" definition issue. >> > > >I am talking about a problem of the current architecture >> > > >(where some MAYs won't have any effect on the current): >> > > > >> > > >- "First, we want to start out by implementing a simple set of >> > > > services, which are useful and easy to understand. At the same time, >> > > > we should not embed these services into the mechanism, but should >> > > > build a general mechanism that allows us to change the services as >> > > > our experience matures."- D. Clark / J. Wroclawski, "An Approach to >> > > > Service Allocation in the Internet" >> > > > >> > > >It seems to me that G4 along with other guideslines are >> > > >restrictive. Services (expected) are being embedded into the PHB >> > > >mechanisms. >> > > >> >> So somethign I'd like to say here is to be careful in equating the >> pre-diffserv terminology that Clark and Wroclawski used to the >> terminology that's been defined since the WG was chartered. Clark's >> use of "mechanism" is analogous to what we call the per-hop forwarding >> behavior or PHB. "Mechanism" was objected to, particularly by vendors, >> because it sounded too much like "implementation" which they objected >> to having specified. >> >> I hope we are not embedding expected services into PHB definitions. This >> was why we took the approach we did for RFC 2598, though we had a >> particular >> service in mind. There are "SHOULDs" that allow one to relax things. On >> the other hand, when a particular "service" IS in mind, it would be well >> to have a PHB available that will implement it. Particularly if there >> is commercial interest in such a "service". >> >> Kathie >> >> _______________________________________________ >> diffserv mailing list >> diffserv@ietf.org >> http://www1.ietf.org/mailman/listinfo/diffserv >> Archive: >>http://www2.ietf.org/mail-archive/working-groups/diffserv/current/maillist.html > >-- >- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - >Brian E Carpenter >Program Director, Internet Standards & Technology, IBM >On assignment for IBM at http://www.iCAIR.org >Board Chairman, Internet Society http://www.isoc.org >Non-IBM email: brian@icair.org > >_______________________________________________ >diffserv mailing list >diffserv@ietf.org >http://www1.ietf.org/mailman/listinfo/diffserv >Archive: >http://www2.ietf.org/mail-archive/working-groups/diffserv/current/maillist.html _______________________________________________ diffserv mailing list diffserv@ietf.org http://www1.ietf.org/mailman/listinfo/diffserv Archive: http://www2.ietf.org/mail-archive/working-groups/diffserv/current/maillist.html From diffserv-admin@ietf.org Fri Dec 8 21:17: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 SMTP id VAA09472 for ; Fri, 8 Dec 2000 21:17:06 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id UAA15256; Fri, 8 Dec 2000 20:55:02 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id UAA15231 for ; Fri, 8 Dec 2000 20:54:59 -0500 (EST) Received: from mta5.snfc21.pbi.net (mta5.snfc21.pbi.net [206.13.28.241]) by ietf.org (8.9.1a/8.9.1a) with SMTP id UAA04718 for ; Fri, 8 Dec 2000 20:54:58 -0500 (EST) Received: from allegronetworks.com ([206.170.1.95]) by mta5.snfc21.pbi.net (Sun Internet Mail Server sims.3.5.2000.01.05.12.18.p9) with ESMTP id <0G5A00EDT1HYJI@mta5.snfc21.pbi.net> for diffserv@ietf.org; Fri, 8 Dec 2000 17:30:01 -0800 (PST) Date: Fri, 08 Dec 2000 17:37:54 -0800 From: Andrew Smith Subject: Re: [Diffserv] Model draft - sharing elements on multiple interfaces To: Robert Moore Cc: diffserv Message-id: <3A318CF2.3040101@allegronetworks.com> Organization: Allegro Networks MIME-version: 1.0 Content-type: text/plain; charset=us-ascii; format=flowed Content-transfer-encoding: 7bit User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; m18) Gecko/20001108 Netscape6/6.0 X-Accept-Language: en References: Content-Transfer-Encoding: 7bit Sender: diffserv-admin@ietf.org Errors-To: diffserv-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Diffserv Discussion List X-BeenThere: diffserv@ietf.org Content-Transfer-Encoding: 7bit Bob, Robert Moore wrote: > Andrew, > > OK, I like this picture a lot better than I liked mine. It does > raise a question, though. What's the direction for those three > interfaces that sit between the routing cores? Intuitively, > they're egress from the point of view of "Routing Core", and > ingress from the point of view of "Another Routing Core." > So what do we call them? I don't actually think the "direction" property is that interesting: the binary in/out choice was OK before but it was really just a descriptive flag, rather than anything very fundamental. > The question becomes harder when we look at the MIB. The > diffServDataPathTable has two indexes: ifIndex and > diffServDataPathIfDirection. For a given ifIndex, you're going > to use up the two Direction values for the "real" ingress path > on the interface (not shown in your picture), and for the > egress path shown at the right in your picture. The only way > out that I see is to define a third "direction," something like > coreToCore, to identify the data paths in the middle of your > picture. I recognize that this would be a fairly significant > change to the model. I don't think that is a very significant change for the Model (see above). The more significant change is to acknowledge that such multi-stage structures might be useful for services built on devices that implement this Model. Still waiting for some opinions on whether that is a change for the better or not. > But without it, I think you will have a > picture of a configuration that the MIB is incapable of > representing. Something about carts and horses comes to mind ..... > Regards, > Bob > > Bob Moore > IBM Networking Software > +1-919-254-4436 > remoore@us.ibm.com > > > > Andrew Smith on 12/07/2000 02:43:09 PM > > To: Robert Moore/Raleigh/IBM@IBMUS > cc: diffserv > Subject: Re: [Diffserv] Model draft - sharing elements on multiple > interfaces > > > > Bob, > > Without diving into the details for now, can we agree that, if the "ingress > SLS > shared over multiple interfaces" idea is interesting, then so is the > *egress* > one? Seems like some operations folks out there might be very interested in > this > ..... no? (think: multi-tenant buildings, metro services?) > > Now diving into the details, the egress picture I would draw would be more > like: > > +---------+ +----------+ > | |i/f 1---\ | |--> i/f 1 > | | \ |Another | > |Routing |i/f 2----->meter-->|Routing |--> i/f 2 > |Core | / |Core | > | |i/f 3---/ | |--> i/f 3 > +---------+ +----------+ > > It is of no business to the Diffserv elements how the traffic gets split > back > out to the interfaces on the r.h.s. so it is appropriate to model that > function > as a black box (in this Model document). A "Classifier" at that point is > not the > right functional block to perform the routing functions (which may be as > simple > as "do the same thing as the prior Routing Core did" - it's not our > business to > describe how it might do that). > > Andrew > > > Robert Moore wrote: > > >> Andrew, >> >> I'm still having trouble with the egress half of your >> symmetric solution. Here's how I visualize your idea >> of metering aggregated traffic across a set of egress >> interfaces: >> >> +---------+ +----------+ >> | |i/f 1---\ | |--> i/f 1 >> | | \ | | >> |Routing |i/f 2----->meter-->|classifier|--> i/f 2 >> |Core | / | | >> | |i/f 3---/ | |--> i/f 3 >> +---------+ +----------+ >> >> In words, the Routing Core does whatever it does to >> route packets (which is *outside* the scope of >> DiffServ), and for each packet selects egress i/f >> 1, 2, or 3. The data paths for these three egress >> interfaces then merge into a single meter, to >> provide the metering for the aggregated traffic. >> The meter is followed by a classifier, which fans >> the packets back out to their respective interfaces >> for queueing, scheduling, etc. >> >> It's the classifier that I don't understand. If the >> Routing Core selects an egress interface for a packet >> based on routing criteria that are outside the scope of >> DiffServ, then how can the classifier get each packet >> back to the correct interface? What is it filtering >> on? It can't base its decision on which interface >> the packet traversed just before the meter, because >> the model stipulates that a packet doesn't "remember" >> where it has been. >> >> Do you have a different way of thinking about this >> situation, one that doesn't run into this problem? >> >> Regards, >> Bob >> >> Bob Moore >> IBM Networking Software >> +1-919-254-4436 >> remoore@us.ibm.com >> >> >> >> Andrew Smith on 12/06/2000 01:38:08 PM >> >> To: Robert Moore/Raleigh/IBM@IBMUS >> cc: diffserv >> Subject: Re: [Diffserv] Model draft - sharing elements on multiple >> interfaces >> >> >> >> Bob, >> >> I think you're trying to craft a compromise with Keith here but what you >> propose >> is inconsistent. [Note that I didn't mention the MIB in my message: the > > MIB > >> can >> implement a subset of the model if it so chooses, so long as it is not >> inconsistent with the model, but that's not the point I raised - by all >> means >> discuss the impact of this issue on the MIB in a separate thread but > > don't > >> let >> that confuse this discussion of the model]. >> >> The point in question is whether "shared-between-multiple-interfaces" >> elements >> are both (a) useful for implementing specific services and (b) likely to > > be > >> implemented by more than one vendor and (c) without this change, does it >> make it >> impossible/unlikely that the model can be used to represent a significant >> set of >> devices? I believe that, for (a), the model needs to be symmetric: if > > such > >> a >> service is useful for "in" then it is also for "out" e.g. metering on a >> collection of interfaces representing one customer is just as useful in >> both >> directions. As regards (b), I'd like to hear some more opinions: so far > > the > >> exit >> poll (3 opinions) seems to read: >> >> In? Out? >> Y/N Y/N >> 2/1 1/2 >> >> (if that notation makes sense). And for (c) I'm not sure we have any data >> points. >> >> >> Andrew >> >> >> Robert Moore wrote: >> >> >> >>> Keith, >>> >>> If I'm understanding you correctly, then I think I agree >>> with you. We can allow the sharing of conditioning >>> elements in the ingress case, but continue to rule it out >>> for egress. This covers a case like a single meter that >>> processes traffic aggregated from several ingress >>> interfaces, which seems like something we want to allow. >>> But it doesn't complicate the MIB in the egress case. >>> >>> If we allow sharing of conditioning elements for ingress >>> interfaces, I think there are two cases that need to be >>> mentioned in the MIB: >>> >>> - Two DataPathStart pointers pointing to the same >>> element. If we leave it at that, we have no answer >>> to the question "Which data path is the element >>> *really* on?" But I think this is OK -- we can >>> say that it's equally on both data paths. >>> - A "next" pointer in a conditioning element pointing >>> to a next conditioning element on a different >>> data path. >>> >>> The MIB would also have to say clearly that these two >>> options are *not* allowed for egress data paths. >>> >>> For Andrew's picture, I think it would be fine to >>> combine the new version for the ingress side with the >>> old version for the egress side. >>> >>> Does this sound good to everybody? >>> >>> Regards, >>> Bob >>> >>> Bob Moore >>> IBM Networking Software >>> +1-919-254-4436 >>> remoore@us.ibm.com >>> >>> >>> >>> Keith McCloghrie @ietf.org on 12/05/2000 05:19:33 PM >>> >>> Sent by: diffserv-admin@ietf.org >>> >>> >>> To: Robert Moore/Raleigh/IBM@IBMUS >>> cc: kzm@cisco.com (Keith McCloghrie), andrew@allegronetworks.com >> >> (Andrew >> >> >>> Smith), diffserv@ietf.org (diffserv) >>> Subject: Re: [Diffserv] Model draft - sharing elements on multiple >>> interfaces >>> >>> >>> >>> Bob, >>> >>> I was arguing against additional complexity, which was what I believed >>> would ensue from Andrew's proposed change from: >>> >>> >>> >>> >>>>> -> I -> core -> E -> >>>>> >>>>> The proposal would be to modify this to something like: >>>>> >>>>> -> I -+-> I -> core -> E -+-> E -> >>>>> | | >>>>> -> I -+ +-> E -> >>>> >>> I think it would be possible to allow merging on ingress just by >>> removing the restriction on two data paths merging, which is stated >>> in this ASN.1 comment (I think that's the only place it's specified): >>> >>> -- The use of next pointer to point to diffserv functional datapath >>> -- element of a different datapath is not allowed >>> >>> I agree it's harder for egress which requries splitting, for which >>> I think the current MIB structure is insufficient, and my concern is >>> that a MIB structure which would allow it is going to be more complex. >>> >>> Keith. >>> >>> >>> >>> >>> >>>> Keith, >>>> >>>> I'm not sure what you're arguing for here. At least >>>> on the ingress side, sharing an element (say a >>>> Classifier) between two ingress interfaces amounts >>>> to having the dataPathStart pointers for two entries >>>> in the dataPathTable point to the same entry in the >>>> diffServClassifier table. Are you saying that the MIB >>>> currently rules this out? If so, I've missed it. Or >>>> are you saying that while the MIB doesn't currently >>>> rule it out, it should be changed so that it does? >>>> >>>> It's a little harder to describe for egress, but I >>>> think the idea would be that two Data Paths start out >>>> together, but then somehow diverge before they're done. >>>> I'm not sure exactly how to express this in terms of >>>> the Next pointers, but the same question I asked you >>>> above applies here as well: do you think that the MIB >>>> currently does outlaw this setup, or do you think that >>>> it should (but doesn't now)? >>>> >>>> Thanks. >>>> >>>> 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://www2.ietf.org/mail-archive/working-groups/diffserv/current/maillist.html _______________________________________________ diffserv mailing list diffserv@ietf.org http://www1.ietf.org/mailman/listinfo/diffserv Archive: http://www2.ietf.org/mail-archive/working-groups/diffserv/current/maillist.html From diffserv-admin@ietf.org Fri Dec 8 22:50: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 SMTP id WAA29059 for ; Fri, 8 Dec 2000 22:50:34 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id WAA16247; Fri, 8 Dec 2000 22:23:18 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id WAA16143 for ; Fri, 8 Dec 2000 22:23:10 -0500 (EST) Received: from usc.edu (root@usc.edu [128.125.253.136]) by ietf.org (8.9.1a/8.9.1a) with SMTP id WAA23473 for ; Fri, 8 Dec 2000 22:23:08 -0500 (EST) Received: from aludra.usc.edu (demir@aludra.usc.edu [128.125.253.184]) by usc.edu (8.9.3.1/8.9.3/usc) with ESMTP id TAA00861; Fri, 8 Dec 2000 19:23:10 -0800 (PST) Received: from localhost (demir@localhost) by aludra.usc.edu (8.9.3.1/8.9.3/usc) with ESMTP id TAA06046; Fri, 8 Dec 2000 19:23:09 -0800 (PST) Date: Fri, 8 Dec 2000 19:23:08 -0800 (PST) From: demir To: John Wroclawski cc: Brian E Carpenter , Kathleen Nichols , John Schnizlein , diffserv@ietf.org Subject: Re: [Diffserv] EFRESOLVE definition in the presence of excess inputburstiness In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: diffserv-admin@ietf.org Errors-To: diffserv-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Diffserv Discussion List X-BeenThere: diffserv@ietf.org > In contrast, the AF precursor we wrote about was proposed with the > goal of being a flexible building block for a wider range of less > closely related services. Examples include olympic, quantitative > capacity profiles, a statistically strong low-delay service, etc. For > a PHB with this bias, the definition ought to be targeted more at > wide reuse than at having a particular service in mind. But I don't > think this difference in bias makes such a PHB either more or less > appropriate than a PHB that needs to be narrowly targeted to do what > it was designed for. They're just different critters, is all. I agree with that. It seems to me that AF PHB is a "base" behavior. A "MAY to let EF PHB or others use AF PHB as a "base" PHB won't change the behavior of EF or others If they choose not to use it as a "base". It will leave an "open" window to them to provide "statistical" services if an experimenter choses to play with it. People who needs "only" "service" don't choose it at all. If one chooses, I think it might "help" in the case of "traffic conditioning failures" and be a "more general mechanism" for "richer range of services". I guess I can't see what's wrong with this if there is. (General point is: "object-oriented approach on using PHBs). Alper K. Demir _______________________________________________ diffserv mailing list diffserv@ietf.org http://www1.ietf.org/mailman/listinfo/diffserv Archive: http://www2.ietf.org/mail-archive/working-groups/diffserv/current/maillist.html From diffserv-admin@ietf.org Sat Dec 9 01:18: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 SMTP id BAA09104 for ; Sat, 9 Dec 2000 01:18:24 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id AAA17657; Sat, 9 Dec 2000 00:55:12 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id AAA17626 for ; Sat, 9 Dec 2000 00:55:08 -0500 (EST) Received: from web4202.mail.yahoo.com (web4202.mail.yahoo.com [216.115.104.135]) by ietf.org (8.9.1a/8.9.1a) with SMTP id AAA29346 for ; Sat, 9 Dec 2000 00:55:08 -0500 (EST) From: g_mercankosk@yahoo.com Message-ID: <20001209055438.9978.qmail@web4202.mail.yahoo.com> Received: from [12.99.144.74] by web4202.mail.yahoo.com; Fri, 08 Dec 2000 21:54:38 PST Date: Fri, 8 Dec 2000 21:54:38 -0800 (PST) Subject: Re: [Diffserv] EFRESOLVE definition in the presence of excess inputburstiness To: demir , John Wroclawski Cc: Brian E Carpenter , Kathleen Nichols , John Schnizlein , diffserv@ietf.org MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Sender: diffserv-admin@ietf.org Errors-To: diffserv-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Diffserv Discussion List X-BeenThere: diffserv@ietf.org Alper, The most important characteristic of EF is its abilty of transfering time across the domain. The only way of realizing that is to have bounded delay variation. Although, I am not too much verse with AF, I know that the above objective is not one of its aims. Therefore, AF cannot act as a base class for EF. So, I would suggest that we forget about AF for a while, as there are other important issues to resolve. Especially, we are still not clear what is required for transferig time across a domain. And it is definitely NOT the RATE guarantee. Guven. --- demir wrote: > > In contrast, the AF precursor we wrote about was > proposed with the > > goal of being a flexible building block for a > wider range of less > > closely related services. Examples include > olympic, quantitative > > capacity profiles, a statistically strong > low-delay service, etc. For > > a PHB with this bias, the definition ought to be > targeted more at > > wide reuse than at having a particular service in > mind. But I don't > > think this difference in bias makes such a PHB > either more or less > > appropriate than a PHB that needs to be narrowly > targeted to do what > > it was designed for. They're just different > critters, is all. > > I agree with that. It seems to me that AF PHB is a > "base" behavior. A "MAY > to let EF PHB or others use AF PHB as a "base" PHB > won't change the > behavior of EF or others If they choose not to use > it as a "base". It > will leave an "open" window to them to provide > "statistical" services if > an experimenter choses to play with it. People who > needs > "only" "service" don't choose it at all. If one > chooses, I think it might > "help" in the case of "traffic conditioning > failures" and be a "more > general mechanism" for "richer range of services". I > guess I can't see > what's wrong with this if there is. (General point > is: "object-oriented > approach on using PHBs). > > Alper K. Demir > > > _______________________________________________ > diffserv mailing list > diffserv@ietf.org > http://www1.ietf.org/mailman/listinfo/diffserv > Archive: > http://www2.ietf.org/mail-archive/working-groups/diffserv/current/maillist.html > > > __________________________________________________ Do You Yahoo!? Yahoo! Shopping - Thousands of Stores. Millions of Products. http://shopping.yahoo.com/ _______________________________________________ diffserv mailing list diffserv@ietf.org http://www1.ietf.org/mailman/listinfo/diffserv Archive: http://www2.ietf.org/mail-archive/working-groups/diffserv/current/maillist.html From diffserv-admin@ietf.org Sat Dec 9 09:51:57 2000 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with SMTP id JAA04235 for ; Sat, 9 Dec 2000 09:51:57 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id JAA27312; Sat, 9 Dec 2000 09:26:10 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id JAA27283 for ; Sat, 9 Dec 2000 09:26:06 -0500 (EST) Received: from auemlsrv.firewall.lucent.com (auemail1.lucent.com [192.11.223.161]) by ietf.org (8.9.1a/8.9.1a) with SMTP id JAA28710 for ; Sat, 9 Dec 2000 09:26:02 -0500 (EST) Received: from auemlsrv.firewall.lucent.com (localhost [127.0.0.1]) by auemlsrv.firewall.lucent.com (Pro-8.9.3/8.9.3) with ESMTP id JAA11277 for ; Sat, 9 Dec 2000 09:26:03 -0500 (EST) Received: from uk0006exch001h.wins.lucent.com (h135-86-160-150.lucent.com [135.86.160.150]) by auemlsrv.firewall.lucent.com (Pro-8.9.3/8.9.3) with ESMTP id JAA11263 for ; Sat, 9 Dec 2000 09:26:03 -0500 (EST) Received: by uk0006exch001h.uk.lucent.com with Internet Mail Service (5.5.2650.21) id ; Sat, 9 Dec 2000 14:26:02 -0000 Message-ID: <976F7C55E3B2D111A0720008C728549C0487761E@en0060exch001u.uk.lucent.com> From: "Casati, Alessio (Alessio)" To: "'Bruce Davie'" Cc: diffserv@ietf.org Subject: RE: [Diffserv] Possible compromise between EFRESOLVE and draft-ch arny Date: Sat, 9 Dec 2000 14:26:01 -0000 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: text/plain Sender: diffserv-admin@ietf.org Errors-To: diffserv-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Diffserv Discussion List X-BeenThere: diffserv@ietf.org Bruce, we would like to summarize the position on the criticisms. > Among the criticisms of EFRESOLVE were > > - it doesn't define behavior of a node outside of its operating region > This is a deliberate choice. We don't want to constrain implementations behaviour outside the operating region. Anything like drop and notify performance management subsystem could be fine. This is more dependent on the service goals, and this is outside the scope of our work. > - non-FIFO treatment of EF will typically lead to a large value of S > It appears this concern was addressed on the list and multiple voices supported that this point was not valid. As such we don't need to discuss about this further. > - S is not a good figure of merit, since non-ideal scheduling and non-FIFO > service are lumped in the same parameter; also very good devices with > large > number of ports will look worse than small devices with bad scheduling > implementations > The list suggested that if a box provides smart features that handle the EF aggregate at flows level, then why not to boast it in your brochures an claim EF++ capabilities? Our definition is not intended to cover particular marketing needs. > - it is not yet clear how to generalize the defintion to the multiple > input, > multiple output case > The team considered the definition to apply to an (input,output) pair. Any EF or non EF traffic towards the same output interface would be considered as competing traffic, in order to deliver the desired behaviour. > - it allows arbitrarily large fixed delay (which isn't visible in a figure > of merit) > Indeed, the current definition allows for it. Fixed delay is not a concern since it is a parameter evaluated by the market independent from EF definition. We don't want to act on this. Summarizing, we have carefully considered the criticisms, and evaluated the answers above would address them. regards, alessio _______________________________________________ diffserv mailing list diffserv@ietf.org http://www1.ietf.org/mailman/listinfo/diffserv Archive: http://www2.ietf.org/mail-archive/working-groups/diffserv/current/maillist.html From diffserv-admin@ietf.org Sat Dec 9 11:10: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 SMTP id LAA15713 for ; Sat, 9 Dec 2000 11:10:02 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id KAA28122; Sat, 9 Dec 2000 10:43:56 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id KAA28091 for ; Sat, 9 Dec 2000 10:43:51 -0500 (EST) Received: from pilgrim.cisco.com (pilgrim.cisco.com [171.69.204.12]) by ietf.org (8.9.1a/8.9.1a) with SMTP id KAA12806 for ; Sat, 9 Dec 2000 10:43:49 -0500 (EST) Received: from acharny-nt.cisco.com ([161.44.189.106]) by pilgrim.cisco.com (8.8.8-Cisco List Logging/8.8.8) with ESMTP id KAA19360; Sat, 9 Dec 2000 10:43:13 -0500 (EST) Message-Id: <4.3.2.7.2.20001209095719.00c86ed0@pilgrim.cisco.com> X-Sender: acharny@pilgrim.cisco.com X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Sat, 09 Dec 2000 10:48:52 -0500 To: "Casati, Alessio (Alessio)" , "'Bruce Davie'" From: Anna Charny Subject: RE: [Diffserv] Possible compromise between EFRESOLVE and draft-ch arny Cc: diffserv@ietf.org In-Reply-To: <976F7C55E3B2D111A0720008C728549C0487761E@en0060exch001u.uk .lucent.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: diffserv-admin@ietf.org Errors-To: diffserv-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Diffserv Discussion List X-BeenThere: diffserv@ietf.org Alessio, At 02:26 PM 12/9/00 +0000, Casati, Alessio (Alessio) wrote: >Bruce, > >we would like to summarize the position >on the criticisms. > > > Among the criticisms of EFRESOLVE were > > > > - it doesn't define behavior of a node outside of its operating region > > >This is a deliberate choice. We don't want to constrain >implementations behaviour outside the >operating region. Anything like drop and notify performance >management subsystem could be fine. This is more >dependent on the service goals, and this is outside >the scope of our work. Can you summarize your objections to having the behavior specified for any operating region as a function of the parameters of this operating region? Also, you say that a number of actions you specify above "would be fine". Could you please explain why you are not concerned about the possibility that undefined behavior at some node (even it network management is notified, but the packets are not dropped), may result in cascaded undefined behavior downstream? > > - non-FIFO treatment of EF will typically lead to a large value of S > > >It appears this concern was addressed on the list and >multiple voices supported that this point was not valid. >As such we don't need to discuss about this further. Do you mean to say that it is not true that devices with non-FIFO treatment will have large S, or that it is not important that they have large S? I would also like to point out that there were also multiple voices on the list that supported the opinion that this point was valid, so I suggest that we need to address this question with a more technical discussion. > > - S is not a good figure of merit, since non-ideal scheduling and non-FIFO > > service are lumped in the same parameter; also very good devices with > > large > > number of ports will look worse than small devices with bad scheduling > > implementations > > >The list suggested that if a box provides smart features that >handle the EF aggregate at flows level, then why not to boast it >in your brochures an claim EF++ capabilities? >Our definition is not intended to cover particular marketing needs. I am not sure how your statement about smart features addresses the fact that S, which is advertised as a figure of merit, does not appear to be one? Also, can you please summarize objections to actually having a figure of merit as part of definition? I would also like to repeat my suggestion that in the case where opposing opinions have been given on the list, we refrain from using the mere fact of the existence of people supporting a given opinion as a proof that this opinion is correct. It seems a technical argument addressing the issue itself might be more appropriate to resolve the differences. > > - it is not yet clear how to generalize the defintion to the multiple > > input, > > multiple output case > > >The team considered the definition to apply to >an (input,output) pair. Any EF or non EF traffic >towards the same output interface would be considered as >competing traffic, in order to deliver the desired behaviour. We understand that. We are concerned, however, that the decision of the team to use the input rate only makes it difficult to generalize the definition to a device with a range of interface speeds in a way meaningful in the diffserv environment. While it is possible that we misunderstand how you plan to address this issue, we have not been able to get any clarification of this (and in fact at least two members of your team have acknowledged that such generalization is not obvious). It may help if you can give the answer to the following questions. Can you please let us know what is the maximum input rate R that a device can support in the case of multiple speeds of interfaces, when the device is just characterized by a single value of R (your draft says that this is the speed of the slowest interface - do you believe it is correct?). Can you also describe how to specify the rate constraints in this case when you want to describe the device by multiple constraints of R, as your draft suggests should be possible? I hope your answers might help clarify these issues. > > - it allows arbitrarily large fixed delay (which isn't visible in a figure > > of merit) > > >Indeed, the current definition allows for it. >Fixed delay is not a concern since it is a parameter >evaluated by the market independent from EF >definition. We don't want to act on this. This indeed can be easily fixed by simply specifying what the fixed delay is. >Summarizing, we have carefully considered the >criticisms, and evaluated >the answers above would address them. I look forward to getting your answers to my questions above. Best regards, Anna >regards, >alessio > > > > >_______________________________________________ >diffserv mailing list >diffserv@ietf.org >http://www1.ietf.org/mailman/listinfo/diffserv >Archive: >http://www2.ietf.org/mail-archive/working-groups/diffserv/current/maillist.html --------------------------------------- Anna Charny Cisco Systems, Inc 300 Apollo Drive Chelmsford, MA 01824 Tel. (978)-244-8172 Fax (978)-244-8126 _______________________________________________ diffserv mailing list diffserv@ietf.org http://www1.ietf.org/mailman/listinfo/diffserv Archive: http://www2.ietf.org/mail-archive/working-groups/diffserv/current/maillist.html From diffserv-admin@ietf.org Sat Dec 9 12:15: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 SMTP id MAA23543 for ; Sat, 9 Dec 2000 12:15:00 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id LAA28689; Sat, 9 Dec 2000 11:49:19 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id LAA28656 for ; Sat, 9 Dec 2000 11:49:14 -0500 (EST) Received: from nt1.rocori.k12.mn.us (nt1.rocori.k12.mn.us [207.229.251.2]) by ietf.org (8.9.1a/8.9.1a) with SMTP id LAA20129; Sat, 9 Dec 2000 11:49:11 -0500 (EST) Message-Id: <200012091649.LAA20129@ietf.org> From: Mail Sender To: diffserv@ietf.org CC: diffserv-request@ietf.org, digital_puer@hotmail.com, dimo_dl@slt.lk, dina.sturdivant@sdrc.com, dion@erebus.demon.nl Reply-To: mailsender@mailsender.ru Date: 09.12.2000 Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Subject: [Diffserv] Russian Goods and Service from Moscow Sender: diffserv-admin@ietf.org Errors-To: diffserv-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Diffserv Discussion List X-BeenThere: diffserv@ietf.org www.rusgoods.com www.rusgoods.ru ================================================================ We present you the production of the 1-st Moscow Watch Factory "Poljot" (Flying). From the simple mechanical watch of the series 2609 till unique, composite and precise mechanical o'clock - Marine timer . It is unique factory in Russia, which makes mechanical hours with the Swiss quality. Factory, which makes watches for the Russian Air Forces , Russian Naval Forces. All mechanical watch which we offer to you, will be delivered to you directly from the factory. If it isn't in the warehouse of the factory, we will place your order directly at the 1-st Moscow Watch Factory without any middlemans. The submarine "Kursk" had on board mechanical marine hronometr 6MX. =============================================================== The "table" of orders. Here you can to order, to find, to know almost everything, than the Russia is rich, everything that does not contradict Russian Federation laws. Here you can receive or order: The information about any enterprise, firm, organization, or person in Russia The production or any goods of Russian manufactories, and other things if it is possible. =============================================================== www.rusgoods.com www.rusgoods.ru _______________________________________________ diffserv mailing list diffserv@ietf.org http://www1.ietf.org/mailman/listinfo/diffserv Archive: http://www2.ietf.org/mail-archive/working-groups/diffserv/current/maillist.html From diffserv-admin@ietf.org Sat Dec 9 18:19: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 SMTP id SAA29194 for ; Sat, 9 Dec 2000 18:19:09 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id RAA02119; Sat, 9 Dec 2000 17:57:22 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id RAA02094 for ; Sat, 9 Dec 2000 17:57:18 -0500 (EST) Received: from bucky.excite.com (bucky-rwcmex.excite.com [198.3.99.218]) by ietf.org (8.9.1a/8.9.1a) with SMTP id RAA24481 for ; Sat, 9 Dec 2000 17:57:16 -0500 (EST) Received: from derby ([199.172.152.144]) by bucky.excite.com (InterMail vM.4.01.02.39 201-229-119-122) with ESMTP id <20001209225648.EFZF14843.bucky.excite.com@derby> for ; Sat, 9 Dec 2000 14:56:48 -0800 Message-ID: <29559295.976402608581.JavaMail.imail@derby> Date: Sat, 9 Dec 2000 14:56:48 -0800 (PST) From: Vijey Jenkal To: diffserv@ietf.org Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Mailer: Excite Inbox X-Sender-Ip: 129.237.126.85 Content-Transfer-Encoding: 7bit Subject: [Diffserv] Testing Sender: diffserv-admin@ietf.org Errors-To: diffserv-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 am trying to perform some initial tests using diffserv and was hoping someone could tell me some very basic configurations and test senarios .. I was especially hoping to know how I can set the DSCP values in the traffic that I generate.. is there any tool that would allow me to the same thankyou regards Vijey Jenkal _______________________________________________________ Send a cool gift with your E-Card _______________________________________________ diffserv mailing list diffserv@ietf.org http://www1.ietf.org/mailman/listinfo/diffserv Archive: http://www2.ietf.org/mail-archive/working-groups/diffserv/current/maillist.html From diffserv-admin@ietf.org Sun Dec 10 08:20: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 SMTP id IAA11467 for ; Sun, 10 Dec 2000 08:20:33 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id HAA14359; Sun, 10 Dec 2000 07:58:39 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id HAA14328 for ; Sun, 10 Dec 2000 07:58:34 -0500 (EST) Received: from e22.nc.us.ibm.com (e22.nc.us.ibm.com [32.97.136.228]) by ietf.org (8.9.1a/8.9.1a) with SMTP id HAA04723 for ; Sun, 10 Dec 2000 07:58:31 -0500 (EST) Received: from southrelay02.raleigh.ibm.com (southrelay02.raleigh.ibm.com [9.37.3.209]) by e22.nc.us.ibm.com (8.9.3/8.9.3) with ESMTP id HAA23528; Sun, 10 Dec 2000 07:55:09 -0600 Received: from d04nm200.raleigh.ibm.com (d04nm200.raleigh.ibm.com [9.67.228.37]) by southrelay02.raleigh.ibm.com (8.8.8m3/NCO v4.95) with ESMTP id HAA32568; Sun, 10 Dec 2000 07:58:00 -0500 Importance: Normal Subject: Re: [Diffserv] Model draft - sharing elements on multiple interfaces To: Andrew Smith Cc: diffserv X-Mailer: Lotus Notes Release 5.0.3 (Intl) 21 March 2000 Message-ID: From: "Robert Moore" Date: Sun, 10 Dec 2000 07:58:58 -0500 X-MIMETrack: Serialize by Router on D04NM200/04/M/IBM(Release 5.0.3 (Intl)|21 March 2000) at 12/10/2000 07:58:30 AM MIME-Version: 1.0 Content-type: text/plain; charset=us-ascii Sender: diffserv-admin@ietf.org Errors-To: diffserv-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Diffserv Discussion List X-BeenThere: diffserv@ietf.org Hi Andrew, There are carts and horses, but there are also dogs and tails. I think that the IETF's concept of an interface, in part as formalized in the Interfaces MIB, is more fundamental than all of DiffServ. If you can incorporate your DiffServ-in-the-middle function into the concept of an interface without doing violence to the concept of an interface, then that's great. If not, though, then I think the concept of interface is the dog, and DiffServ (in Toto (sorry -- couldn't resist the dog pun:-): existing RFCs, Informal Model, MIB, PIB) is the tail. In other words, if you think we need to represent DiffServ data paths that cross "interfaces" on the egress side, then we may need to say that DiffServ can happen in two places in a system: on an ingress or egress interface, and in a component that sits between routing cores, but is not an interface. I believe that the only reason you're saying now that this location in the middle is an interface is that we previously, before you considered this case, you had placed all DiffServ functions on interfaces. This change would ripple painfully through much of the Informal Model and the MIB & PIB, so let me be clear that I'm not proposing it. As I said earlier, I would be satisfied if we had cross-interface data paths only on ingress. Nor am I saying that the interface dog absolutely cannot accommodate the DiffServ--in-the-middle tail you've suggested. I *am* saying, however, that we'd better make sure that the people who work with the concept of an interfaces in other contexts understand what we're doing, and agree that it's appropriate, before we move forward with your proposal. Regards, Bob Bob Moore IBM Networking Software +1-919-254-4436 remoore@us.ibm.com Andrew Smith @ietf.org on 12/08/2000 08:37:54 PM Sent by: diffserv-admin@ietf.org To: Robert Moore/Raleigh/IBM@IBMUS cc: diffserv Subject: Re: [Diffserv] Model draft - sharing elements on multiple interfaces Bob, Robert Moore wrote: > Andrew, > > OK, I like this picture a lot better than I liked mine. It does > raise a question, though. What's the direction for those three > interfaces that sit between the routing cores? Intuitively, > they're egress from the point of view of "Routing Core", and > ingress from the point of view of "Another Routing Core." > So what do we call them? I don't actually think the "direction" property is that interesting: the binary in/out choice was OK before but it was really just a descriptive flag, rather than anything very fundamental. > The question becomes harder when we look at the MIB. The > diffServDataPathTable has two indexes: ifIndex and > diffServDataPathIfDirection. For a given ifIndex, you're going > to use up the two Direction values for the "real" ingress path > on the interface (not shown in your picture), and for the > egress path shown at the right in your picture. The only way > out that I see is to define a third "direction," something like > coreToCore, to identify the data paths in the middle of your > picture. I recognize that this would be a fairly significant > change to the model. I don't think that is a very significant change for the Model (see above). The more significant change is to acknowledge that such multi-stage structures might be useful for services built on devices that implement this Model. Still waiting for some opinions on whether that is a change for the better or not. > But without it, I think you will have a > picture of a configuration that the MIB is incapable of > representing. Something about carts and horses comes to mind ..... > Regards, > Bob > > Bob Moore > IBM Networking Software > +1-919-254-4436 > remoore@us.ibm.com > > > > Andrew Smith on 12/07/2000 02:43:09 PM > > To: Robert Moore/Raleigh/IBM@IBMUS > cc: diffserv > Subject: Re: [Diffserv] Model draft - sharing elements on multiple > interfaces > > > > Bob, > > Without diving into the details for now, can we agree that, if the "ingress > SLS > shared over multiple interfaces" idea is interesting, then so is the > *egress* > one? Seems like some operations folks out there might be very interested in > this > ..... no? (think: multi-tenant buildings, metro services?) > > Now diving into the details, the egress picture I would draw would be more > like: > > +---------+ +----------+ > | |i/f 1---\ | |--> i/f 1 > | | \ |Another | > |Routing |i/f 2----->meter-->|Routing |--> i/f 2 > |Core | / |Core | > | |i/f 3---/ | |--> i/f 3 > +---------+ +----------+ > > It is of no business to the Diffserv elements how the traffic gets split > back > out to the interfaces on the r.h.s. so it is appropriate to model that > function > as a black box (in this Model document). A "Classifier" at that point is > not the > right functional block to perform the routing functions (which may be as > simple > as "do the same thing as the prior Routing Core did" - it's not our > business to > describe how it might do that). > > Andrew > > > Robert Moore wrote: > > >> Andrew, >> >> I'm still having trouble with the egress half of your >> symmetric solution. Here's how I visualize your idea >> of metering aggregated traffic across a set of egress >> interfaces: >> >> +---------+ +----------+ >> | |i/f 1---\ | |--> i/f 1 >> | | \ | | >> |Routing |i/f 2----->meter-->|classifier|--> i/f 2 >> |Core | / | | >> | |i/f 3---/ | |--> i/f 3 >> +---------+ +----------+ >> >> In words, the Routing Core does whatever it does to >> route packets (which is *outside* the scope of >> DiffServ), and for each packet selects egress i/f >> 1, 2, or 3. The data paths for these three egress >> interfaces then merge into a single meter, to >> provide the metering for the aggregated traffic. >> The meter is followed by a classifier, which fans >> the packets back out to their respective interfaces >> for queueing, scheduling, etc. >> >> It's the classifier that I don't understand. If the >> Routing Core selects an egress interface for a packet >> based on routing criteria that are outside the scope of >> DiffServ, then how can the classifier get each packet >> back to the correct interface? What is it filtering >> on? It can't base its decision on which interface >> the packet traversed just before the meter, because >> the model stipulates that a packet doesn't "remember" >> where it has been. >> >> Do you have a different way of thinking about this >> situation, one that doesn't run into this problem? >> >> Regards, >> Bob >> >> Bob Moore >> IBM Networking Software >> +1-919-254-4436 >> remoore@us.ibm.com >> >> >> >> Andrew Smith on 12/06/2000 01:38:08 PM >> >> To: Robert Moore/Raleigh/IBM@IBMUS >> cc: diffserv >> Subject: Re: [Diffserv] Model draft - sharing elements on multiple >> interfaces >> >> >> >> Bob, >> >> I think you're trying to craft a compromise with Keith here but what you >> propose >> is inconsistent. [Note that I didn't mention the MIB in my message: the > > MIB > >> can >> implement a subset of the model if it so chooses, so long as it is not >> inconsistent with the model, but that's not the point I raised - by all >> means >> discuss the impact of this issue on the MIB in a separate thread but > > don't > >> let >> that confuse this discussion of the model]. >> >> The point in question is whether "shared-between-multiple-interfaces" >> elements >> are both (a) useful for implementing specific services and (b) likely to > > be > >> implemented by more than one vendor and (c) without this change, does it >> make it >> impossible/unlikely that the model can be used to represent a significant >> set of >> devices? I believe that, for (a), the model needs to be symmetric: if > > such > >> a >> service is useful for "in" then it is also for "out" e.g. metering on a >> collection of interfaces representing one customer is just as useful in >> both >> directions. As regards (b), I'd like to hear some more opinions: so far > > the > >> exit >> poll (3 opinions) seems to read: >> >> In? Out? >> Y/N Y/N >> 2/1 1/2 >> >> (if that notation makes sense). And for (c) I'm not sure we have any data >> points. >> >> >> Andrew >> >> >> Robert Moore wrote: >> >> >> >>> Keith, >>> >>> If I'm understanding you correctly, then I think I agree >>> with you. We can allow the sharing of conditioning >>> elements in the ingress case, but continue to rule it out >>> for egress. This covers a case like a single meter that >>> processes traffic aggregated from several ingress >>> interfaces, which seems like something we want to allow. >>> But it doesn't complicate the MIB in the egress case. >>> >>> If we allow sharing of conditioning elements for ingress >>> interfaces, I think there are two cases that need to be >>> mentioned in the MIB: >>> >>> - Two DataPathStart pointers pointing to the same >>> element. If we leave it at that, we have no answer >>> to the question "Which data path is the element >>> *really* on?" But I think this is OK -- we can >>> say that it's equally on both data paths. >>> - A "next" pointer in a conditioning element pointing >>> to a next conditioning element on a different >>> data path. >>> >>> The MIB would also have to say clearly that these two >>> options are *not* allowed for egress data paths. >>> >>> For Andrew's picture, I think it would be fine to >>> combine the new version for the ingress side with the >>> old version for the egress side. >>> >>> Does this sound good to everybody? >>> >>> Regards, >>> Bob >>> >>> Bob Moore >>> IBM Networking Software >>> +1-919-254-4436 >>> remoore@us.ibm.com >>> >>> >>> >>> Keith McCloghrie @ietf.org on 12/05/2000 05:19:33 PM >>> >>> Sent by: diffserv-admin@ietf.org >>> >>> >>> To: Robert Moore/Raleigh/IBM@IBMUS >>> cc: kzm@cisco.com (Keith McCloghrie), andrew@allegronetworks.com >> >> (Andrew >> >> >>> Smith), diffserv@ietf.org (diffserv) >>> Subject: Re: [Diffserv] Model draft - sharing elements on multiple >>> interfaces >>> >>> >>> >>> Bob, >>> >>> I was arguing against additional complexity, which was what I believed >>> would ensue from Andrew's proposed change from: >>> >>> >>> >>> >>>>> -> I -> core -> E -> >>>>> >>>>> The proposal would be to modify this to something like: >>>>> >>>>> -> I -+-> I -> core -> E -+-> E -> >>>>> | | >>>>> -> I -+ +-> E -> >>>> >>> I think it would be possible to allow merging on ingress just by >>> removing the restriction on two data paths merging, which is stated >>> in this ASN.1 comment (I think that's the only place it's specified): >>> >>> -- The use of next pointer to point to diffserv functional datapath >>> -- element of a different datapath is not allowed >>> >>> I agree it's harder for egress which requries splitting, for which >>> I think the current MIB structure is insufficient, and my concern is >>> that a MIB structure which would allow it is going to be more complex. >>> >>> Keith. >>> >>> >>> >>> >>> >>>> Keith, >>>> >>>> I'm not sure what you're arguing for here. At least >>>> on the ingress side, sharing an element (say a >>>> Classifier) between two ingress interfaces amounts >>>> to having the dataPathStart pointers for two entries >>>> in the dataPathTable point to the same entry in the >>>> diffServClassifier table. Are you saying that the MIB >>>> currently rules this out? If so, I've missed it. Or >>>> are you saying that while the MIB doesn't currently >>>> rule it out, it should be changed so that it does? >>>> >>>> It's a little harder to describe for egress, but I >>>> think the idea would be that two Data Paths start out >>>> together, but then somehow diverge before they're done. >>>> I'm not sure exactly how to express this in terms of >>>> the Next pointers, but the same question I asked you >>>> above applies here as well: do you think that the MIB >>>> currently does outlaw this setup, or do you think that >>>> it should (but doesn't now)? >>>> >>>> Thanks. >>>> >>>> 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://www2.ietf.org/mail-archive/working-groups/diffserv/current/maillist.html _______________________________________________ diffserv mailing list diffserv@ietf.org http://www1.ietf.org/mailman/listinfo/diffserv Archive: http://www2.ietf.org/mail-archive/working-groups/diffserv/current/maillist.html _______________________________________________ diffserv mailing list diffserv@ietf.org http://www1.ietf.org/mailman/listinfo/diffserv Archive: http://www2.ietf.org/mail-archive/working-groups/diffserv/current/maillist.html From diffserv-admin@ietf.org Sun Dec 10 18:25: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 SMTP id SAA03392 for ; Sun, 10 Dec 2000 18:25:24 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id RAA19360; Sun, 10 Dec 2000 17:54:05 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id RAA19329 for ; Sun, 10 Dec 2000 17:54:01 -0500 (EST) 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 SMTP id RAA24072 for ; Sun, 10 Dec 2000 17:54:00 -0500 (EST) Received: from stl-av-02.boeing.com ([192.76.190.7]) by stl-smtpout-01.boeing.com (8.9.2/8.8.5-M2) with ESMTP id QAA04415 for ; Sun, 10 Dec 2000 16:54:01 -0600 (CST) Received: from stl-hub-01.boeing.com (localhost [127.0.0.1]) by stl-av-02.boeing.com (8.9.3/8.9.2) with ESMTP id QAA24027 for ; Sun, 10 Dec 2000 16:54:01 -0600 (CST) Received: from xch-phlbh-01.he.boeing.com by stl-hub-01.boeing.com with ESMTP; Sun, 10 Dec 2000 16:53:55 -0600 Received: by xch-phlbh-01.he.boeing.com with Internet Mail Service (5.5.2650.21) id ; Sun, 10 Dec 2000 17:53:54 -0500 Message-Id: <4102273CEB77D211869200805FE6F593018C5BDD@xch-phl-01.he.boeing.com> From: "Manfredi, Albert E" To: "'Anna Charny'" Cc: diffserv@ietf.org Subject: RE: [Diffserv] Possible compromise between EFRESOLVE and draft-ch arny Date: Sun, 10 Dec 2000 17:53:53 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: text/plain; charset="iso-8859-1" Sender: diffserv-admin@ietf.org Errors-To: diffserv-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Diffserv Discussion List X-BeenThere: diffserv@ietf.org Anna Charny wrote: > Alessio Casati wrote: > > > - non-FIFO treatment of EF will typically lead to a large > value of S > > > > >It appears this concern was addressed on the list and > >multiple voices supported that this point was not valid. > >As such we don't need to discuss about this further. > > Do you mean to say that it is not true that devices with > non-FIFO treatment > will have large S, or that it is not important that they have large S? > > I would also like to point out that there were also multiple > voices on the > list that supported the opinion that this point was valid, so > I suggest > that we need to address this question > with a more technical discussion. I'm afraid I don't understand the controversy regarding S. EFRESOLVE states that EF is defined as an aggregate flow for which the difference between minimum possible delay and the maximum possible delay is bounded by some number S X MTU transfer time when the arrival rate of this incoming EF aggregate flow is specified as R. The underlying idea of EF, whether we can state this or no, has always been (has it not?) to support a service similar to CBR, or approaching CBR, for an aggregate flow. So S will determine how CBR-like this EF flow will be. If some non-FIFO schedulers will result in large values of S, seems to me that those schedulers are simply not ideal for EF use. Why is this an issue? > We are concerned, however, that the > decision of the > team to use the input rate only makes it difficult to generalize the > definition to a device with a range of interface speeds in a > way meaningful > in the diffserv environment. While it is possible that we > misunderstand how > you plan to address this issue, we have not been able to get any > clarification of this (and in fact at least two members of > your team have > acknowledged that such generalization is not obvious). > > It may help if you can give the answer to the following questions. > Can you please let us know what is the maximum input rate R > that a device > can support in the case of multiple speeds of interfaces, > when the device > is just characterized by a single value of R (your draft > says that this is > the speed of the slowest interface - do you believe it is > correct?). Wouldn't the total EF arrival rate at the box be R? And if so, if the speed of the slowest egress >= R, then haven't we guaranteed that the delay variation will remain bounded? Bert _______________________________________________ diffserv mailing list diffserv@ietf.org http://www1.ietf.org/mailman/listinfo/diffserv Archive: http://www2.ietf.org/mail-archive/working-groups/diffserv/current/maillist.html From diffserv-admin@ietf.org Sun Dec 10 20:41: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 SMTP id UAA27658 for ; Sun, 10 Dec 2000 20:41:12 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id UAA20713; Sun, 10 Dec 2000 20:18:24 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id UAA20684 for ; Sun, 10 Dec 2000 20:18:19 -0500 (EST) Received: from auemlsrv.firewall.lucent.com (auemail1.lucent.com [192.11.223.161]) by ietf.org (8.9.1a/8.9.1a) with SMTP id UAA25130 for ; Sun, 10 Dec 2000 20:18:17 -0500 (EST) Received: from auemlsrv.firewall.lucent.com (localhost [127.0.0.1]) by auemlsrv.firewall.lucent.com (Pro-8.9.3/8.9.3) with ESMTP id UAA26739 for ; Sun, 10 Dec 2000 20:18:19 -0500 (EST) Received: from nl0006exch001h.wins.lucent.com (h135-85-76-62.lucent.com [135.85.76.62]) by auemlsrv.firewall.lucent.com (Pro-8.9.3/8.9.3) with ESMTP id UAA26725 for ; Sun, 10 Dec 2000 20:18:19 -0500 (EST) Received: by nl0006exch001h.nl.lucent.com with Internet Mail Service (5.5.2650.21) id ; Mon, 11 Dec 2000 02:18:13 +0100 Message-ID: <2413FED0DFE6D111B3F90008C7FA61FB0A6705D6@nl0006exch002u.nl.lucent.com> From: "Wijnen, Bert (Bert)" To: Kwok-Ho Chan Cc: diffserv@ietf.org Subject: RE: [Diffserv] DiffServ MIB -06: the diffServDscpMarkActTable Date: Mon, 11 Dec 2000 02:18:09 +0100 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: text/plain Sender: diffserv-admin@ietf.org Errors-To: diffserv-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Diffserv Discussion List X-BeenThere: diffserv@ietf.org I think it is OK to use a zero (for the index which is also the only readable column). I have looked at the -06 revision. What I think I do want to see changed is: - add some text to the DESCRIPTION clause why the value of is OK in this exceptional case. - Add a range to the Dscp Syntax to exclide the -1 value. Just stating that in the description clause is not good enuf. Bert > ---------- > From: Kwok-Ho Chan[SMTP:khchan@nortelnetworks.com] > Sent: Friday, November 17, 2000 11:36 PM > To: Robert Moore/Raleigh/IBM > Cc: diffserv@ietf.org; Kwok-Ho Chan > Subject: Re: [Diffserv] DiffServ MIB -05: the > diffServDscpMarkActTable > > Bob: > Thanks for your comments! > > It is true that the -04 method is simpler and more efficient. > The key point of this issue is: > Will the use of zero valued index acceptable? > I think yes, see above _______________________________________________ diffserv mailing list diffserv@ietf.org http://www1.ietf.org/mailman/listinfo/diffserv Archive: http://www2.ietf.org/mail-archive/working-groups/diffserv/current/maillist.html From diffserv-admin@ietf.org Sun Dec 10 23:52: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 SMTP id XAA24264 for ; Sun, 10 Dec 2000 23:51:59 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id XAA22595; Sun, 10 Dec 2000 23:32:49 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id XAA22564 for ; Sun, 10 Dec 2000 23:32:46 -0500 (EST) Received: from mta6.snfc21.pbi.net (mta6.snfc21.pbi.net [206.13.28.240]) by ietf.org (8.9.1a/8.9.1a) with SMTP id XAA20179 for ; Sun, 10 Dec 2000 23:32:39 -0500 (EST) Received: from allegronetworks.com ([206.170.1.30]) by mta6.snfc21.pbi.net (Sun Internet Mail Server sims.3.5.2000.01.05.12.18.p9) with ESMTP id <0G5D004WRZ5GDU@mta6.snfc21.pbi.net> for diffserv@ietf.org; Sun, 10 Dec 2000 20:29:43 -0800 (PST) Date: Sun, 10 Dec 2000 20:38:05 -0800 From: Andrew Smith Subject: Re: [Diffserv] Model draft - sharing elements on multiple interfaces To: Robert Moore Cc: diffserv Message-id: <3A345A2D.7090408@allegronetworks.com> Organization: Allegro Networks MIME-version: 1.0 Content-type: text/plain; charset=us-ascii; format=flowed Content-transfer-encoding: 7bit User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; m18) Gecko/20001108 Netscape6/6.0 X-Accept-Language: en References: Content-Transfer-Encoding: 7bit Sender: diffserv-admin@ietf.org Errors-To: diffserv-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Diffserv Discussion List X-BeenThere: diffserv@ietf.org Content-Transfer-Encoding: 7bit Bob, Well, my earlier comment about the "in" and "out" spigot things in Diffserv MIB being more like "rmonDataSource" than "ifIndex" things wasn't entirely facetious. The "IETF concept of an interface, in part as formalized in the Interfaces MIB" has its uses but I don't think it can be said to be the normative definition of an interface for non-MIB things. But I only proposed this change to the Model in order to try to satisfy the issue that you yourself raised regarding functional elements that were to be applied to more than interface. If we add it for the ingress side then we must also add it for the egress. If you don't think it needs to be added then let's leave it out. However, the MIB *must* not then allow the concept to sneak in through the back door - the whole purpose of the Model is to set the boundaries on what the MIB/PIB/etc. can represent. Andrew Robert Moore wrote: > Hi Andrew, > > There are carts and horses, but there are also dogs and tails. > I think that the IETF's concept of an interface, in part as > formalized in the Interfaces MIB, is more fundamental than all > of DiffServ. If you can incorporate your DiffServ-in-the-middle > function into the concept of an interface without doing violence > to the concept of an interface, then that's great. If not, > though, then I think the concept of interface is the dog, and > DiffServ (in Toto (sorry -- couldn't resist the dog pun:-): > existing RFCs, Informal Model, MIB, PIB) is the tail. > > In other words, if you think we need to represent DiffServ data > paths that cross "interfaces" on the egress side, then we may > need to say that DiffServ can happen in two places in a system: > on an ingress or egress interface, and in a component that sits > between routing cores, but is not an interface. I believe that > the only reason you're saying now that this location in the > middle is an interface is that we previously, before you > considered this case, you had placed all DiffServ functions on > interfaces. > > This change would ripple painfully through much of the Informal > Model and the MIB & PIB, so let me be clear that I'm not > proposing it. As I said earlier, I would be satisfied if we > had cross-interface data paths only on ingress. Nor am I > saying that the interface dog absolutely cannot accommodate the > DiffServ--in-the-middle tail you've suggested. I *am* saying, > however, that we'd better make sure that the people who work > with the concept of an interfaces in other contexts understand > what we're doing, and agree that it's appropriate, before we > move forward with your proposal. > > Regards, > Bob > > Bob Moore > IBM Networking Software > +1-919-254-4436 > remoore@us.ibm.com > > > > Andrew Smith @ietf.org on 12/08/2000 08:37:54 > PM > > Sent by: diffserv-admin@ietf.org > > > To: Robert Moore/Raleigh/IBM@IBMUS > cc: diffserv > Subject: Re: [Diffserv] Model draft - sharing elements on multiple > interfaces > > > > Bob, > > Robert Moore wrote: > > >> Andrew, >> >> OK, I like this picture a lot better than I liked mine. It does >> raise a question, though. What's the direction for those three >> interfaces that sit between the routing cores? Intuitively, >> they're egress from the point of view of "Routing Core", and >> ingress from the point of view of "Another Routing Core." >> So what do we call them? > > > I don't actually think the "direction" property is that interesting: the > binary > in/out choice was OK before but it was really just a descriptive flag, > rather > than anything very fundamental. > > > >> The question becomes harder when we look at the MIB. The >> diffServDataPathTable has two indexes: ifIndex and >> diffServDataPathIfDirection. For a given ifIndex, you're going >> to use up the two Direction values for the "real" ingress path >> on the interface (not shown in your picture), and for the >> egress path shown at the right in your picture. The only way >> out that I see is to define a third "direction," something like >> coreToCore, to identify the data paths in the middle of your >> picture. I recognize that this would be a fairly significant >> change to the model. > > > I don't think that is a very significant change for the Model (see above). > The > more significant change is to acknowledge that such multi-stage structures > might > be useful for services built on devices that implement this Model. Still > waiting > for some opinions on whether that is a change for the better or not. > > >> But without it, I think you will have a >> picture of a configuration that the MIB is incapable of >> representing. > > > Something about carts and horses comes to mind ..... > > >> Regards, >> Bob >> >> Bob Moore >> IBM Networking Software >> +1-919-254-4436 >> remoore@us.ibm.com >> >> >> >> Andrew Smith on 12/07/2000 02:43:09 PM >> >> To: Robert Moore/Raleigh/IBM@IBMUS >> cc: diffserv >> Subject: Re: [Diffserv] Model draft - sharing elements on multiple >> interfaces >> >> >> >> Bob, >> >> Without diving into the details for now, can we agree that, if the > > "ingress > >> SLS >> shared over multiple interfaces" idea is interesting, then so is the >> *egress* >> one? Seems like some operations folks out there might be very interested > > in > >> this >> ..... no? (think: multi-tenant buildings, metro services?) >> >> Now diving into the details, the egress picture I would draw would be > > more > >> like: >> >> +---------+ +----------+ >> | |i/f 1---\ | |--> i/f 1 >> | | \ |Another | >> |Routing |i/f 2----->meter-->|Routing |--> i/f 2 >> |Core | / |Core | >> | |i/f 3---/ | |--> i/f 3 >> +---------+ +----------+ >> >> It is of no business to the Diffserv elements how the traffic gets split >> back >> out to the interfaces on the r.h.s. so it is appropriate to model that >> function >> as a black box (in this Model document). A "Classifier" at that point is >> not the >> right functional block to perform the routing functions (which may be as >> simple >> as "do the same thing as the prior Routing Core did" - it's not our >> business to >> describe how it might do that). >> >> Andrew >> >> >> Robert Moore wrote: >> >> >> >>> Andrew, >>> >>> I'm still having trouble with the egress half of your >>> symmetric solution. Here's how I visualize your idea >>> of metering aggregated traffic across a set of egress >>> interfaces: >>> >>> +---------+ +----------+ >>> | |i/f 1---\ | |--> i/f 1 >>> | | \ | | >>> |Routing |i/f 2----->meter-->|classifier|--> i/f 2 >>> |Core | / | | >>> | |i/f 3---/ | |--> i/f 3 >>> +---------+ +----------+ >>> >>> In words, the Routing Core does whatever it does to >>> route packets (which is *outside* the scope of >>> DiffServ), and for each packet selects egress i/f >>> 1, 2, or 3. The data paths for these three egress >>> interfaces then merge into a single meter, to >>> provide the metering for the aggregated traffic. >>> The meter is followed by a classifier, which fans >>> the packets back out to their respective interfaces >>> for queueing, scheduling, etc. >>> >>> It's the classifier that I don't understand. If the >>> Routing Core selects an egress interface for a packet >>> based on routing criteria that are outside the scope of >>> DiffServ, then how can the classifier get each packet >>> back to the correct interface? What is it filtering >>> on? It can't base its decision on which interface >>> the packet traversed just before the meter, because >>> the model stipulates that a packet doesn't "remember" >>> where it has been. >>> >>> Do you have a different way of thinking about this >>> situation, one that doesn't run into this problem? >>> >>> Regards, >>> Bob >>> >>> Bob Moore >>> IBM Networking Software >>> +1-919-254-4436 >>> remoore@us.ibm.com >>> >>> >>> >>> Andrew Smith on 12/06/2000 01:38:08 PM >>> >>> To: Robert Moore/Raleigh/IBM@IBMUS >>> cc: diffserv >>> Subject: Re: [Diffserv] Model draft - sharing elements on multiple >>> interfaces >>> >>> >>> >>> Bob, >>> >>> I think you're trying to craft a compromise with Keith here but what you >>> propose >>> is inconsistent. [Note that I didn't mention the MIB in my message: the >> >> MIB >> >> >>> can >>> implement a subset of the model if it so chooses, so long as it is not >>> inconsistent with the model, but that's not the point I raised - by all >>> means >>> discuss the impact of this issue on the MIB in a separate thread but >> >> don't >> >> >>> let >>> that confuse this discussion of the model]. >>> >>> The point in question is whether "shared-between-multiple-interfaces" >>> elements >>> are both (a) useful for implementing specific services and (b) likely to >> >> be >> >> >>> implemented by more than one vendor and (c) without this change, does it >>> make it >>> impossible/unlikely that the model can be used to represent a >> > significant > >>> set of >>> devices? I believe that, for (a), the model needs to be symmetric: if >> >> such >> >> >>> a >>> service is useful for "in" then it is also for "out" e.g. metering on a >>> collection of interfaces representing one customer is just as useful in >>> both >>> directions. As regards (b), I'd like to hear some more opinions: so far >> >> the >> >> >>> exit >>> poll (3 opinions) seems to read: >>> >>> In? Out? >>> Y/N Y/N >>> 2/1 1/2 >>> >>> (if that notation makes sense). And for (c) I'm not sure we have any >> > data > >>> points. >>> >>> >>> Andrew >>> >>> >>> Robert Moore wrote: >>> >>> >>> >>> >>>> Keith, >>>> >>>> If I'm understanding you correctly, then I think I agree >>>> with you. We can allow the sharing of conditioning >>>> elements in the ingress case, but continue to rule it out >>>> for egress. This covers a case like a single meter that >>>> processes traffic aggregated from several ingress >>>> interfaces, which seems like something we want to allow. >>>> But it doesn't complicate the MIB in the egress case. >>>> >>>> If we allow sharing of conditioning elements for ingress >>>> interfaces, I think there are two cases that need to be >>>> mentioned in the MIB: >>>> >>>> - Two DataPathStart pointers pointing to the same >>>> element. If we leave it at that, we have no answer >>>> to the question "Which data path is the element >>>> *really* on?" But I think this is OK -- we can >>>> say that it's equally on both data paths. >>>> - A "next" pointer in a conditioning element pointing >>>> to a next conditioning element on a different >>>> data path. >>>> >>>> The MIB would also have to say clearly that these two >>>> options are *not* allowed for egress data paths. >>>> >>>> For Andrew's picture, I think it would be fine to >>>> combine the new version for the ingress side with the >>>> old version for the egress side. >>>> >>>> Does this sound good to everybody? >>>> >>>> Regards, >>>> Bob >>>> >>>> Bob Moore >>>> IBM Networking Software >>>> +1-919-254-4436 >>>> remoore@us.ibm.com >>>> >>>> >>>> >>>> Keith McCloghrie @ietf.org on 12/05/2000 05:19:33 PM >>>> >>>> Sent by: diffserv-admin@ietf.org >>>> >>>> >>>> To: Robert Moore/Raleigh/IBM@IBMUS >>>> cc: kzm@cisco.com (Keith McCloghrie), andrew@allegronetworks.com >>> >>> (Andrew >>> >>> >>> >>>> Smith), diffserv@ietf.org (diffserv) >>>> Subject: Re: [Diffserv] Model draft - sharing elements on multiple >>>> interfaces >>>> >>>> >>>> >>>> Bob, >>>> >>>> I was arguing against additional complexity, which was what I believed >>>> would ensue from Andrew's proposed change from: >>>> >>>> >>>> >>>> >>>> >>>>>> -> I -> core -> E -> >>>>>> >>>>>> The proposal would be to modify this to something like: >>>>>> >>>>>> -> I -+-> I -> core -> E -+-> E -> >>>>>> | | >>>>>> -> I -+ +-> E -> >>>>> >>>> I think it would be possible to allow merging on ingress just by >>>> removing the restriction on two data paths merging, which is stated >>>> in this ASN.1 comment (I think that's the only place it's specified): >>>> >>>> -- The use of next pointer to point to diffserv functional datapath >>>> -- element of a different datapath is not allowed >>>> >>>> I agree it's harder for egress which requries splitting, for which >>>> I think the current MIB structure is insufficient, and my concern is >>>> that a MIB structure which would allow it is going to be more complex. >>>> >>>> Keith. >>>> >>>> >>>> >>>> >>>> >>>> >>>>> Keith, >>>>> >>>>> I'm not sure what you're arguing for here. At least >>>>> on the ingress side, sharing an element (say a >>>>> Classifier) between two ingress interfaces amounts >>>>> to having the dataPathStart pointers for two entries >>>>> in the dataPathTable point to the same entry in the >>>>> diffServClassifier table. Are you saying that the MIB >>>>> currently rules this out? If so, I've missed it. Or >>>>> are you saying that while the MIB doesn't currently >>>>> rule it out, it should be changed so that it does? >>>>> >>>>> It's a little harder to describe for egress, but I >>>>> think the idea would be that two Data Paths start out >>>>> together, but then somehow diverge before they're done. >>>>> I'm not sure exactly how to express this in terms of >>>>> the Next pointers, but the same question I asked you >>>>> above applies here as well: do you think that the MIB >>>>> currently does outlaw this setup, or do you think that >>>>> it should (but doesn't now)? >>>>> >>>>> Thanks. >>>>> >>>>> 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://www2.ietf.org/mail-archive/working-groups/diffserv/current/maillist.html > > > > _______________________________________________ > diffserv mailing list > diffserv@ietf.org > http://www1.ietf.org/mailman/listinfo/diffserv > Archive: > http://www2.ietf.org/mail-archive/working-groups/diffserv/current/maillist.html > > > > > _______________________________________________ > diffserv mailing list > diffserv@ietf.org > http://www1.ietf.org/mailman/listinfo/diffserv > Archive: http://www2.ietf.org/mail-archive/working-groups/diffserv/current/maillist.html _______________________________________________ diffserv mailing list diffserv@ietf.org http://www1.ietf.org/mailman/listinfo/diffserv Archive: http://www2.ietf.org/mail-archive/working-groups/diffserv/current/maillist.html From diffserv-admin@ietf.org Mon Dec 11 00:07: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 SMTP id AAA27730 for ; Mon, 11 Dec 2000 00:07:33 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id XAA22739; Sun, 10 Dec 2000 23:49:02 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id XAB22708 for ; Sun, 10 Dec 2000 23:48:57 -0500 (EST) Received: from cisco.com (sigma.cisco.com [171.69.63.142]) by ietf.org (8.9.1a/8.9.1a) with SMTP id XAA23629 for ; Sun, 10 Dec 2000 23:48:54 -0500 (EST) Received: from andreawlap (sj-dial-4-32.cisco.com [171.68.181.161]) by cisco.com (8.8.8-Cisco List Logging/8.8.8) with SMTP id UAA14736; Sun, 10 Dec 2000 20:47:44 -0800 (PST) From: "Andrea Westerinen" To: Cc: "diffserv" , "Randy Bush" Date: Sun, 10 Dec 2000 20:52:06 -0800 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2910.0) Importance: Normal In-Reply-To: <3A2BA02D.1FA4582B@mediaone.net> X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2919.6700 Content-Transfer-Encoding: 7bit Subject: [Diffserv] RE: snmpconf FW: November Milestones Sender: diffserv-admin@ietf.org Errors-To: diffserv-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Diffserv Discussion List X-BeenThere: diffserv@ietf.org Content-Transfer-Encoding: 7bit Some of the info modeling work may be pertinent here. Some of the models separate state and current operational data from configuration information. The latter is described by Setting classes and collected into Configuration aggregations. You can send clearly defined Setting classes and instances to a device. You can "apply" these Settings to a device and/or its components. You can retrieve (read mostly) current state/operational data from other classes and instances. Just FYI... Andrea -----Original Message----- From: owner-snmpconf@snmp.com [mailto:owner-snmpconf@snmp.com]On Behalf Of Jon Saperia Sent: Monday, December 04, 2000 5:46 AM To: snmpconf@snmp.com Cc: diffserv; Randy Bush Subject: Re: snmpconf FW: November Milestones > Randy's point is well made - I don't think it is a rathole - and is directly > relevant to the MIB/PIB/snmpconf/DSMON discussions for diffserv management. In > the various iterations of the diffserv MIB we have veered between extremes of > optimise-for-read and optimise-for-configure without, I think, a clear idea of > why. The -04 version tended towards the former whilst the latest incarnation > (-06) veers back towards the latter in the interests of consistency with the PIB > work and the "template" concept for the diffserv policy MIB (snmpconf WG). > Should we treat these as valid reasons to sacrifice read performance or should > we find another way to optimise opbjects for configuration e.g. by duplication > (indexing of same information in multiple ways)? Right now, I believe the -06 > MIB does cause additional complexity for reading. > > Andrew > It is often the case that read only MIB documents are not well designed in a number of respects. Relevant to this discussion is that the indices are often created with implementation ease in mind. It is more difficult to implement a table with multiple indices (regardless of basic technology) than to use simple integer index values. This is true whether the objects are read only or read write. This poor design, while easy for software engineers, causes unnecessary data collection overhead since it is more difficult to 'scope' what you want to retrieve (Randy indirectly alluded to this in a previous post). In some cases, the design makes it quite difficult not mater how much data you collect to understand what it means in terms of the configuration. My view is that the additional complexity for configuration will pay off in terms of better quality data and less data movement. This is not to say -06 is just right, there are other who can better assess that. My point is that it is worth the work. /jon _______________________________________________ diffserv mailing list diffserv@ietf.org http://www1.ietf.org/mailman/listinfo/diffserv Archive: http://www2.ietf.org/mail-archive/working-groups/diffserv/current/maillist.html From diffserv-admin@ietf.org Mon Dec 11 02:25: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 SMTP id CAA19500 for ; Mon, 11 Dec 2000 02:25:00 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id BAA00417; Mon, 11 Dec 2000 01:37:52 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id BAA00386 for ; Mon, 11 Dec 2000 01:37:43 -0500 (EST) Received: from usc.edu (root@usc.edu [128.125.253.136]) by ietf.org (8.9.1a/8.9.1a) with SMTP id BAA24211 for ; Mon, 11 Dec 2000 01:37:43 -0500 (EST) Received: from aludra.usc.edu (demir@aludra.usc.edu [128.125.253.184]) by usc.edu (8.9.3.1/8.9.3/usc) with ESMTP id WAA06748; Sun, 10 Dec 2000 22:37:37 -0800 (PST) Received: from localhost (demir@localhost) by aludra.usc.edu (8.9.3.1/8.9.3/usc) with ESMTP id WAA26964; Sun, 10 Dec 2000 22:37:38 -0800 (PST) Date: Sun, 10 Dec 2000 22:37:38 -0800 (PST) From: demir To: "Manfredi, Albert E" cc: "'Anna Charny'" , diffserv@ietf.org Subject: RE: [Diffserv] Possible compromise between EFRESOLVE and draft-ch arny In-Reply-To: <4102273CEB77D211869200805FE6F593018C5BDD@xch-phl-01.he.boeing.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: diffserv-admin@ietf.org Errors-To: diffserv-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Diffserv Discussion List X-BeenThere: diffserv@ietf.org What is the "limit" of EF's (EFRESOLVE's) "misterious" properties that is "stepped further" whenever a new argument is made? (I know EFRESOLVE is only a draft). > The underlying idea of EF, whether we can state this or no, has always been > (has it not?) to support a service similar to CBR, or approaching CBR, for > an aggregate flow. So S will determine how CBR-like this EF flow will be. Where is this underlying idea stated? > If some non-FIFO schedulers will result in large values of S, seems to me > that those schedulers are simply not ideal for EF use. Why is this an issue? To me, it seems that "EF" dominates everything. It seems without understanding "EF", one can not implement Diffserv-compatible boxes/other PHBs. (I am aware of the your argument saying that: then forget these scheduler, that's diffserv. If that is the case then Diffserv dominates a box, is this "scalable"?). Everything will depend on "EF". Alper K. Demir _______________________________________________ diffserv mailing list diffserv@ietf.org http://www1.ietf.org/mailman/listinfo/diffserv Archive: http://www2.ietf.org/mail-archive/working-groups/diffserv/current/maillist.html From diffserv-admin@ietf.org Mon Dec 11 04:48: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 SMTP id EAA01349 for ; Mon, 11 Dec 2000 04:48:36 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id EAA02434; Mon, 11 Dec 2000 04:28:10 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id EAA02324 for ; Mon, 11 Dec 2000 04:28:02 -0500 (EST) Received: from mta5.snfc21.pbi.net (mta5.snfc21.pbi.net [206.13.28.241]) by ietf.org (8.9.1a/8.9.1a) with SMTP id EAA26779 for ; Mon, 11 Dec 2000 04:28:00 -0500 (EST) Received: from allegronetworks.com ([206.170.1.252]) by mta5.snfc21.pbi.net (Sun Internet Mail Server sims.3.5.2000.01.05.12.18.p9) with ESMTP id <0G5E00CTJCF1DG@mta5.snfc21.pbi.net> for diffserv@ietf.org; Mon, 11 Dec 2000 01:16:15 -0800 (PST) Date: Mon, 11 Dec 2000 01:24:12 -0800 From: Andrew Smith To: diffserv Message-id: <3A349D3C.1090803@allegronetworks.com> Organization: Allegro Networks MIME-version: 1.0 Content-type: text/plain; charset=us-ascii; format=flowed Content-transfer-encoding: 7bit User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; m18) Gecko/20001108 Netscape6/6.0 X-Accept-Language: en Content-Transfer-Encoding: 7bit Subject: [Diffserv] Diffserv MIB - editorial comments (part 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 Content-Transfer-Encoding: 7bit These are all editorial fixups on the preamble (up to and including section 6) - maybe more to follow on the MIB module itself). Andrew ================================================================ 1. General: make consistent Diffserv and DiffServ. Other documents have generally chosen "Diffserv". 2. General: several places where it says "Notice that ..." - these should be replaced by "NOTE: ...": this is standards-speak for indicating that the following is just explanation and is not making any normative rules. 3. Abstract: "Differentiated Services Router Informal Management Model" -> "Informal Management Model for Diffserv Routers" 4. 2.1 instructmentation -> instrumentation 5. 2.1 functionalities -> functionality 3. 2.1 "and only mentioned" -> and is only mentioned" 4. 2.1 "By not including TCB notion in its parameters, this MIB allow any grouping of elements to construct TCBs, using rules indicated by the [MODEL]. This will minimize changes to this MIB if rules in [MODEL] changes." Grammar, confusing. How about: "By not using the TCB concept, this MIB allows any grouping of elements to construct TCBs using the rules defined by [MODEL]: that document should be consulted for the allowed combinations of elements that make up a TCB." 5. 2.2: "thru" -> "through" 6. 2.3 "full-filled" -> "fulfilled" "thru out" -> "throughout" 7. 3. "reuse" -> "reused" 8. 3. "intented" -> intended" 9. 3.1. "provide" -> "provides" 10. 3.1. "Functional Elements" -> "Functional Datapath Elements" multiple times, also in 3.1.1. 11. 3.1.1. "of none existence of DiffServ Treatments" -> "of non-existence of DiffServ functional datapath elements" (multiple times). 12. 3.1.1. "entries can be created" -> "entries can be configured" (they can be modified as well as created). 13. 3.2.1. "With each" -> "Each" 14. 3.2.1. "A data path may consist of more than one Classifier, the order the classification processes aplies to the traffic is the same as the order the classifier table entries are linked in the data path." change to "A datapath may contain more than one Classifier: the order in which the classification process applies them to the traffic is the same as the order in which the classifier table entries are linked in the datapath." 15. 3.2.2. "handles" -> "handle" 16. 3.5.2. "multiple drop processes ... be" -> "multiple drop processes ... to be" 17. 3.5.2. "parameters may include the sampling rate" -> "parameters may include the sampling interval or rate" 18. 3.5.3. "parameterized" -> "parameterize" 19. 3.5.3. Suggest reword: "When new scheduling methods need to be defined, and no new scheduling parameters are needed, just need to add a new OBJECT-IDENTITY definition in some other MIB, with description of how the existing scheduling parameters will be used by the new scheduling method." -> "If an additional scheduling method needs to be defined and no new scheduling parameters are needed, a new OBJECT-IDENTITY definition can be made in some other MIB module, with a description of how the existing scheduling parameters will be used by the new scheduling method." 20. 4.1. Suggest delete: "This example has been explained in sufficient detail in [MODEL] section 8.1, please use that as a reference." 21. 4.2.1 "DataPathTable" -> "diffServDataPathTable" "ClfrElement" -> "Classifier Element" "seperations" -> "separations" "Minimumly" -> "Minimally" 22. 4.2.2 "mutliple" -> "multiple" 23. 5.2 "indicate" -> "indicates that". Other grammar also - but see tech comment on this paragraph. _______________________________________________ diffserv mailing list diffserv@ietf.org http://www1.ietf.org/mailman/listinfo/diffserv Archive: http://www2.ietf.org/mail-archive/working-groups/diffserv/current/maillist.html From diffserv-admin@ietf.org Mon Dec 11 04:49: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 SMTP id EAA01622 for ; Mon, 11 Dec 2000 04:49:48 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id EAA02459; Mon, 11 Dec 2000 04:28:13 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id EAA02329 for ; Mon, 11 Dec 2000 04:28:03 -0500 (EST) Received: from mta5.snfc21.pbi.net (mta5.snfc21.pbi.net [206.13.28.241]) by ietf.org (8.9.1a/8.9.1a) with SMTP id EAA26781 for ; Mon, 11 Dec 2000 04:28:01 -0500 (EST) Received: from allegronetworks.com ([206.170.1.252]) by mta5.snfc21.pbi.net (Sun Internet Mail Server sims.3.5.2000.01.05.12.18.p9) with ESMTP id <0G5E00C25CFNAL@mta5.snfc21.pbi.net> for diffserv@ietf.org; Mon, 11 Dec 2000 01:16:39 -0800 (PST) Date: Mon, 11 Dec 2000 01:24:34 -0800 From: Andrew Smith To: diffserv Message-id: <3A349D52.1080108@allegronetworks.com> Organization: Allegro Networks MIME-version: 1.0 Content-type: text/plain; charset=us-ascii; format=flowed Content-transfer-encoding: 7bit User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; m18) Gecko/20001108 Netscape6/6.0 X-Accept-Language: en Content-Transfer-Encoding: 7bit Subject: [Diffserv] MIB - technical comments (part 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 Content-Transfer-Encoding: 7bit Here are some technical comments on the MIB document: these start at the beginning and go as far as the start of the MIB section. At the end there are also a few comments on the MIB module too although these are not complete - more to come on that. Feel free to act on or ignore as the WG sees fit. Andrew ====================================== 1. 2.1 (This comment is somewhat related to the ongoing discussion with Bob Moore on the mailing list). A term is introduced here, "Data Path", which is somewhat different to the "Datapath" idea used in the Model draft. From [MODEL]: "Datapath A conceptual path taken by packets with particular characteristics through a Diffserv router. Decisions as to the path taken by a packet are made by functional datapath elements such as Classifiers and Meters." The usage in the MIB document is different to this i.e. it is single interface, single direction. The last paragraph of 2.1 could also use some clarification: e.g. "The notion of a Datapath introduced in [MODEL] is used in this MIB to indicate the DiffServ processing that a packet experiences as it travels in a given direction ("in" or "out") of a given interface of a Diffserv device. A diffServDataPathTable contains entries that indicate the first of possibly multiple functional datapath elements that will apply DiffServ treatment to the packet." That's closer to consistency. But then there's a comment down in the MIB: "Each entry of the diffServQTable belongs to one and only one datapath." This is a more specific usage of "datapath" than up in 2.1: Is this supposed to be saying that a datapath is the complete collection of functional datapath elements that exist for a given {interface,direction} combination? That would conflict with the usage in [MODEL] where it means just a single potential path (and thus would allow multiple such paths to merge into the same queue). 2. 2.2 "These elements are designed with their parameterization tables separated from their data path linkage tables, allowing reuse of each table as much as possible. The data path linkage in this MIB is coupled with interface thru the use of diffServDataPathTable. The concept of "interface" is as for the InterfaceIndex/ifIndex of the IETF Interfaces MIB [IFMIB]." Not sure what most of this has to do with "Relationship to other MIBs and Policy Management" (keep the Interfaces MIB reference though). There are too many forward references here for legibility. Suggest this belongs later on after ideas such as "parameterization table" and "data path linkage table" have been defined. 3. 2.3 para 1: "the sequential DiffServ treatments being applied to a packet, and the parameterization of these treatments" Suggest use existing terms, rather than "treatments" e.g. "the sequence of DiffServ functional datapath elements that act on a packet, as well as the parameterization of these elements". 4. 2.3 para 1: Not sure what a "data definition" is. 5. 2.3 para 2: "router" has been replaced with "Diffserv network device" here but there are several other places that still talk about "router". Seems like this change is decreasing consistency with other Diffserv documents - suggest that we need WG consensus to make this change (else this would be just an editorial comment). 6. 2.3 "Data Path Table A general extensible framework for describing the starting point of DiffServ datapaths within a single DiffServ device." Not sure why this is described as a "general extensible framework" - it's just a table, not intended to be extended, and it is complete, not just a framework. 7. 2.3 "Classifier and Filter Tables A general extensible framework and one example of a parameterization table - filter table (an IP Six-Tuple Multi-Field Classification Table)." What is a "parameterization table - filter table"? Suggest we nuke the "parameterization table - ". 8. 2.3 "Meter Tables A general extensible framework and one example of a parameterization table - TBMeter table, applicable for Simple Token Bucket Meter, Average Rate Meter, Single Rate Three Color Meter, Two Rate Three Color Meter, and Sliding Window Three Color Meter." Suggest that, if this meter table is really suitable for all those different types of meter then it shouldn't be called "TBMeter table" any more. 9. 3 "DiffServ treatment parameterization" is used in several places: see comment 3 above, but suggest we use some other existing terms e.g. "paramterisation of DiffServ functional datapath elements". 10. 3 "... allowing the flexibility to maintain a common data construct for DiffServ device configuration and provisioning, independent of the configuration/provisioning method used." A distinction is introduced between configuration and provisioning without really defining what is meant by each. Either need to provide definitions or references and explain why we distinguish between them here. 11. 3 "The definitions in this MIB are intented to be reused by the DiffServ PIB and SNMPCONF working group's DiffServ Policy MIB.". This may be too specific a forward-reference for this document. Suggest "The definitions in this MIB are intended to be reusable verbatim by other future standards." 12. 3.1 "Given some basic information, e.g. ifIndex and interface direction, the first DiffServ Functional Element is determined." Define "first". 13. 3.1 "The data path can be redefined to allow a different level of control other than interface level control currently defined in this MIB. There is on-going work in this area, most notably the development of Policy Information Base in DiffServ and RAP working groups, and DiffServ Policy MIB in SNMPCONF working group." Again, this forward-reference probably doesn't belong here. I don't understand what is meant by "the data path can be redefined ..." 14. 3.1.1 "As indicated in section 2.2, with some modification/extension of the Data Path Table, most of the tables and their entries are reusable by other Policy Management mechanisms." Suggest we nuke this sentence (not relevant to this MIB). 15. 3.1.1. "For indication of none existence of DiffServ Treatments, entries can be created with zeroDotZero in the diffServDataPathStart attribute to indicate this explicitly. The none existence of DiffServ Treatment can also be indicated implicitly by not having the entry at all. The explicit/implicit selection is up to the implementation. This means allow normal IP device processing when zeroDotZero is used in the diffServDataPathStart attribute, or when the entry does not exist. Normal IP device processing will depend on the device, for example, this can be forwarding the packet." Why do we offer such an implementation choice? Choices are bad. Pick one - suggest "implicit". I'd propose: "The non-existence of any Diffserv functional datapath elements on an interface/direction is indicated implicitly by having no corresponding entry in this table." Much simpler. 16. 3.2. "Order is present only to resolve ambiguity, by use of "order" here and "precedence" in [MODEL]" Why the change to use different terminology to [MODEL]? Previous MIB drafts used "precedence" here quite happily. 17. 3.2. I'm confused by the introduction of the terms "classifier element" and "filter specification" (previously we had just "classifier" and "filter"). Need to explain these new terms and how it relates to the others (particularly since "filter specification" means something different in Intserv documents). 18. 3.2. "The classifiers specified here are at the interface level, they may be derived from some more general policies ..." I'm not sure what this sentence means any more (it made slightly more sense in previous versions, but not a lot) and it applies to many of the other element types as well. Suggest we nuke the paragraph. 19. 3.2.1. "entries .... get linked from ..." We don't have a concept of back pointers here so it would be best to phrase this as "entries .... are pointed at by ..." instead. 20. 3.2.1. But more problemmatical is: "It is the entries in the Classifier Table that get linked from the upstream diffserv functional datapath element, i.e. an entry in diffServDataPathTable." The entries in diffServDataPathTable do *not* represent functional datapath elements! I think what is meant is something like: "It is the entries in the Classifier Table that are pointed at by the entries in diffServDataPathTable." 21. 3.4.2 "Notice counter support is implementation specific. Where within a data path and for what purpose a counter exists can be different between implementations. It is advisable to have at least one counter within a data path and have different counts derived from DiffServ counters and counters defined in other MIBs." I have a problem with this text - it seems to say nothing useful for a standard. Is the advice meant for an implementor or a manager? Suggest we nuke this paragraph. See also similar sentence in 4.2.2 - the "should" there is similarly ambiguous. 22. 3.5.2. The figure 1 no longer matches the definitions in the MIB. 23. 3.5.2. This section ought to mention the usage that random-drop makes of the diffServAlgDropQThreshold value (it's described down in the MIB under diffServAlgDropType and diffServRandomDropMaxThreshBytes). 24. 3.5.2 "The availability of diffServRandomDropSamplingRate as readable is important, the information provided by Sampling Rate is essential to the configuration of diffServRandomDropInvWeight. Having Sampling Rate be configurable is also helpful, as line speed increases, the ability to have queue sampling be less frequent than packet arrival is needed." I can't fully parse the last sentence of this discussion but I think I understand what it means and disagree with the reasoning (as I have done all along over the last year or so): what is presented is an argument for having the implementation change its sampling rate according to changing line speed. It is *not* an argument for having the net manager change it. I'm still not convinced that this variable is that useful (to a net manager) and it certainly must be made optional in the conformance section, if included at all. And if diffServRandomDropInvWeight is optionally read-only then the argument presented means that there is no need to have diffServRandomDropSamplingRate mandatory (we could make it mandatory iff you implement a configurable diffServRandomDropInvWeight). But did I miss the discussion where the WG decided to include this variable at all? 25. 3.5.3 "The [MODEL] section 7.1.2 describes a a scheduler with multiple inputs: this is represented in the MIB by having the scheduling parameters be associated with each input. In this way, sets of Queues can be be grouped together as inputs to the same same Scheduler." This is somewhat confusing: input to what? Suggest: "The [MODEL] section 7.1.2 describes a a scheduler with multiple inputs: this is represented in the MIB by having the scheduling parameters for servicing the queue at each input to the scheduler be referenced by the queue table entry itself. In this way, sets of Queues can be be grouped together as inputs to the same same Scheduler." 26. 3.5.3 The changes that were made since -04 draft on the following paragraph make it no longer make sense: "For representing a Strict Priority scheduler, each scheduler input is assigned a priority with respect to all the other inputs feeding the same scheduler, with default values for the other parameters. A higher-priority input will be serviced first over a lower-priority priority input, assuming that all guarantees have already been met." Since this is now describing a Strict Priority scheduler, where does the concept of a "guarantee" come from? I prefer the -04 draft version (yes, I wrote that paragraph :-)) which explains how the parameter works, in general, not just in the specific case of a Strict Priority scheduler (which is just an example). The original paragraph was: "Each scheduler input, as represented by a Queue Table entry, is assigned a priority with respect to all the other inputs feeding the same scheduler. A higher-priority input will be serviced first over a lower-priority priority input, assuming that all guarantees have already been met. This priority parameter, used on its own with default values for the other parameters, serves to allow representation of a Strict Priority scheduler." Suggest we go back to the original. 27. 3.5.3. The changes here seem now to imply that a scheduler can no longer offer guaranteed minimum bandwidths as well as sometimes limiting to a maximum (the OID pointers in the MIB make these exclusive and there is only a single leaky-bucket Burst Size parameter). I think that is too limiting - there are, literally, several millions of deployed examples of schedulers that quite happily do both. The example in 4.2.3 also seems to indicate that, if you want to do shaping, it is likely done *after* all other scheduling whereas, in my experience, it is much more likely that shaping will be done separately on each class, rather than on the complete output to a link - so I think Figure 6 is somewhat of a strange example. DiffServSchdParamEntry: does diffServSchdParamBurstSize apply to the Max or to the Min? But what is needed are separate burst sizes for the Min and Max leaky-buckets - this was described in 3.4.3 of the -04 MIB as follows: "For Weighted Queueing algorithms e.g. WFQ, WRR, the "weight" of a given scheduler input is represented with a Minimum Service Rate leaky-bucket profile which provides guaranteed bandwidth to that input, if required. This is represented, as were token-bucket meters, by a rate diffServQueueMinRateAbs and a burst size diffServQueueMinBurstSize. The rate may, alternatively, be represented by a relative value, as a fraction of the interface's current line rate, diffServQueueMinRateRel to assist in cases where line rates are variable or where a higher-level policy might be expressed in terms of fractions of network resources. The two rate parameters are inter-related and changes in one may be reflected in the other. An input may also be capable of acting as a non-work-conserving [MODEL] traffic shaper: this is done by defining a Maximum Service Rate leaky- bucket profile in order to limit the scheduler bandwidth available to that input. This is represented, similarly to the minimum rate, by a rate diffServQueueMaxRateAbs and a burst size diffServQueueMaxBurstSize. The rate may, alternatively, be represented by a relative value, as a fraction of the interface's current line rate, diffServQueueMaxRateRel." Except that we forgot back then to put the two burst size parameters into the MIB module - duh! This is also consistent with [MODEL]. 28. 4.1 Figures 2,3,4: I find the use of text names for the "xxxId" values to be confusing: in the MIB (and the example in [MODEL] too) these are integers and to use text strings here in the figures seems confusing: for one thing the text strings imply semantics e.g. "AF", "EF" that may or may not be appropriate; for another, the same text string is used in multiple places for Ids that may or may not be identical (e.g. AF11 in at least 3 places in figure 2). Also,, the spaghetti could be a bit straighter - e.g. place the AbsDrop box below the Counter one in figure 2, avoid the crossing arrows in Figure 3. 29. 4.2.1 "Another level of classification can be defined that follows the Action functional datapath elements in Figure 5. This second level of classifiers and their subsequent functional datapath elements would be considered as in another TCB." Why refer to TCB at this point? It's the first time since saying up top that we wouldn't be considering them here. 30. 4.2.1 The last example here could use some more introduction in the way of "this example is here because .... if conveys the following benefits ..." etc. 31. 4.2.2. "for trTCM": what is this? need a reference or else spell it out "two-rate three-colour marker". BTW, I thought trTCM was a Marker, not a Meter .... are you here describing a Meter that can be used to measure the output of a trTC *Marker*? If so, needs some re-wording. 32. 5.2. "StaticRowPointer also clearly indicate the identified conceptual row's content does not change, hence they can be simultaneously used, pointed to, by more than one data path linkage table entries." Not sure that that really means what it says: surely the contents of a conceptual row are allowed to be changed. Is it just the existence of the row that is supposed to be constant? 33. StaticRowPointer definition: do you want comments on this here on on the other separate ID? Is the text pasted in unchanged? 34. diffServClfrElementEntry: INDEX { diffServClfrElementClfrId, diffServClfrElementId } These should be reversed to match the order of the objects in DiffServClfrElementEntry (or vice versa). 35. diffServRandomDropInvProbMax: Again, did I miss some discussion where the WG decided to use an "inverse probability" rather than a percent*100 for Pmax (as it was in -04)? It's possible I'm not interpreting the DESCRIPTION correctly: "The worst case random drop probability, expressed as the inverse of the drop probability. With special case of the value zero meaning zero probability of drop. For example, if every packet may be dropped in the worst case (100%), this has the value of 4,294,967,295." As it is now I think I can represent Pmax of 1, 0.5, 0.25, 0.125 etc. with MIB values of 1, 2, 3, 4 respectively, but no intermediate values (but then why does 4294967295 represent 100% - why not 1? SO I am obivously confused). But we've been through this many times before and I thought we had consensus on using percent*100. I guess I must have blinked. 36. diffServSchdParamPriority: is described as: "The priority of this queue, to be used as a parame- ter to the next scheduler element downstream from this one." I'm confused about which "this" is intended and what "downstream" means: I don't think these descriptions in diffServSchdParamEntry should be talking about queues since they are used for both Queue Table and Scheduler Table entries - they should talk about being parameters of scheduler inputs instead, which is what they really are. So how about just: "The priority of this input to the associated scheduler, relative to others." If "associated" is not clear enough then describe what the association is in the definition of diffServSchdParamEntry. _______________________________________________ diffserv mailing list diffserv@ietf.org http://www1.ietf.org/mailman/listinfo/diffserv Archive: http://www2.ietf.org/mail-archive/working-groups/diffserv/current/maillist.html From diffserv-admin@ietf.org Mon Dec 11 05:36: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 SMTP id FAA14106 for ; Mon, 11 Dec 2000 05:36:56 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id EAA03136; Mon, 11 Dec 2000 04:59:09 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id EAA03102 for ; Mon, 11 Dec 2000 04:59:05 -0500 (EST) Received: from p-mail2.cnet.fr (p-mail2.rd.francetelecom.fr [193.49.124.32]) by ietf.org (8.9.1a/8.9.1a) with SMTP id EAA04225 for ; Mon, 11 Dec 2000 04:59:03 -0500 (EST) Received: by p-voyageur.issy.cnet.fr with Internet Mail Service (5.5.2650.21) id ; Mon, 11 Dec 2000 10:58:24 +0100 Message-ID: <98388C05D464D111B61800805F15041601418A52@p-ibis.issy.cnet.fr> From: ROBERTS James FTRD/DAC/ISS To: diffserv@ietf.org Subject: RE: [Diffserv] Possible compromise between EFRESOLVE and draft-ch arny Date: Mon, 11 Dec 2000 10:58:24 +0100 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: text/plain; charset="iso-8859-1" Sender: diffserv-admin@ietf.org Errors-To: diffserv-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Diffserv Discussion List X-BeenThere: diffserv@ietf.org I still don't understand how EFRESOLVE as it stands can be accepted as a satisfactory PHB definition. Its usefulness depends on it being possible to calculate a sufficiently small value of S for some candidate schedulers under specified conditions of burstiness. It is surely necessary to demonstrate that the definition is meaningful in at least one plausible scenario. No one has yet responded to the request for such an example made initially be Jon Bennett. If, to simplify, we assume there is only EF traffic in the network and the routers provide perfect FIFO output queuing, is it then possible to come up with the "network calculus" necessary to quantify how burstiness evolves from node to node and how it impacts the necessary bound S? Current research (the previously cited paper by Charny and Le Boudec and references therein) would suggest this is extremely difficult or even impossible. The modified rate guarantee given by Bruce Davie avoids the requirement to specify burstiness. The bounds E_a and E_p measure the divergence of a real router from an ideal represented by the perfect FIFO output queuing scheduler referred to above. This obviously doesn't solve the problem of evaluating burstiness and its impact on packet delay variation in the node or through the network. The advantage I see is that it leaves this question in the research domain where it still belongs. The per hop behaviour definition does not depend on a hypothetical solution to a difficult problem. I happen to believe that perfect FIFO output queuing, and slight divergences from it measured by small values of E_a and E_p, would provide a satisfactory basis for building useful end to end services over EF with statistical bounds on delay and delay variation. The necessary network engineering depends significantly on the values of E_a and E_p. On the other hand, I really doubt that it is possible to find a deterministic delay bound S*MTU/R that is sufficiently small to be of any practical use in building services. I therefore add my support to the modified definition of the EF PHB coming from the 'group of twelve'. Jim Roberts _______________________________________________ diffserv mailing list diffserv@ietf.org http://www1.ietf.org/mailman/listinfo/diffserv Archive: http://www2.ietf.org/mail-archive/working-groups/diffserv/current/maillist.html From diffserv-admin@ietf.org Mon Dec 11 06:49: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 SMTP id GAA29608 for ; Mon, 11 Dec 2000 06:49:34 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id GAA04182; Mon, 11 Dec 2000 06:14:37 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id GAA04153 for ; Mon, 11 Dec 2000 06:14:32 -0500 (EST) Received: from usc.edu (root@usc.edu [128.125.253.136]) by ietf.org (8.9.1a/8.9.1a) with SMTP id GAA22138 for ; Mon, 11 Dec 2000 06:14:32 -0500 (EST) Received: from aludra.usc.edu (demir@aludra.usc.edu [128.125.253.184]) by usc.edu (8.9.3.1/8.9.3/usc) with ESMTP id DAA18404 for ; Mon, 11 Dec 2000 03:14:31 -0800 (PST) Received: from localhost (demir@localhost) by aludra.usc.edu (8.9.3.1/8.9.3/usc) with ESMTP id DAA08905 for ; Mon, 11 Dec 2000 03:14:30 -0800 (PST) Date: Mon, 11 Dec 2000 03:14:30 -0800 (PST) From: demir To: diffserv@ietf.org Subject: [Diffserv] need for clear definition of "assurance" in EF 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 In Introduction of EF PHB, the "assured bandwidth" phrase is used. I think this is misleading and "inaccurate". In AF, assurance is "different levels of forwarding assurances for IP packets received from a customer DS domain". Where as, to me, in EF, "assured bandwidth" has different meaning ("available"?) (you might say that "assured" bandwidth makes it assured bandwidth. However "assured" forwarding in AF doesn't make it assured forwarding (assuming "underprovisioned" and/or "traffic conditioning" failure). I agree they are just "words". It would be nicer to make words clear to understand. I have already made my point on providing "assurance" level for EF if one choses to use it (fundamental change :) However, it seems it's okay to change EF's constraint from "rate" to "delay", "delay variance". What is the limit of "expedited"? "no delay", "no delay variance" :) for a packet? "philosophical" change is fine, but "fundamental" is not fine? my 2 cents, Alper K. Demir _______________________________________________ diffserv mailing list diffserv@ietf.org http://www1.ietf.org/mailman/listinfo/diffserv Archive: http://www2.ietf.org/mail-archive/working-groups/diffserv/current/maillist.html From diffserv-admin@ietf.org Mon Dec 11 06:54:50 2000 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with SMTP id GAA00783 for ; Mon, 11 Dec 2000 06:54:50 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id GAA04602; Mon, 11 Dec 2000 06:32:58 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id GAA04572 for ; Mon, 11 Dec 2000 06:32:54 -0500 (EST) Received: from usc.edu (root@usc.edu [128.125.253.136]) by ietf.org (8.9.1a/8.9.1a) with SMTP id GAA26037 for ; Mon, 11 Dec 2000 06:32:53 -0500 (EST) Received: from aludra.usc.edu (demir@aludra.usc.edu [128.125.253.184]) by usc.edu (8.9.3.1/8.9.3/usc) with ESMTP id DAA23324; Mon, 11 Dec 2000 03:32:53 -0800 (PST) Received: from localhost (demir@localhost) by aludra.usc.edu (8.9.3.1/8.9.3/usc) with ESMTP id DAA14112; Mon, 11 Dec 2000 03:32:52 -0800 (PST) Date: Mon, 11 Dec 2000 03:32:52 -0800 (PST) From: demir To: ROBERTS James FTRD/DAC/ISS cc: diffserv@ietf.org Subject: RE: [Diffserv] Possible compromise between EFRESOLVE and draft-ch arny In-Reply-To: <98388C05D464D111B61800805F15041601418A52@p-ibis.issy.cnet.fr> 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 Very nicely said. I have made below points before. However, I haven't received any response. May be, I didn't say that clear(?) > I therefore add my support to the modified definition of the EF PHB coming > from the 'group of twelve'. It didn't happen to me to accept such a solution to be accepted for a PHB where there are "toplogy-dependent" parameters. However, if this is acceptable by Diffserv, I think B. Davie's (and the group's solution) seems a better choice. Alper K. Demir _______________________________________________ diffserv mailing list diffserv@ietf.org http://www1.ietf.org/mailman/listinfo/diffserv Archive: http://www2.ietf.org/mail-archive/working-groups/diffserv/current/maillist.html From diffserv-admin@ietf.org Mon Dec 11 10:14: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 SMTP id KAA05790 for ; Mon, 11 Dec 2000 10:14:24 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id JAA06724; Mon, 11 Dec 2000 09:50:46 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id JAA06696 for ; Mon, 11 Dec 2000 09:50:42 -0500 (EST) Received: from smtppop3pub.verizon.net (smtppop3pub.gte.net [206.46.170.22]) by ietf.org (8.9.1a/8.9.1a) with SMTP id JAA00870 for ; Mon, 11 Dec 2000 09:50:41 -0500 (EST) Received: from PROXIM (lsanca1-ar5-217-030.dsl.gtei.net [4.33.217.30]) by smtppop3pub.verizon.net with SMTP ; id IAA74189590 Mon, 11 Dec 2000 08:45:19 -0600 (CST) Message-ID: <001101c06381$a7e975c0$2ed4e00a@dsl.vz.genuity.net> From: "Bill Courtney" To: "Manfredi, Albert E" , "'Anna Charny'" Cc: References: <4102273CEB77D211869200805FE6F593018C5BDD@xch-phl-01.he.boeing.com> Subject: Re: [Diffserv] Possible compromise between EFRESOLVE and draft-ch arny Date: Mon, 11 Dec 2000 06:50:07 -0800 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.50.4133.2400 X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4133.2400 Content-Transfer-Encoding: 7bit Sender: diffserv-admin@ietf.org Errors-To: diffserv-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Diffserv Discussion List X-BeenThere: diffserv@ietf.org Content-Transfer-Encoding: 7bit Hi Bert, You wrote: > I'm afraid I don't understand the controversy regarding S. > > EFRESOLVE states that EF is defined as an aggregate flow for which the > difference between minimum possible delay and the maximum possible delay is > bounded by some number S X MTU transfer time when the arrival rate of this > incoming EF aggregate flow is specified as R. > > The underlying idea of EF, whether we can state this or no, has always been > (has it not?) to support a service similar to CBR, or approaching CBR, for > an aggregate flow. So S will determine how CBR-like this EF flow will be. > The controversy is based on the fact, as two or three earlier posts have established, that *perfectly fine schedulers* can have values of S that are orders of magnitude greater than the values for *less desirable schedulers*. (See, for example, some of Jon Bennett's mailings from near the time of efresolve's release.) By "perfectly fine," I mean schedulers that introduce little or no jitter or delay, and by "less desirable," I mean schedulers that introduce more jitter. Jon's examples and other similar difficulties with S are by no means exotic or unusual examples. So, S does not provide a useful measure of the worth of a scheduler (i.e., large values might mean anything), and a value of S can be found for almost every scheduler. Thus, efresolve offers us a definition that admits virtually everything and fails to make any useful distinction among the things it admits. > If some non-FIFO schedulers will result in large values of S, seems to me > that those schedulers are simply not ideal for EF use. Why is this an issue? The large values of S may have nothing to do with the usefulness of those schedulers for EF, or they may. It depends on the scheduler. Thus, S is a very poor discriminator. I, too, am mystified as to why there is still an issue. I would have thought that efresolve would have been discarded as an irredeemably failed attempt long ago. Cheers, Bill _______________________________________________ diffserv mailing list diffserv@ietf.org http://www1.ietf.org/mailman/listinfo/diffserv Archive: http://www2.ietf.org/mail-archive/working-groups/diffserv/current/maillist.html From diffserv-admin@ietf.org Mon Dec 11 11:08: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 SMTP id LAA12603 for ; Mon, 11 Dec 2000 11:08:22 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id KAA07507; Mon, 11 Dec 2000 10:43:55 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id KAA07476 for ; Mon, 11 Dec 2000 10:43:51 -0500 (EST) Received: from usc.edu (root@usc.edu [128.125.253.136]) by ietf.org (8.9.1a/8.9.1a) with SMTP id KAA09425 for ; Mon, 11 Dec 2000 10:43:49 -0500 (EST) Received: from aludra.usc.edu (demir@aludra.usc.edu [128.125.253.184]) by usc.edu (8.9.3.1/8.9.3/usc) with ESMTP id HAA20194 for ; Mon, 11 Dec 2000 07:43:51 -0800 (PST) Received: from localhost (demir@localhost) by aludra.usc.edu (8.9.3.1/8.9.3/usc) with ESMTP id HAA07326 for ; Mon, 11 Dec 2000 07:43:50 -0800 (PST) Date: Mon, 11 Dec 2000 07:43:49 -0800 (PST) From: demir To: diffserv@ietf.org Subject: RE: [Diffserv] Possible compromise between EFRESOLVE and draft-ch arny In-Reply-To: <98388C05D464D111B61800805F15041601418A52@p-ibis.issy.cnet.fr> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: diffserv-admin@ietf.org Errors-To: diffserv-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Diffserv Discussion List X-BeenThere: diffserv@ietf.org I think that if B. Davie and his group's definition is the one that will be accepted, it would be better to define B and E_p as: B=SIGMA Bi, where Bi is "bound on the burstiness of the input traffic from i-th interface E_p=SIGMA E_pi, where E_pi is packet error allowed for i-th interface Alper K. Demir _______________________________________________ diffserv mailing list diffserv@ietf.org http://www1.ietf.org/mailman/listinfo/diffserv Archive: http://www2.ietf.org/mail-archive/working-groups/diffserv/current/maillist.html From diffserv-admin@ietf.org Mon Dec 11 11:10:28 2000 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with SMTP id LAA13056 for ; Mon, 11 Dec 2000 11:10:28 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id KAA07397; Mon, 11 Dec 2000 10:38:51 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id KAA07369 for ; Mon, 11 Dec 2000 10:38:47 -0500 (EST) Received: from blv-smtpout-01.boeing.com (blv-smtpout-01.boeing.com [192.161.36.5]) by ietf.org (8.9.1a/8.9.1a) with SMTP id KAA08854 for ; Mon, 11 Dec 2000 10:38:45 -0500 (EST) Received: from stl-av-02.boeing.com ([192.76.190.7]) by blv-smtpout-01.boeing.com (8.9.2/8.8.5-M2) with ESMTP id HAA02848 for ; Mon, 11 Dec 2000 07:38:45 -0800 (PST) Received: from stl-hub-01.boeing.com (localhost [127.0.0.1]) by stl-av-02.boeing.com (8.9.3/8.9.2) with ESMTP id JAA10674 for ; Mon, 11 Dec 2000 09:38:10 -0600 (CST) Received: from xch-phlbh-01.he.boeing.com by stl-hub-01.boeing.com with ESMTP; Mon, 11 Dec 2000 09:38:00 -0600 Received: by xch-phlbh-01.he.boeing.com with Internet Mail Service (5.5.2650.21) id ; Mon, 11 Dec 2000 10:37:58 -0500 Message-Id: <4102273CEB77D211869200805FE6F593018C5BDF@xch-phl-01.he.boeing.com> From: "Manfredi, Albert E" To: "'demir'" , diffserv@ietf.org Subject: RE: [Diffserv] need for clear definition of "assurance" in EF Date: Mon, 11 Dec 2000 10:37:56 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: text/plain; charset="iso-8859-1" Sender: diffserv-admin@ietf.org Errors-To: diffserv-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Diffserv Discussion List X-BeenThere: diffserv@ietf.org Alper Demir wrote: > In Introduction of EF PHB, the "assured bandwidth" phrase is > used. I think > this is misleading and "inaccurate". In AF, assurance is > "different levels > of forwarding assurances for IP packets received from a customer DS > domain". Where as, to me, in EF, "assured bandwidth" has > different meaning > ("available"?) (you might say that "assured" bandwidth makes it > assured bandwidth. However "assured" forwarding in AF doesn't make it > assured forwarding (assuming "underprovisioned" and/or "traffic > conditioning" failure). > I agree they are just "words". It would be nicer to make > words clear to > understand. > I have already made my point on providing "assurance" level > for EF if one > choses to use it (fundamental change :) However, it seems it's okay to > change EF's constraint from "rate" to "delay", "delay > variance". What is > the limit of "expedited"? "no delay", "no delay variance" :) > for a packet? > "philosophical" change is fine, but "fundamental" is not fine? Perhaps I'm reading more into this than I should, but I believe that the practical difference between EF and AF is that EF is intended as a means of making the Link Layer provide CBR-like services, e.g. for UDP flows, whereas AF is meant to use TCP feedback mechanisms to provide a continuum of "assurances," from best effort to something that could be essentially the same as EF. Bert _______________________________________________ diffserv mailing list diffserv@ietf.org http://www1.ietf.org/mailman/listinfo/diffserv Archive: http://www2.ietf.org/mail-archive/working-groups/diffserv/current/maillist.html From diffserv-admin@ietf.org Mon Dec 11 11:40: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 SMTP id LAA20019 for ; Mon, 11 Dec 2000 11:40:19 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id KAA07765; Mon, 11 Dec 2000 10:58:01 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id KAA07733 for ; Mon, 11 Dec 2000 10:57:53 -0500 (EST) 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 SMTP id KAA10985 for ; Mon, 11 Dec 2000 10:57:52 -0500 (EST) Received: from stl-av-02.boeing.com ([192.76.190.7]) by stl-smtpout-01.boeing.com (8.9.2/8.8.5-M2) with ESMTP id JAA05115 for ; Mon, 11 Dec 2000 09:57:50 -0600 (CST) Received: from stl-hub-01.boeing.com (localhost [127.0.0.1]) by stl-av-02.boeing.com (8.9.3/8.9.2) with ESMTP id JAA28937 for ; Mon, 11 Dec 2000 09:57:37 -0600 (CST) Received: from xch-phlbh-01.he.boeing.com by stl-hub-01.boeing.com with ESMTP; Mon, 11 Dec 2000 09:57:25 -0600 Received: by xch-phlbh-01.he.boeing.com with Internet Mail Service (5.5.2650.21) id ; Mon, 11 Dec 2000 10:57:24 -0500 Message-Id: <4102273CEB77D211869200805FE6F593018C5BE0@xch-phl-01.he.boeing.com> From: "Manfredi, Albert E" To: "'Bill Courtney'" Cc: diffserv@ietf.org Subject: RE: [Diffserv] Possible compromise between EFRESOLVE and draft-ch arny Date: Mon, 11 Dec 2000 10:57:23 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: text/plain; charset="iso-8859-1" Sender: diffserv-admin@ietf.org Errors-To: diffserv-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Diffserv Discussion List X-BeenThere: diffserv@ietf.org Thanks for the reply, Bill. Bill Courtney wrote: > The controversy is based on the fact, as two or three earlier posts > have established, that *perfectly fine schedulers* can have > values of S > that are orders of magnitude greater than the values for *less > desirable schedulers*. (See, for example, some of Jon Bennett's > mailings from near the time of efresolve's release.) By "perfectly > fine," I mean schedulers that introduce little or no jitter or delay, > and by "less desirable," I mean schedulers that introduce more > jitter. Jon's examples and other similar difficulties with S are by no > means exotic or unusual examples. If a more "desirable scheduler" creates values of S that are orders of magnitude greater than "less desirable schedulers," then there can only be two possible situations that come to (my) mind: 1. The more desirable schedulers introduce a lot more delay variation than lesser schedulers, or 2. The more desirable schedulers introduce a lot more deterministic delay then lesser schedulers. Perhaps we should all first agree as to what EF is for. In my view, both 1 and 2 are bad for EF, so the "lesser schedulers" are perhaps more appropriate. Maybe "more desirable schedulers" needs to be defined better. Or perhaps we need two variants of EF -- one that minimizes jitter at the expense of latency, the other than minimizes latency. > I, too, am mystified as to why there is still an issue. > I would have thought that efresolve would have been > discarded as an irredeemably failed attempt long ago. Bert _______________________________________________ diffserv mailing list diffserv@ietf.org http://www1.ietf.org/mailman/listinfo/diffserv Archive: http://www2.ietf.org/mail-archive/working-groups/diffserv/current/maillist.html From diffserv-admin@ietf.org Mon Dec 11 11:40:23 2000 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with SMTP id LAA20062 for ; Mon, 11 Dec 2000 11:40:23 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id LAA08106; Mon, 11 Dec 2000 11:09:42 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id LAA08080 for ; Mon, 11 Dec 2000 11:09:38 -0500 (EST) Received: from mailhub1.almaden.ibm.com (mailhub1.almaden.ibm.com [198.4.83.44]) by ietf.org (8.9.1a/8.9.1a) with SMTP id LAA12856 for ; Mon, 11 Dec 2000 11:09:32 -0500 (EST) Received: from maui.almaden.ibm.com (maui.almaden.ibm.com [9.1.24.92]) by mailhub1.almaden.ibm.com (8.8.8/8.8.8) with ESMTP id IAA39160 for ; Mon, 11 Dec 2000 08:06:50 -0800 Received: from hursley.ibm.com (gsine05.us.sine.ibm.com [9.14.6.45]) by maui.almaden.ibm.com (AIX4.3/8.9.3/8.7) with ESMTP id IAA35772 for ; Mon, 11 Dec 2000 08:09:02 -0800 Message-ID: <3A34FBE6.5A3F0A60@hursley.ibm.com> Date: Mon, 11 Dec 2000 10:08:06 -0600 From: Brian E Carpenter Organization: IBM X-Mailer: Mozilla 4.61 [en] (Win98; I) X-Accept-Language: en,fr MIME-Version: 1.0 To: diffserv@ietf.org Subject: Re: [Diffserv] Possible compromise between EFRESOLVE and draft-charny References: <98388C05D464D111B61800805F15041601418A52@p-ibis.issy.cnet.fr> 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 ROBERTS James FTRD/DAC/ISS wrote: ... > If, to simplify, we assume there is only EF traffic in the network and the > routers provide perfect FIFO output queuing, is it then possible to come up > with the "network calculus" necessary to quantify how burstiness evolves > from node to node and how it impacts the necessary bound S? Current research > (the previously cited paper by Charny and Le Boudec and references therein) > would suggest this is extremely difficult or even impossible. We are not attempting to solve research problems, and we all hopefully agree that this "network calculus" is a research problem. Our job is very limited: specify a well-defined behaviour with some measureable properties. Requiring that we understand all the implications of a non-existent network calculus for compositions of this behaviour is by definition impossible. So we are going to re-specify EF without attempting the impossible. We're engineers. Brian Carpenter diffserv co-chair _______________________________________________ diffserv mailing list diffserv@ietf.org http://www1.ietf.org/mailman/listinfo/diffserv Archive: http://www2.ietf.org/mail-archive/working-groups/diffserv/current/maillist.html From diffserv-admin@ietf.org Mon Dec 11 11:40: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 SMTP id LAA20097 for ; Mon, 11 Dec 2000 11:40:26 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id LAA08326; Mon, 11 Dec 2000 11:13:06 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id LAA08303 for ; Mon, 11 Dec 2000 11:13:02 -0500 (EST) Received: from hoemail2.firewall.lucent.com (hoemail2.lucent.com [192.11.226.163]) by ietf.org (8.9.1a/8.9.1a) with SMTP id LAA13636 for ; Mon, 11 Dec 2000 11:13:00 -0500 (EST) Received: from hoemail2.firewall.lucent.com (localhost [127.0.0.1]) by hoemail2.firewall.lucent.com (Pro-8.9.3/8.9.3) with ESMTP id LAA09864 for ; Mon, 11 Dec 2000 11:13:01 -0500 (EST) Received: from uk0006exch001h.wins.lucent.com (h135-86-160-150.lucent.com [135.86.160.150]) by hoemail2.firewall.lucent.com (Pro-8.9.3/8.9.3) with ESMTP id LAA09813 for ; Mon, 11 Dec 2000 11:13:01 -0500 (EST) Received: by uk0006exch001h.uk.lucent.com with Internet Mail Service (5.5.2650.21) id ; Mon, 11 Dec 2000 16:12:59 -0000 Message-ID: <976F7C55E3B2D111A0720008C728549C04877620@en0060exch001u.uk.lucent.com> From: "Casati, Alessio (Alessio)" To: "'Bruce Davie'" , "'Anna Charny'" Cc: diffserv@ietf.org Subject: RE: [Diffserv] Possible compromise between EFRESOLVE and draft-ch arny Date: Mon, 11 Dec 2000 16:11:42 -0000 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: text/plain; charset="iso-8859-1" Sender: diffserv-admin@ietf.org Errors-To: diffserv-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Diffserv Discussion List X-BeenThere: diffserv@ietf.org Anna, > Can you summarize your objections to having the behavior specified > for any operating region as a function of the parameters of this operating > > region? > no such objection has been raised. In fact, a manufacturer can do so. EFRESOLVE does not constrain this (and if you find verbage preventing this, it would be good so that we can have a better quality standard). But "any" needs to be better qualified: "any operating region the manufacturer is certifying the Box for" would be a better wording. > Also, you say that a number of actions you specify above "would be > fine". Could you please explain why you are not concerned about the > possibility that undefined behavior at some node (even it network > management is notified, but the packets are not dropped), may result in > cascaded undefined behavior downstream? > It happens in real world that now and then some glitches show up. The management subsystem detects them and corrective actions are (or may be) taken. The goal would be minimizing such glitches. The action taken in response to glitches may be optimized as a function of the service (and may be global, or local). > > > - non-FIFO treatment of EF will typically lead to a large value of S > > > > >It appears this concern was addressed on the list and > >multiple voices supported that this point was not valid. > >As such we don't need to discuss about this further. > > Do you mean to say that it is not true that devices with non-FIFO > treatment > will have large S, or that it is not important that they have large S? > > I would also like to point out that there were also multiple voices on > the > list that supported the opinion that this point was valid, so I suggest > that we need to address this question > with a more technical discussion. > Anna, the goal of the PHB is to bound delay variation to the S*MTU/R value. Clearly, if the bound we are talking about needs to be the same for FIFO or non FIFO, S*MTU/R needs to be the same. A greater S implies you are considering a smaller R. So, people on the list acutely observed that the comparison was between apples and oranges (or Apples and EF). > > > - S is not a good figure of merit, since non-ideal scheduling and > non-FIFO > > > service are lumped in the same parameter; also very good devices with > > > large > > > number of ports will look worse than small devices with bad scheduling > > > implementations > > > > >The list suggested that if a box provides smart features that > >handle the EF aggregate at flows level, then why not to boast it > >in your brochures an claim EF++ capabilities? > >Our definition is not intended to cover particular marketing needs. > > I am not sure how your statement about smart features addresses the fact > that S, which is advertised as a figure of merit, does not appear to be > one? > I also don't understand the way our definition would be subverting the commonsense of a router buyer... I have no additional comments. > Also, can you please summarize objections to actually having a figure of > merit as part of definition? > S*MTU/R is the promised bound on delay variation. It is possible to compared S values if the values of burstiness, Rate and MTU. Otherwise it does not make sense (apples and oranges). I would also support that it is difficult to obtain a "figure of merit" based on which to rank routers. So, I would be cautious in going down this path. > I would also like to repeat my suggestion that in the case where opposing > opinions have been given on the list, we refrain from using the mere fact > of the existence of people supporting a given opinion as a proof that this > > opinion is correct. > "presidentials elections" syndrome going on here :)... > > > - it is not yet clear how to generalize the defintion to the multiple > > > input, > > > multiple output case > > > > >The team considered the definition to apply to > >an (input,output) pair. Any EF or non EF traffic > >towards the same output interface would be considered as > >competing traffic, in order to deliver the desired behaviour. > > We understand that. We are concerned, however, that the decision of the > team to use the input rate only makes it difficult to generalize the > definition to a device with a range of interface speeds in a way > meaningful > in the diffserv environment. While it is possible that we misunderstand > how > you plan to address this issue, we have not been able to get any > clarification of this (and in fact at least two members of your team have > acknowledged that such generalization is not obvious). > this is the text (by the way, nothing is obvious in EF, and I would be scared of a definition that would look so): In the absence of additional information, R is assumed to be limited by the slowest interface on the device. In addition, an EF device may be characterized by different values of R for different traffic flow scenarios (for example, for traffic aimed at different ports, total incoming R, and possibly total per output port incoming R across all incoming interfaces). So, if there are additional informations we don't imply R to be the same for all Input output pairs. > It may help if you can give the answer to the following questions. > Can you please let us know what is the maximum input rate R that a device > can support in the case of multiple speeds of interfaces, when the device > > is just characterized by a single value of R (your draft says that this > is > the speed of the slowest interface - do you believe it is correct?). > Our draft is much more detailed than this. Please text above for a better understanding. > Can > you also describe how to specify the rate constraints in this case when > you > want to describe the device by multiple constraints of R, as your draft > suggests should be possible? I hope your answers might help clarify these > > issues. > I think I need help to understand this question (I may misinterpret it, and I would not like to appear to have given the wrong answer) > > > - it allows arbitrarily large fixed delay (which isn't visible in a > figure > > > of merit) > > > > >Indeed, the current definition allows for it. > >Fixed delay is not a concern since it is a parameter > >evaluated by the market independent from EF > >definition. We don't want to act on this. > > This indeed can be easily fixed by simply specifying what the fixed delay > is. > It is not the EF PHB role to define this. > >Summarizing, we have carefully considered the > >criticisms, and evaluated > >the answers above would address them. > > I look forward to getting your answers to my questions above. > > I hope I've been sufficiently helpful. alessio _______________________________________________ diffserv mailing list diffserv@ietf.org http://www1.ietf.org/mailman/listinfo/diffserv Archive: http://www2.ietf.org/mail-archive/working-groups/diffserv/current/maillist.html From diffserv-admin@ietf.org Mon Dec 11 11:40:44 2000 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with SMTP id LAA20234 for ; Mon, 11 Dec 2000 11:40:44 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id LAA08246; Mon, 11 Dec 2000 11:12:14 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id LAA08219 for ; Mon, 11 Dec 2000 11:12:09 -0500 (EST) Received: from mailhub1.almaden.ibm.com (mailhub1.almaden.ibm.com [198.4.83.44]) by ietf.org (8.9.1a/8.9.1a) with SMTP id LAA13438 for ; Mon, 11 Dec 2000 11:12:07 -0500 (EST) Received: from maui.almaden.ibm.com (maui.almaden.ibm.com [9.1.24.92]) by mailhub1.almaden.ibm.com (8.8.8/8.8.8) with ESMTP id IAA27948 for ; Mon, 11 Dec 2000 08:09:26 -0800 Received: from hursley.ibm.com (gsine05.us.sine.ibm.com [9.14.6.45]) by maui.almaden.ibm.com (AIX4.3/8.9.3/8.7) with ESMTP id IAA22520 for ; Mon, 11 Dec 2000 08:11:38 -0800 Message-ID: <3A34FC81.C80F5163@hursley.ibm.com> Date: Mon, 11 Dec 2000 10:10:41 -0600 From: Brian E Carpenter Organization: IBM X-Mailer: Mozilla 4.61 [en] (Win98; I) X-Accept-Language: en,fr MIME-Version: 1.0 To: diffserv@ietf.org Subject: Re: [Diffserv] Possible compromise between EFRESOLVE and draft-ch arny References: <4102273CEB77D211869200805FE6F593018C5BDD@xch-phl-01.he.boeing.com> <001101c06381$a7e975c0$2ed4e00a@dsl.vz.genuity.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 We decided a couple of weeks ago that a) the EFRESOLVE S should be renamed Scale instead of Score b) it is not a figure of merit but merely a bound that must exist as a finite value So I suggest we stop asking the same question repeatedly. Brian Carpenter diffserv co-chair Bill Courtney wrote: > > Hi Bert, > > You wrote: > > > I'm afraid I don't understand the controversy regarding S. > > > > EFRESOLVE states that EF is defined as an aggregate flow for which the > > difference between minimum possible delay and the maximum possible delay > is > > bounded by some number S X MTU transfer time when the arrival rate of this > > incoming EF aggregate flow is specified as R. > > > > The underlying idea of EF, whether we can state this or no, has always > been > > (has it not?) to support a service similar to CBR, or approaching CBR, for > > an aggregate flow. So S will determine how CBR-like this EF flow will be. > > > > The controversy is based on the fact, as two or three earlier posts > have established, that *perfectly fine schedulers* can have values of S > that are orders of magnitude greater than the values for *less > desirable schedulers*. (See, for example, some of Jon Bennett's > mailings from near the time of efresolve's release.) By "perfectly > fine," I mean schedulers that introduce little or no jitter or delay, > and by "less desirable," I mean schedulers that introduce more > jitter. Jon's examples and other similar difficulties with S are by no > means exotic or unusual examples. > > So, S does not provide a useful measure of the worth of a > scheduler (i.e., large values might mean anything), and a > value of S can be found for almost every scheduler. Thus, > efresolve offers us a definition that admits virtually > everything and fails to make any useful distinction among > the things it admits. > > > If some non-FIFO schedulers will result in large values of S, seems to me > > that those schedulers are simply not ideal for EF use. Why is this an > issue? > > The large values of S may have nothing to do with the > usefulness of those schedulers for EF, or they may. > It depends on the scheduler. Thus, S is a very poor > discriminator. > > I, too, am mystified as to why there is still an issue. > I would have thought that efresolve would have been > discarded as an irredeemably failed attempt long ago. > > Cheers, > Bill > > _______________________________________________ > diffserv mailing list > diffserv@ietf.org > http://www1.ietf.org/mailman/listinfo/diffserv > Archive: http://www2.ietf.org/mail-archive/working-groups/diffserv/current/maillist.html _______________________________________________ diffserv mailing list diffserv@ietf.org http://www1.ietf.org/mailman/listinfo/diffserv Archive: http://www2.ietf.org/mail-archive/working-groups/diffserv/current/maillist.html From diffserv-admin@ietf.org Mon Dec 11 11:44:40 2000 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with SMTP id LAA21886 for ; Mon, 11 Dec 2000 11:44:40 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id LAA08442; Mon, 11 Dec 2000 11:17:26 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id LAA08412 for ; Mon, 11 Dec 2000 11:17:22 -0500 (EST) Received: from mailhub1.almaden.ibm.com (mailhub1.almaden.ibm.com [198.4.83.44]) by ietf.org (8.9.1a/8.9.1a) with SMTP id LAA14520 for ; Mon, 11 Dec 2000 11:17:20 -0500 (EST) Received: from maui.almaden.ibm.com (maui.almaden.ibm.com [9.1.24.92]) by mailhub1.almaden.ibm.com (8.8.8/8.8.8) with ESMTP id IAA19882; Mon, 11 Dec 2000 08:14:38 -0800 Received: from hursley.ibm.com (gsine05.us.sine.ibm.com [9.14.6.45]) by maui.almaden.ibm.com (AIX4.3/8.9.3/8.7) with ESMTP id IAA32426; Mon, 11 Dec 2000 08:16:50 -0800 Message-ID: <3A34FDB8.2F29DB32@hursley.ibm.com> Date: Mon, 11 Dec 2000 10:15:52 -0600 From: Brian E Carpenter Organization: IBM X-Mailer: Mozilla 4.61 [en] (Win98; I) X-Accept-Language: en,fr MIME-Version: 1.0 To: demir CC: diffserv@ietf.org Subject: Re: [Diffserv] need for clear definition of "assurance" in EF References: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: diffserv-admin@ietf.org Errors-To: diffserv-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Diffserv Discussion List X-BeenThere: diffserv@ietf.org Content-Transfer-Encoding: 7bit I'm not sure whether you're referring to RFC 2598 or one of the recent drafts, but you are correct: it's very confusing to use the same word as the A in AF. I don't think we have anything like consensus for changing from a rate-based EF definition yet - hopefully we will clarify this by the end of Tuesday's meeting. Brian demir wrote: > > In Introduction of EF PHB, the "assured bandwidth" phrase is used. I think > this is misleading and "inaccurate". In AF, assurance is "different levels > of forwarding assurances for IP packets received from a customer DS > domain". Where as, to me, in EF, "assured bandwidth" has different meaning > ("available"?) (you might say that "assured" bandwidth makes it > assured bandwidth. However "assured" forwarding in AF doesn't make it > assured forwarding (assuming "underprovisioned" and/or "traffic > conditioning" failure). > I agree they are just "words". It would be nicer to make words clear to > understand. > I have already made my point on providing "assurance" level for EF if one > choses to use it (fundamental change :) However, it seems it's okay to > change EF's constraint from "rate" to "delay", "delay variance". What is > the limit of "expedited"? "no delay", "no delay variance" :) for a packet? > "philosophical" change is fine, but "fundamental" is not fine? > > my 2 cents, > > Alper K. Demir > > _______________________________________________ > diffserv mailing list > diffserv@ietf.org > http://www1.ietf.org/mailman/listinfo/diffserv > Archive: http://www2.ietf.org/mail-archive/working-groups/diffserv/current/maillist.html _______________________________________________ diffserv mailing list diffserv@ietf.org http://www1.ietf.org/mailman/listinfo/diffserv Archive: http://www2.ietf.org/mail-archive/working-groups/diffserv/current/maillist.html From diffserv-admin@ietf.org Mon Dec 11 11:55: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 SMTP id LAA24630 for ; Mon, 11 Dec 2000 11:55:38 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id LAA08875; Mon, 11 Dec 2000 11:31:16 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id LAA08845 for ; Mon, 11 Dec 2000 11:31:11 -0500 (EST) Received: from mailhub1.almaden.ibm.com (mailhub1.almaden.ibm.com [198.4.83.44]) by ietf.org (8.9.1a/8.9.1a) with SMTP id LAA17560 for ; Mon, 11 Dec 2000 11:31:09 -0500 (EST) Received: from maui.almaden.ibm.com (maui.almaden.ibm.com [9.1.24.92]) by mailhub1.almaden.ibm.com (8.8.8/8.8.8) with ESMTP id IAA57098; Mon, 11 Dec 2000 08:28:27 -0800 Received: from hursley.ibm.com (gsine05.us.sine.ibm.com [9.14.6.45]) by maui.almaden.ibm.com (AIX4.3/8.9.3/8.7) with ESMTP id IAA35786; Mon, 11 Dec 2000 08:30:39 -0800 Message-ID: <3A3500EE.570D47FF@hursley.ibm.com> Date: Mon, 11 Dec 2000 10:29:34 -0600 From: Brian E Carpenter Organization: IBM X-Mailer: Mozilla 4.61 [en] (Win98; I) X-Accept-Language: en,fr MIME-Version: 1.0 To: demir CC: "Manfredi, Albert E" , diffserv@ietf.org Subject: Re: [Diffserv] need for clear definition of "assurance" in EF 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 Hi, This discussion is getting off target, in fact it seems more like one for the diffserv-interest list. Brian demir wrote: > > > Perhaps I'm reading more into this than I should, but I believe that the > > practical difference between EF and AF is that EF is intended as a means of > > making the Link Layer provide CBR-like services, e.g. for UDP flows, whereas > > AF is meant to use TCP feedback mechanisms to provide a continuum of > > "assurances," from best effort to something that could be essentially the > > same as EF. > > That is an "interesting" intention. It seems both AF and EF PHB have > already picked their "transport" protocol. What if I use "TCP-friendly > rate adaptive" protocol based on UDP and want to get a service based on AF > PHB or I use TCP and ask for a service based on EF PHB (I have no idea > why? for reliability?)? I have mentioned that it is not a good idea to > "embed" services into PHBs. The respose was that EF is intended for > "expedition". I don't have any problem with accepting that (still > believing that this should also be avoided if there is a network-dependent > parameter cause a PDB can achieve this goal anytime, everywhere). Now, > there is another property of EF assumes "CBR-traffic" meaning what kind of > traffic EF is expecting? There are alot of "mistery" behind EF PHB. > > Alper K. Demir > > _______________________________________________ > diffserv mailing list > diffserv@ietf.org > http://www1.ietf.org/mailman/listinfo/diffserv > Archive: http://www2.ietf.org/mail-archive/working-groups/diffserv/current/maillist.html _______________________________________________ diffserv mailing list diffserv@ietf.org http://www1.ietf.org/mailman/listinfo/diffserv Archive: http://www2.ietf.org/mail-archive/working-groups/diffserv/current/maillist.html From diffserv-admin@ietf.org Mon Dec 11 12:15: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 SMTP id LAA20011 for ; Mon, 11 Dec 2000 11:40:19 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id KAA07728; Mon, 11 Dec 2000 10:57:51 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id KAA07696 for ; Mon, 11 Dec 2000 10:57:47 -0500 (EST) Received: from usc.edu (root@usc.edu [128.125.253.136]) by ietf.org (8.9.1a/8.9.1a) with SMTP id KAA10954 for ; Mon, 11 Dec 2000 10:57:40 -0500 (EST) Received: from aludra.usc.edu (demir@aludra.usc.edu [128.125.253.184]) by usc.edu (8.9.3.1/8.9.3/usc) with ESMTP id HAA28537; Mon, 11 Dec 2000 07:57:42 -0800 (PST) Received: from localhost (demir@localhost) by aludra.usc.edu (8.9.3.1/8.9.3/usc) with ESMTP id HAA10907; Mon, 11 Dec 2000 07:57:41 -0800 (PST) Date: Mon, 11 Dec 2000 07:57:41 -0800 (PST) From: demir To: "Manfredi, Albert E" cc: diffserv@ietf.org Subject: RE: [Diffserv] need for clear definition of "assurance" in EF In-Reply-To: <4102273CEB77D211869200805FE6F593018C5BDF@xch-phl-01.he.boeing.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: diffserv-admin@ietf.org Errors-To: diffserv-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Diffserv Discussion List X-BeenThere: diffserv@ietf.org > Perhaps I'm reading more into this than I should, but I believe that the > practical difference between EF and AF is that EF is intended as a means of > making the Link Layer provide CBR-like services, e.g. for UDP flows, whereas > AF is meant to use TCP feedback mechanisms to provide a continuum of > "assurances," from best effort to something that could be essentially the > same as EF. That is an "interesting" intention. It seems both AF and EF PHB have already picked their "transport" protocol. What if I use "TCP-friendly rate adaptive" protocol based on UDP and want to get a service based on AF PHB or I use TCP and ask for a service based on EF PHB (I have no idea why? for reliability?)? I have mentioned that it is not a good idea to "embed" services into PHBs. The respose was that EF is intended for "expedition". I don't have any problem with accepting that (still believing that this should also be avoided if there is a network-dependent parameter cause a PDB can achieve this goal anytime, everywhere). Now, there is another property of EF assumes "CBR-traffic" meaning what kind of traffic EF is expecting? There are alot of "mistery" behind EF PHB. Alper K. Demir _______________________________________________ diffserv mailing list diffserv@ietf.org http://www1.ietf.org/mailman/listinfo/diffserv Archive: http://www2.ietf.org/mail-archive/working-groups/diffserv/current/maillist.html From diffserv-admin@ietf.org Mon Dec 11 12:23:57 2000 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with SMTP id MAA03225 for ; Mon, 11 Dec 2000 12:23:57 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id LAA09691; Mon, 11 Dec 2000 11:55:55 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id LAA09578 for ; Mon, 11 Dec 2000 11:55:46 -0500 (EST) Received: from usc.edu (root@usc.edu [128.125.253.136]) by ietf.org (8.9.1a/8.9.1a) with SMTP id LAA24672 for ; Mon, 11 Dec 2000 11:55:44 -0500 (EST) Received: from aludra.usc.edu (demir@aludra.usc.edu [128.125.253.184]) by usc.edu (8.9.3.1/8.9.3/usc) with ESMTP id IAA06124; Mon, 11 Dec 2000 08:55:46 -0800 (PST) Received: from localhost (demir@localhost) by aludra.usc.edu (8.9.3.1/8.9.3/usc) with ESMTP id IAA02122; Mon, 11 Dec 2000 08:55:45 -0800 (PST) Date: Mon, 11 Dec 2000 08:55:45 -0800 (PST) From: demir To: Brian E Carpenter cc: diffserv@ietf.org Subject: Re: [Diffserv] need for clear definition of "assurance" in EF In-Reply-To: <3A34FDB8.2F29DB32@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 Yes. I am refering to RFC 2598. I don't think that "rate-based EF definition" (actually, "assurance" level for EF" with a "MAY" statement) would "hurt" EF PHB. Alper K. Demir On Mon, 11 Dec 2000, Brian E Carpenter wrote: > I'm not sure whether you're referring to RFC 2598 or one of the recent > drafts, but you are correct: it's very confusing to use the same word > as the A in AF. > > I don't think we have anything like consensus for changing from > a rate-based EF definition yet - hopefully we will clarify this by the > end of Tuesday's meeting. > > Brian > > demir wrote: > > > > In Introduction of EF PHB, the "assured bandwidth" phrase is used. I think > > this is misleading and "inaccurate". In AF, assurance is "different levels > > of forwarding assurances for IP packets received from a customer DS > > domain". Where as, to me, in EF, "assured bandwidth" has different meaning > > ("available"?) (you might say that "assured" bandwidth makes it > > assured bandwidth. However "assured" forwarding in AF doesn't make it > > assured forwarding (assuming "underprovisioned" and/or "traffic > > conditioning" failure). > > I agree they are just "words". It would be nicer to make words clear to > > understand. > > I have already made my point on providing "assurance" level for EF if one > > choses to use it (fundamental change :) However, it seems it's okay to > > change EF's constraint from "rate" to "delay", "delay variance". What is > > the limit of "expedited"? "no delay", "no delay variance" :) for a packet? > > "philosophical" change is fine, but "fundamental" is not fine? > > > > my 2 cents, > > > > Alper K. Demir > > > > _______________________________________________ > > diffserv mailing list > > diffserv@ietf.org > > http://www1.ietf.org/mailman/listinfo/diffserv > > Archive: http://www2.ietf.org/mail-archive/working-groups/diffserv/current/maillist.html > _______________________________________________ diffserv mailing list diffserv@ietf.org http://www1.ietf.org/mailman/listinfo/diffserv Archive: http://www2.ietf.org/mail-archive/working-groups/diffserv/current/maillist.html From diffserv-admin@ietf.org Mon Dec 11 12:36: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 SMTP id MAA06585 for ; Mon, 11 Dec 2000 12:36:36 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id MAA10118; Mon, 11 Dec 2000 12:08:20 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id MAA10086 for ; Mon, 11 Dec 2000 12:08:16 -0500 (EST) Received: from p-mail2.cnet.fr (p-mail2.rd.francetelecom.fr [193.49.124.32]) by ietf.org (8.9.1a/8.9.1a) with SMTP id MAA27914 for ; Mon, 11 Dec 2000 12:08:13 -0500 (EST) Received: by p-voyageur.issy.cnet.fr with Internet Mail Service (5.5.2650.21) id ; Mon, 11 Dec 2000 18:07:35 +0100 Message-ID: <91A311FF6A85D3118DDF0060080C3D82B7DAA9@lat3721.lannion.cnet.fr> From: GARBISU Jean-Pierre FTRD/DMI/CAE To: diffserv@ietf.org Subject: RE: [Diffserv] Possible compromise between EFRESOLVE and draft-ch arny Date: Mon, 11 Dec 2000 18:05:44 +0100 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: text/plain; charset="iso-8859-1" Sender: diffserv-admin@ietf.org Errors-To: diffserv-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Diffserv Discussion List X-BeenThere: diffserv@ietf.org so many flames that one can doubt about reaching an agreement satisfying both camps you can't have two presidents ;-) but perhaps two EF "like" PHB... are there some supreme wise (wo)men participating to diffserv tomorrow :-) cheers jeanpierre.garbisu@francetelecom.fr _______________________________________________ diffserv mailing list diffserv@ietf.org http://www1.ietf.org/mailman/listinfo/diffserv Archive: http://www2.ietf.org/mail-archive/working-groups/diffserv/current/maillist.html From diffserv-admin@ietf.org Mon Dec 11 12:59:12 2000 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with SMTP id MAA11603 for ; Mon, 11 Dec 2000 12:59:12 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id MAA10446; Mon, 11 Dec 2000 12:22:59 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id MAA10421 for ; Mon, 11 Dec 2000 12:22:55 -0500 (EST) Received: from usc.edu (root@usc.edu [128.125.253.136]) by ietf.org (8.9.1a/8.9.1a) with SMTP id MAA02882 for ; Mon, 11 Dec 2000 12:22:52 -0500 (EST) Received: from aludra.usc.edu (demir@aludra.usc.edu [128.125.253.184]) by usc.edu (8.9.3.1/8.9.3/usc) with ESMTP id JAA26589; Mon, 11 Dec 2000 09:22:50 -0800 (PST) Received: from localhost (demir@localhost) by aludra.usc.edu (8.9.3.1/8.9.3/usc) with ESMTP id JAA15363; Mon, 11 Dec 2000 09:22:50 -0800 (PST) Date: Mon, 11 Dec 2000 09:22:49 -0800 (PST) From: demir To: Brian E Carpenter cc: diffserv@ietf.org Subject: Re: [Diffserv] Possible compromise between EFRESOLVE and draft-ch arny In-Reply-To: <3A34FC81.C80F5163@hursley.ibm.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: diffserv-admin@ietf.org Errors-To: diffserv-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Diffserv Discussion List X-BeenThere: diffserv@ietf.org Brian, I think whatever name EFRESOLVE uses for S other than B, it is not for "intended expedite" which is not clear yet. As long as this "finite bound" S remains bounding "delay variance" (D(i) - E(i)), EF PHB will dominate every other PHBs and every diffserv-compatible box. That means without understanding EF, it won't be possible to implemet other PHBs (currently, there is no problem with AF, but there could be others). May be instead of Expedited PHB, "Entry" point PHB for Diffserv :) would be a better choice :) If that is fine with Diffserv, then there is no need to discuss futher. Alper K. Demir On Mon, 11 Dec 2000, Brian E Carpenter wrote: > We decided a couple of weeks ago that > a) the EFRESOLVE S should be renamed Scale instead of Score > b) it is not a figure of merit but merely a bound that must exist as a finite value > > So I suggest we stop asking the same question repeatedly. > > Brian Carpenter > diffserv co-chair > > Bill Courtney wrote: > > > > Hi Bert, > > > > You wrote: > > > > > I'm afraid I don't understand the controversy regarding S. > > > > > > EFRESOLVE states that EF is defined as an aggregate flow for which the > > > difference between minimum possible delay and the maximum possible delay > > is > > > bounded by some number S X MTU transfer time when the arrival rate of this > > > incoming EF aggregate flow is specified as R. > > > > > > The underlying idea of EF, whether we can state this or no, has always > > been > > > (has it not?) to support a service similar to CBR, or approaching CBR, for > > > an aggregate flow. So S will determine how CBR-like this EF flow will be. > > > > > > > The controversy is based on the fact, as two or three earlier posts > > have established, that *perfectly fine schedulers* can have values of S > > that are orders of magnitude greater than the values for *less > > desirable schedulers*. (See, for example, some of Jon Bennett's > > mailings from near the time of efresolve's release.) By "perfectly > > fine," I mean schedulers that introduce little or no jitter or delay, > > and by "less desirable," I mean schedulers that introduce more > > jitter. Jon's examples and other similar difficulties with S are by no > > means exotic or unusual examples. > > > > So, S does not provide a useful measure of the worth of a > > scheduler (i.e., large values might mean anything), and a > > value of S can be found for almost every scheduler. Thus, > > efresolve offers us a definition that admits virtually > > everything and fails to make any useful distinction among > > the things it admits. > > > > > If some non-FIFO schedulers will result in large values of S, seems to me > > > that those schedulers are simply not ideal for EF use. Why is this an > > issue? > > > > The large values of S may have nothing to do with the > > usefulness of those schedulers for EF, or they may. > > It depends on the scheduler. Thus, S is a very poor > > discriminator. > > > > I, too, am mystified as to why there is still an issue. > > I would have thought that efresolve would have been > > discarded as an irredeemably failed attempt long ago. > > > > Cheers, > > Bill > > > > _______________________________________________ > > diffserv mailing list > > diffserv@ietf.org > > http://www1.ietf.org/mailman/listinfo/diffserv > > Archive: http://www2.ietf.org/mail-archive/working-groups/diffserv/current/maillist.html > > _______________________________________________ > diffserv mailing list > diffserv@ietf.org > http://www1.ietf.org/mailman/listinfo/diffserv > Archive: http://www2.ietf.org/mail-archive/working-groups/diffserv/current/maillist.html > _______________________________________________ diffserv mailing list diffserv@ietf.org http://www1.ietf.org/mailman/listinfo/diffserv Archive: http://www2.ietf.org/mail-archive/working-groups/diffserv/current/maillist.html From diffserv-admin@ietf.org Mon Dec 11 13:13:40 2000 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with SMTP id NAA14679 for ; Mon, 11 Dec 2000 13:13:35 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id MAA10954; Mon, 11 Dec 2000 12:44:01 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id MAA10924 for ; Mon, 11 Dec 2000 12:43:57 -0500 (EST) Received: from babar.switch.ch (babar.switch.ch [130.59.4.2]) by ietf.org (8.9.1a/8.9.1a) with SMTP id MAA08284 for ; Mon, 11 Dec 2000 12:43:56 -0500 (EST) Received: (from leinen@localhost) by babar.switch.ch (8.9.3+Sun/8.9.3) id SAA15521; Mon, 11 Dec 2000 18:43:18 +0100 (MET) X-Authentication-Warning: babar.switch.ch: leinen set sender to simon@limmat.switch.ch using -f To: Andrew Smith Cc: diffserv References: <3A349D52.1080108@allegronetworks.com> X-Face: 1Nk*r=:$IBBb8|TyRB'2WSY6u:BzMO7N)#id#-4_}MsU5?vTI?dez|JiutW4sKBLjp.l7,F 7QOld^hORRtpCUj)!cP]gtK_SyK5FW(+o"!or:v^C^]OxX^3+IPd\z,@ttmwYVO7l`6OXXYR` From: Simon Leinen In-Reply-To: <3A349D52.1080108@allegronetworks.com> Date: 11 Dec 2000 18:43:17 +0100 Message-ID: Lines: 45 User-Agent: Gnus/5.09 (Gnus v5.9.0) Emacs/21.0.92 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Subject: [Diffserv] diffServRandomDropInvProbMax [was: MIB - technical comments (part 1)] Sender: diffserv-admin@ietf.org Errors-To: diffserv-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Diffserv Discussion List X-BeenThere: diffserv@ietf.org Andrew, I don't think you are confused... somehow the old (inverse propability) representation snuck back in in the -05 revision. In mib-04 we had: diffServRandomDropProbMax OBJECT-TYPE SYNTAX Unsigned32 MAX-ACCESS read-create STATUS current DESCRIPTION "The worst case random drop probability, expressed in drops per thousand packets. For example, if every packet may be dropped in the worst case (100%), this has the value 1000. Alternatively, if in the worst case one percent (1%) of traffic may be dropped, it has the value 10." ::= { diffServRandomDropEntry 6 } This was shorter, less confusing, and reflected what I interpret as WG consensus. So I suggest reverting to that version. -- Simon. >>>>> "as" == Andrew Smith writes: > 35. diffServRandomDropInvProbMax: > Again, did I miss some discussion where the WG decided to use an > "inverse probability" rather than a percent*100 for Pmax (as it was in > -04)? It's possible I'm not interpreting the DESCRIPTION correctly: > "The worst case random drop probability, expressed as > the inverse of the drop probability. With special > case of the value zero meaning zero probability of > drop. > For example, if every packet may be dropped in the > worst case (100%), this has the value of > 4,294,967,295." > As it is now I think I can represent Pmax of 1, 0.5, 0.25, 0.125 > etc. with MIB values of 1, 2, 3, 4 respectively, but no intermediate > values (but then why does 4294967295 represent 100% - why not 1? SO I > am obivously confused). But we've been through this many times before > and I thought we had consensus on using percent*100. I guess I must > have blinked. _______________________________________________ diffserv mailing list diffserv@ietf.org http://www1.ietf.org/mailman/listinfo/diffserv Archive: http://www2.ietf.org/mail-archive/working-groups/diffserv/current/maillist.html From diffserv-admin@ietf.org Mon Dec 11 13:22:06 2000 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with SMTP id NAA16406 for ; Mon, 11 Dec 2000 13:22:06 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id MAA11166; Mon, 11 Dec 2000 12:52:47 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id MAA11135 for ; Mon, 11 Dec 2000 12:52:43 -0500 (EST) Received: from p-mail2.cnet.fr (p-mail2.rd.francetelecom.fr [193.49.124.32]) by ietf.org (8.9.1a/8.9.1a) with SMTP id MAA10219 for ; Mon, 11 Dec 2000 12:52:42 -0500 (EST) Received: by p-voyageur.issy.cnet.fr with Internet Mail Service (5.5.2650.21) id ; Mon, 11 Dec 2000 18:51:51 +0100 Message-ID: <98388C05D464D111B61800805F15041601418A5B@p-ibis.issy.cnet.fr> From: ROBERTS James FTRD/DAC/ISS To: "'Brian E Carpenter'" , diffserv@ietf.org Subject: RE: [Diffserv] Possible compromise between EFRESOLVE and draft-ch arny Date: Mon, 11 Dec 2000 18:51:50 +0100 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: text/plain; charset="iso-8859-1" Sender: diffserv-admin@ietf.org Errors-To: diffserv-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Diffserv Discussion List X-BeenThere: diffserv@ietf.org > ROBERTS James FTRD/DAC/ISS wrote: > ... > > If, to simplify, we assume there is only EF traffic in the > network and the > > routers provide perfect FIFO output queuing, is it then > possible to come up > > with the "network calculus" necessary to quantify how > burstiness evolves > > from node to node and how it impacts the necessary bound S? > Current research > > (the previously cited paper by Charny and Le Boudec and > references therein) > > would suggest this is extremely difficult or even impossible. > > We are not attempting to solve research problems, and we all hopefully > agree that this "network calculus" is a research problem. Our job is > very limited: specify a well-defined behaviour with some measureable > properties. Requiring that we understand all the implications of a > non-existent network calculus for compositions of this behaviour > is by definition impossible. So we are going to re-specify EF without > attempting the impossible. We're engineers. > > Brian Carpenter > diffserv co-chair > > It seemed to me that EFRESOLVE requires network calculus to specify what is meant by tolerable burstiness. For instance, I think it is not sufficient to use a token bucket if you can't predict how bucket parameters evolve as EF flows progress through the network aggregating and splitting in a fairly arbitrary manner. How can you measure this burstiness and if you can't, how can the behaviour be well defined? It seems the modified rate guarantee definition successfully avoids the need to specify or measure burstiness. It defines a behaviour which can be reasonably interpreted in a literal sense as "expedited forwarding", ie, it approximates work conserving FIFO scheduling to within the tolerance defined by the E bounds. It looks to me like a reasonable engineering solution. Jim _______________________________________________ diffserv mailing list diffserv@ietf.org http://www1.ietf.org/mailman/listinfo/diffserv Archive: http://www2.ietf.org/mail-archive/working-groups/diffserv/current/maillist.html From diffserv-admin@ietf.org Mon Dec 11 13:46:40 2000 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with SMTP id NAA20714 for ; Mon, 11 Dec 2000 13:46:36 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id NAA11737; Mon, 11 Dec 2000 13:19:21 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id NAA11703 for ; Mon, 11 Dec 2000 13:19:17 -0500 (EST) Received: from longsys.com (dmz.longsys.com [63.111.150.5]) by ietf.org (8.9.1a/8.9.1a) with SMTP id NAA15938 for ; Mon, 11 Dec 2000 13:19:16 -0500 (EST) Received: from joel (discordian.longsys.com [63.111.150.74]) by longsys.com (8.10.0/8.10.0) with ESMTP id eBBIJCr20178; Mon, 11 Dec 2000 18:19:12 GMT Message-Id: <4.2.2.20001211131118.00b49190@localhost> X-Sender: joel@localhost X-Mailer: QUALCOMM Windows Eudora Pro Version 4.2.2 Date: Mon, 11 Dec 2000 13:16:54 -0500 To: "Bill Courtney" From: "Joel M. Halpern" Subject: Re: [Diffserv] Possible compromise between EFRESOLVE and draft-ch arny Cc: In-Reply-To: <001101c06381$a7e975c0$2ed4e00a@dsl.vz.genuity.net> References: <4102273CEB77D211869200805FE6F593018C5BDD@xch-phl-01.he.boeing.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: diffserv-admin@ietf.org Errors-To: diffserv-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Diffserv Discussion List X-BeenThere: diffserv@ietf.org In order to get this result, you have to use "jitter or delay" relative to something different than what we believe the purpose of EF uses it to mean. It is certainly true that if what one cares about is the proportional distortion of substreams of the aggregated EF, one can get highly desireable results that have a large S. There are many contexts (including those where one has chosen to accept very large bursts) where a large S device is perfectly acceptable. However, I have not yet seen any example of a situation where, for the purposes that most of us understand EF to be for, a small S device will be worse than a large S device. That does not mean it will be better, but I have to disagree with Bill's assertion that these smaller S devices are "less desirable" schedulers. They may not be any better for the actual environmental problem. That is why it is hard to decide whether to say that S is a figure of merit or not. But that does not mean that it is not a useful description as this message attempts to suggest. Yours, Joel M. Halpern At 06:50 AM 12/11/00 -0800, Bill Courtney wrote: >The controversy is based on the fact, as two or three earlier posts >have established, that *perfectly fine schedulers* can have values of S >that are orders of magnitude greater than the values for *less >desirable schedulers*. (See, for example, some of Jon Bennett's >mailings from near the time of efresolve's release.) By "perfectly >fine," I mean schedulers that introduce little or no jitter or delay, >and by "less desirable," I mean schedulers that introduce more >jitter. Jon's examples and other similar difficulties with S are by no >means exotic or unusual examples. _______________________________________________ diffserv mailing list diffserv@ietf.org http://www1.ietf.org/mailman/listinfo/diffserv Archive: http://www2.ietf.org/mail-archive/working-groups/diffserv/current/maillist.html From diffserv-admin@ietf.org Mon Dec 11 13:46: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 SMTP id NAA20739 for ; Mon, 11 Dec 2000 13:46:47 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id NAA11469; Mon, 11 Dec 2000 13:04:31 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id NAA11438 for ; Mon, 11 Dec 2000 13:04:27 -0500 (EST) Received: from longsys.com (dmz.longsys.com [63.111.150.5]) by ietf.org (8.9.1a/8.9.1a) with SMTP id NAA12731 for ; Mon, 11 Dec 2000 13:04:26 -0500 (EST) Received: from joel (discordian.longsys.com [63.111.150.74]) by longsys.com (8.10.0/8.10.0) with ESMTP id eBBI4NF19790 for ; Mon, 11 Dec 2000 18:04:23 GMT Message-Id: <4.2.2.20001211124946.00b4e870@localhost> X-Sender: joel@localhost X-Mailer: QUALCOMM Windows Eudora Pro Version 4.2.2 Date: Mon, 11 Dec 2000 13:02:05 -0500 To: diffserv@ietf.org From: "Joel M. Halpern" Subject: RE: [Diffserv] Possible compromise between EFRESOLVE and draft-ch arny In-Reply-To: <98388C05D464D111B61800805F15041601418A52@p-ibis.issy.cnet. fr> 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 If all the traffic is EF, then the full output is dedicated to EF, and things work easily. Given the latest request for an example, here is one. I am sure that people will argue that it is a bad example. So be it. The assumption in this example is a pipe model of EF usage. A number of interfaces supporting EF traffic are directing that EF traffic to a common output. The implementor must specify, for the burst limit that he is willing to support, what the R and S are for each input. For simplicity, all of the inputs will use the same R in this example. The configuration is 500 input interfaces, each allowing 4 megabits / second of EF, and a total burst limit on the output of 32,000 packets. The common output is a 40 gigabit link. The EF scheduler in use alternates EF packets and everything else. Assume for simplicity that the bursts are arriving at all inputs at once (one can easily perform the math for more complex cases, but it does not elucidate any more). Also assume that the input links are 44 megabits, and the bursts arrive at wire rate. The last packet that will be leaving arrives on its interface at time 64 * MTU / (input-wire) It leaves the output interface at time fixed-delay + 32,000 * MTU / (output-wire) The earliest time it could have left is obviously its arrival time plus the fixed delay. Therefore, in units of time the maximum time difference is 32,000 * MTU / (output-wire) - 64 * MTU / (input-wire) To show that S comes out fairly small even in bad cases, I will overstate that S the implementor will calculate by ignoring ths second term. Then, S = 32,0000 * (input-rate) / (output-EF) Plugging back in the 4 megabits / second EF input rate and the 40 gigabits / second output wire rate, and the alternate packet scheduling, we see that S = 6.4 So, can we stop saying that we can not calculate S or that all reasonable schedulers give large S. Yours, Joel M. Halpern _______________________________________________ diffserv mailing list diffserv@ietf.org http://www1.ietf.org/mailman/listinfo/diffserv Archive: http://www2.ietf.org/mail-archive/working-groups/diffserv/current/maillist.html From diffserv-admin@ietf.org Mon Dec 11 14:06:28 2000 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with SMTP id OAA23071 for ; Mon, 11 Dec 2000 14:06:24 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id NAA12193; Mon, 11 Dec 2000 13:38:20 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id NAA12165 for ; Mon, 11 Dec 2000 13:38:16 -0500 (EST) Received: from longsys.com (dmz.longsys.com [63.111.150.5]) by ietf.org (8.9.1a/8.9.1a) with SMTP id NAA19585 for ; Mon, 11 Dec 2000 13:38:15 -0500 (EST) Received: from joel (discordian.longsys.com [63.111.150.74]) by longsys.com (8.10.0/8.10.0) with ESMTP id eBBIbqf20635; Mon, 11 Dec 2000 18:37:52 GMT Message-Id: <4.2.2.20001211133309.00b5a220@localhost> X-Sender: joel@localhost X-Mailer: QUALCOMM Windows Eudora Pro Version 4.2.2 Date: Mon, 11 Dec 2000 13:35:17 -0500 To: demir From: "Joel M. Halpern" Subject: Re: [Diffserv] Possible compromise between EFRESOLVE and draft-ch arny Cc: diffserv@ietf.org In-Reply-To: References: <3A34FC81.C80F5163@hursley.ibm.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: diffserv-admin@ietf.org Errors-To: diffserv-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Diffserv Discussion List X-BeenThere: diffserv@ietf.org I am not sure what you are getting at. Assume we have an EF RFC (new, old, different, ...). Why would this "dominate every other PHBs and every diffserv compatible box". A device is not and will not be required to implement / support EF. That is up to the implementor. It is likely the case that support EF will have an impact on the design of a device if the implementor has chosen to support it. But that does not mean that it dominates or even affects every diffserv-compatible box. No particular PHBs are mandatory to implement. Yours, Joel M. Halpern At 09:22 AM 12/11/00 -0800, demir wrote: >Brian, >I think whatever name EFRESOLVE uses for S other than B, it is not for >"intended expedite" which is not clear yet. As long as this "finite >bound" S remains bounding "delay variance" (D(i) - E(i)), EF PHB will >dominate every other PHBs and every diffserv-compatible box. That means >without understanding EF, it won't be possible to implemet other PHBs >(currently, there is no problem with AF, but there could be others). May >be instead of Expedited PHB, "Entry" point PHB for Diffserv :) would be a >better choice :) If that is fine with Diffserv, then there is no need to >discuss futher. > >Alper K. Demir > > >On Mon, 11 Dec 2000, Brian E Carpenter wrote: > > > We decided a couple of weeks ago that > > a) the EFRESOLVE S should be renamed Scale instead of Score > > b) it is not a figure of merit but merely a bound that must exist as a > finite value > > > > So I suggest we stop asking the same question repeatedly. > > > > Brian Carpenter > > diffserv co-chair > > > > Bill Courtney wrote: > > > > > > Hi Bert, > > > > > > You wrote: > > > > > > > I'm afraid I don't understand the controversy regarding S. > > > > > > > > EFRESOLVE states that EF is defined as an aggregate flow for which the > > > > difference between minimum possible delay and the maximum possible > delay > > > is > > > > bounded by some number S X MTU transfer time when the arrival rate > of this > > > > incoming EF aggregate flow is specified as R. > > > > > > > > The underlying idea of EF, whether we can state this or no, has always > > > been > > > > (has it not?) to support a service similar to CBR, or approaching > CBR, for > > > > an aggregate flow. So S will determine how CBR-like this EF flow > will be. > > > > > > > > > > The controversy is based on the fact, as two or three earlier posts > > > have established, that *perfectly fine schedulers* can have values of S > > > that are orders of magnitude greater than the values for *less > > > desirable schedulers*. (See, for example, some of Jon Bennett's > > > mailings from near the time of efresolve's release.) By "perfectly > > > fine," I mean schedulers that introduce little or no jitter or delay, > > > and by "less desirable," I mean schedulers that introduce more > > > jitter. Jon's examples and other similar difficulties with S are by no > > > means exotic or unusual examples. > > > > > > So, S does not provide a useful measure of the worth of a > > > scheduler (i.e., large values might mean anything), and a > > > value of S can be found for almost every scheduler. Thus, > > > efresolve offers us a definition that admits virtually > > > everything and fails to make any useful distinction among > > > the things it admits. > > > > > > > If some non-FIFO schedulers will result in large values of S, seems > to me > > > > that those schedulers are simply not ideal for EF use. Why is this an > > > issue? > > > > > > The large values of S may have nothing to do with the > > > usefulness of those schedulers for EF, or they may. > > > It depends on the scheduler. Thus, S is a very poor > > > discriminator. > > > > > > I, too, am mystified as to why there is still an issue. > > > I would have thought that efresolve would have been > > > discarded as an irredeemably failed attempt long ago. > > > > > > Cheers, > > > Bill > > > > > > _______________________________________________ > > > diffserv mailing list > > > diffserv@ietf.org > > > http://www1.ietf.org/mailman/listinfo/diffserv > > > Archive: > http://www2.ietf.org/mail-archive/working-groups/diffserv/current/maillist.html > > > > _______________________________________________ > > diffserv mailing list > > diffserv@ietf.org > > http://www1.ietf.org/mailman/listinfo/diffserv > > Archive: > http://www2.ietf.org/mail-archive/working-groups/diffserv/current/maillist.html > > > > >_______________________________________________ >diffserv mailing list >diffserv@ietf.org >http://www1.ietf.org/mailman/listinfo/diffserv >Archive: >http://www2.ietf.org/mail-archive/working-groups/diffserv/current/maillist.html _______________________________________________ diffserv mailing list diffserv@ietf.org http://www1.ietf.org/mailman/listinfo/diffserv Archive: http://www2.ietf.org/mail-archive/working-groups/diffserv/current/maillist.html From diffserv-admin@ietf.org Mon Dec 11 14:09: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 SMTP id OAA23478 for ; Mon, 11 Dec 2000 14:09:32 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id NAA12405; Mon, 11 Dec 2000 13:45:15 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id NAA12375 for ; Mon, 11 Dec 2000 13:45:11 -0500 (EST) Received: from longsys.com (dmz.longsys.com [63.111.150.5]) by ietf.org (8.9.1a/8.9.1a) with SMTP id NAA20504 for ; Mon, 11 Dec 2000 13:45:10 -0500 (EST) Received: from joel (discordian.longsys.com [63.111.150.74]) by longsys.com (8.10.0/8.10.0) with ESMTP id eBBIj1p21001; Mon, 11 Dec 2000 18:45:02 GMT Message-Id: <4.2.2.20001211133852.00b50530@localhost> X-Sender: joel@localhost X-Mailer: QUALCOMM Windows Eudora Pro Version 4.2.2 Date: Mon, 11 Dec 2000 13:42:43 -0500 To: ROBERTS James FTRD/DAC/ISS , diffserv@ietf.org From: "Joel M. Halpern" Subject: RE: [Diffserv] Possible compromise between EFRESOLVE and draft-ch arny In-Reply-To: <98388C05D464D111B61800805F15041601418A5B@p-ibis.issy.cnet. fr> 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 Using EFResolve (or Charny or in fact any other reasonable definition) will require network calculus. Some of that will be in the PDB. Some will be done by the vendor, and some by the customer. But that does not mean that the EF definition requires network calculus. The EF definition has to be defined in terms of a region of applicability, including received burst characteristics. The user then ensures that his usage results in traffic that falls within that characteristic. Yours, Joel M. Halpern PS: To defend my reference to the Charny draft having the same requirement, note that the E_p definition is only applicable within an operating region. That is the same operating region as for EFResolve. At 06:51 PM 12/11/00 +0100, ROBERTS James FTRD/DAC/ISS wrote: > > ROBERTS James FTRD/DAC/ISS wrote: > > ... > > > If, to simplify, we assume there is only EF traffic in the > > network and the > > > routers provide perfect FIFO output queuing, is it then > > possible to come up > > > with the "network calculus" necessary to quantify how > > burstiness evolves > > > from node to node and how it impacts the necessary bound S? > > Current research > > > (the previously cited paper by Charny and Le Boudec and > > references therein) > > > would suggest this is extremely difficult or even impossible. > > > > We are not attempting to solve research problems, and we all hopefully > > agree that this "network calculus" is a research problem. Our job is > > very limited: specify a well-defined behaviour with some measureable > > properties. Requiring that we understand all the implications of a > > non-existent network calculus for compositions of this behaviour > > is by definition impossible. So we are going to re-specify EF without > > attempting the impossible. We're engineers. > > > > Brian Carpenter > > diffserv co-chair > > > > > >It seemed to me that EFRESOLVE requires network calculus to specify what is >meant by tolerable burstiness. For instance, I think it is not sufficient to >use a token bucket if you can't predict how bucket parameters evolve as EF >flows progress through the network aggregating and splitting in a fairly >arbitrary manner. How can you measure this burstiness and if you can't, how >can the behaviour be well defined? > >It seems the modified rate guarantee definition successfully avoids the need >to specify or measure burstiness. It defines a behaviour which can be >reasonably interpreted in a literal sense as "expedited forwarding", ie, it >approximates work conserving FIFO scheduling to within the tolerance defined >by the E bounds. It looks to me like a reasonable engineering solution. > >Jim > >_______________________________________________ >diffserv mailing list >diffserv@ietf.org >http://www1.ietf.org/mailman/listinfo/diffserv >Archive: >http://www2.ietf.org/mail-archive/working-groups/diffserv/current/maillist.html _______________________________________________ diffserv mailing list diffserv@ietf.org http://www1.ietf.org/mailman/listinfo/diffserv Archive: http://www2.ietf.org/mail-archive/working-groups/diffserv/current/maillist.html From diffserv-admin@ietf.org Mon Dec 11 14:28:58 2000 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with SMTP id OAA25727 for ; Mon, 11 Dec 2000 14:28:58 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id NAA12683; Mon, 11 Dec 2000 13:58:19 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id NAA12658 for ; Mon, 11 Dec 2000 13:58:15 -0500 (EST) 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 SMTP id NAA22103 for ; Mon, 11 Dec 2000 13:58:12 -0500 (EST) Received: from stl-av-02.boeing.com ([192.76.190.7]) by stl-smtpout-01.boeing.com (8.9.2/8.8.5-M2) with ESMTP id MAA13601 for ; Mon, 11 Dec 2000 12:58:12 -0600 (CST) Received: from stl-hub-01.boeing.com (localhost [127.0.0.1]) by stl-av-02.boeing.com (8.9.3/8.9.2) with ESMTP id MAA03717 for ; Mon, 11 Dec 2000 12:58:09 -0600 (CST) Received: from xch-phlbh-01.he.boeing.com by stl-hub-01.boeing.com with ESMTP; Mon, 11 Dec 2000 12:57:57 -0600 Received: by xch-phlbh-01.he.boeing.com with Internet Mail Service (5.5.2650.21) id ; Mon, 11 Dec 2000 13:57:57 -0500 Message-Id: <4102273CEB77D211869200805FE6F593018C5BE7@xch-phl-01.he.boeing.com> From: "Manfredi, Albert E" To: "'Joel M. Halpern'" , diffserv@ietf.org Subject: RE: [Diffserv] Possible compromise between EFRESOLVE and draft-ch arny Date: Mon, 11 Dec 2000 13:57:56 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: text/plain; charset="iso-8859-1" Sender: diffserv-admin@ietf.org Errors-To: diffserv-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Diffserv Discussion List X-BeenThere: diffserv@ietf.org Joel M. Halpern wrote: > Plugging back in the 4 megabits / second EF input rate and > the 40 gigabits > / second output wire rate, and the alternate packet > scheduling, we see that > S = 6.4 > > So, can we stop saying that we can not calculate S or that > all reasonable > schedulers give large S. Maybe this controversy would be resolved if we define two, rather than one, EF behaviors? One EF class minimizes latency while keeping jitter bounded. This is what you have today with EFRESOLVE, and would be appropriate, for example, for interactive voice links. The second EF class minimizes jitter exclusively, which would be appropriate for such services as non-real-time video distribution (e.g. TV over Internet). Defining these two classes would make it plain that large S is not necessarily acceptable, but is an option that might work in real-world applications of EF. Bert _______________________________________________ diffserv mailing list diffserv@ietf.org http://www1.ietf.org/mailman/listinfo/diffserv Archive: http://www2.ietf.org/mail-archive/working-groups/diffserv/current/maillist.html From diffserv-admin@ietf.org Mon Dec 11 14:30:57 2000 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with SMTP id OAA25995 for ; Mon, 11 Dec 2000 14:30:52 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id OAA12983; Mon, 11 Dec 2000 14:05:53 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id OAA12954 for ; Mon, 11 Dec 2000 14:05:49 -0500 (EST) Received: from usc.edu (root@usc.edu [128.125.253.136]) by ietf.org (8.9.1a/8.9.1a) with SMTP id OAA22978 for ; Mon, 11 Dec 2000 14:05:47 -0500 (EST) Received: from aludra.usc.edu (demir@aludra.usc.edu [128.125.253.184]) by usc.edu (8.9.3.1/8.9.3/usc) with ESMTP id LAA08929; Mon, 11 Dec 2000 11:05:47 -0800 (PST) Received: from localhost (demir@localhost) by aludra.usc.edu (8.9.3.1/8.9.3/usc) with ESMTP id LAA11323; Mon, 11 Dec 2000 11:05:46 -0800 (PST) Date: Mon, 11 Dec 2000 11:05:45 -0800 (PST) From: demir To: "Joel M. Halpern" cc: diffserv@ietf.org Subject: Re: [Diffserv] Possible compromise between EFRESOLVE and draft-ch arny In-Reply-To: <4.2.2.20001211133309.00b5a220@localhost> 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 Joel, > I am not sure what you are getting at. > Assume we have an EF RFC (new, old, different, ...). Why would this > "dominate every other PHBs and every diffserv compatible box". A device is > not and will not be required to implement / support EF. That is up to the > implementor. It is likely the case that support EF will have an impact on > the design of a device if the implementor has chosen to support it. But > that does not mean that it dominates or even affects every > diffserv-compatible box. No particular PHBs are mandatory to implement. What I mean by "domination" is "degree of impact". I was refering to EFRESOLVE. If it is not implemented, there is no "impact", degree=0 (no domination). It is "obivious" that EF PHB will have an impact on any Difserv box. I don't think that "degree of impact" will be the same for new, old, or different. And I added, if that is fine with Diffserv, there is no need to discuss (I believe this shouldn't be okay). Alper K. Demir > >Brian, > >I think whatever name EFRESOLVE uses for S other than B, it is not for > >"intended expedite" which is not clear yet. As long as this "finite > >bound" S remains bounding "delay variance" (D(i) - E(i)), EF PHB will > >dominate every other PHBs and every diffserv-compatible box. That means > >without understanding EF, it won't be possible to implemet other PHBs > >(currently, there is no problem with AF, but there could be others). May > >be instead of Expedited PHB, "Entry" point PHB for Diffserv :) would be a > >better choice :) If that is fine with Diffserv, then there is no need to > >discuss futher. > > > >Alper K. Demir > > > > > >On Mon, 11 Dec 2000, Brian E Carpenter wrote: > > > > > We decided a couple of weeks ago that > > > a) the EFRESOLVE S should be renamed Scale instead of Score > > > b) it is not a figure of merit but merely a bound that must exist as a > > finite value > > > > > > So I suggest we stop asking the same question repeatedly. > > > > > > Brian Carpenter > > > diffserv co-chair > > > > > > Bill Courtney wrote: > > > > > > > > Hi Bert, > > > > > > > > You wrote: > > > > > > > > > I'm afraid I don't understand the controversy regarding S. > > > > > > > > > > EFRESOLVE states that EF is defined as an aggregate flow for which the > > > > > difference between minimum possible delay and the maximum possible > > delay > > > > is > > > > > bounded by some number S X MTU transfer time when the arrival rate > > of this > > > > > incoming EF aggregate flow is specified as R. > > > > > > > > > > The underlying idea of EF, whether we can state this or no, has always > > > > been > > > > > (has it not?) to support a service similar to CBR, or approaching > > CBR, for > > > > > an aggregate flow. So S will determine how CBR-like this EF flow > > will be. > > > > > > > > > > > > > The controversy is based on the fact, as two or three earlier posts > > > > have established, that *perfectly fine schedulers* can have values of S > > > > that are orders of magnitude greater than the values for *less > > > > desirable schedulers*. (See, for example, some of Jon Bennett's > > > > mailings from near the time of efresolve's release.) By "perfectly > > > > fine," I mean schedulers that introduce little or no jitter or delay, > > > > and by "less desirable," I mean schedulers that introduce more > > > > jitter. Jon's examples and other similar difficulties with S are by no > > > > means exotic or unusual examples. > > > > > > > > So, S does not provide a useful measure of the worth of a > > > > scheduler (i.e., large values might mean anything), and a > > > > value of S can be found for almost every scheduler. Thus, > > > > efresolve offers us a definition that admits virtually > > > > everything and fails to make any useful distinction among > > > > the things it admits. > > > > > > > > > If some non-FIFO schedulers will result in large values of S, seems > > to me > > > > > that those schedulers are simply not ideal for EF use. Why is this an > > > > issue? > > > > > > > > The large values of S may have nothing to do with the > > > > usefulness of those schedulers for EF, or they may. > > > > It depends on the scheduler. Thus, S is a very poor > > > > discriminator. > > > > > > > > I, too, am mystified as to why there is still an issue. > > > > I would have thought that efresolve would have been > > > > discarded as an irredeemably failed attempt long ago. > > > > > > > > Cheers, > > > > Bill > > > > > > > > _______________________________________________ > > > > diffserv mailing list > > > > diffserv@ietf.org > > > > http://www1.ietf.org/mailman/listinfo/diffserv > > > > Archive: > > http://www2.ietf.org/mail-archive/working-groups/diffserv/current/maillist.html > > > > > > _______________________________________________ > > > diffserv mailing list > > > diffserv@ietf.org > > > http://www1.ietf.org/mailman/listinfo/diffserv > > > Archive: > > http://www2.ietf.org/mail-archive/working-groups/diffserv/current/maillist.html > > > > > > > > >_______________________________________________ > >diffserv mailing list > >diffserv@ietf.org > >http://www1.ietf.org/mailman/listinfo/diffserv > >Archive: > >http://www2.ietf.org/mail-archive/working-groups/diffserv/current/maillist.html > _______________________________________________ diffserv mailing list diffserv@ietf.org http://www1.ietf.org/mailman/listinfo/diffserv Archive: http://www2.ietf.org/mail-archive/working-groups/diffserv/current/maillist.html From diffserv-admin@ietf.org Mon Dec 11 14:34: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 SMTP id OAA26419 for ; Mon, 11 Dec 2000 14:34:27 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id OAA13200; Mon, 11 Dec 2000 14:14:04 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id OAA13167 for ; Mon, 11 Dec 2000 14:13:59 -0500 (EST) Received: from usc.edu (root@usc.edu [128.125.253.136]) by ietf.org (8.9.1a/8.9.1a) with SMTP id OAA24002 for ; Mon, 11 Dec 2000 14:13:58 -0500 (EST) Received: from aludra.usc.edu (demir@aludra.usc.edu [128.125.253.184]) by usc.edu (8.9.3.1/8.9.3/usc) with ESMTP id LAA17916 for ; Mon, 11 Dec 2000 11:13:55 -0800 (PST) Received: from localhost (demir@localhost) by aludra.usc.edu (8.9.3.1/8.9.3/usc) with ESMTP id LAA18942 for ; Mon, 11 Dec 2000 11:13:54 -0800 (PST) Date: Mon, 11 Dec 2000 11:13:54 -0800 (PST) From: demir To: diffserv@ietf.org Subject: [Diffserv] Another restriction of EFRESOLVE on conformance test In-Reply-To: <4.2.2.20001211124946.00b4e870@localhost> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: diffserv-admin@ietf.org Errors-To: diffserv-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Diffserv Discussion List X-BeenThere: diffserv@ietf.org I am not sure if anyone has already pointed out. If so, I appologize for bringing it up again. An EF (EFRESOLVE) scheduler can make D(i) - E(i) conformance test only before it sends a EF packet. If a non-EF packet arrives after a EF packet where EF packet's conformance has already calculated, but non-EF packet leaves before the EF packet though it has arrived after (for whatever reason), then pre-calulated D(i) - E(i) will be wrong. Is that acceptable? Alper K. Demir _______________________________________________ diffserv mailing list diffserv@ietf.org http://www1.ietf.org/mailman/listinfo/diffserv Archive: http://www2.ietf.org/mail-archive/working-groups/diffserv/current/maillist.html From diffserv-admin@ietf.org Mon Dec 11 14:47: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 SMTP id OAA27916 for ; Mon, 11 Dec 2000 14:47:14 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id OAA13524; Mon, 11 Dec 2000 14:25:15 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id OAA13421 for ; Mon, 11 Dec 2000 14:25:08 -0500 (EST) Received: from usc.edu (root@usc.edu [128.125.253.136]) by ietf.org (8.9.1a/8.9.1a) with SMTP id OAA25286 for ; Mon, 11 Dec 2000 14:25:06 -0500 (EST) Received: from aludra.usc.edu (demir@aludra.usc.edu [128.125.253.184]) by usc.edu (8.9.3.1/8.9.3/usc) with ESMTP id LAA29793; Mon, 11 Dec 2000 11:25:07 -0800 (PST) Received: from localhost (demir@localhost) by aludra.usc.edu (8.9.3.1/8.9.3/usc) with ESMTP id LAA00273; Mon, 11 Dec 2000 11:25:06 -0800 (PST) Date: Mon, 11 Dec 2000 11:25:05 -0800 (PST) From: demir To: "Joel M. Halpern" cc: ROBERTS James FTRD/DAC/ISS , diffserv@ietf.org Subject: RE: [Diffserv] Possible compromise between EFRESOLVE and draft-ch arny In-Reply-To: <4.2.2.20001211133852.00b50530@localhost> 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 Joel, > Using EFResolve (or Charny or in fact any other reasonable definition) will > require network calculus. Some of that will be in the PDB. Some will be > done by the vendor, and some by the customer. > But that does not mean that the EF definition requires network > calculus. The EF definition has to be defined in terms of a region of > applicability, including received burst characteristics. The user then > ensures that his usage results in traffic that falls within that > characteristic. To me, this is a "trade off" between "engineering" and "science". If it is okay to feel full by only "drinking water/juice" intead of 'eating a meal", then there is "no problem". No offence or harm to anyone. > PS: To defend my reference to the Charny draft having the same requirement, > note that the E_p definition is only applicable within an operating > region. That is the same operating region as for EFResolve. It seems this "operating region" has a great impact on "degree" that I have mentioned in my previous email. However, I don't think that both Charny draft and EFRESOLVE will have "same degree". Alper K. Demir _______________________________________________ diffserv mailing list diffserv@ietf.org http://www1.ietf.org/mailman/listinfo/diffserv Archive: http://www2.ietf.org/mail-archive/working-groups/diffserv/current/maillist.html From diffserv-admin@ietf.org Mon Dec 11 14:55: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 SMTP id OAA28933 for ; Mon, 11 Dec 2000 14:55:47 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id OAA13856; Mon, 11 Dec 2000 14:35:11 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id OAB13825 for ; Mon, 11 Dec 2000 14:35:06 -0500 (EST) Received: from usc.edu (root@usc.edu [128.125.253.136]) by ietf.org (8.9.1a/8.9.1a) with SMTP id OAA26501 for ; Mon, 11 Dec 2000 14:35:04 -0500 (EST) Received: from aludra.usc.edu (demir@aludra.usc.edu [128.125.253.184]) by usc.edu (8.9.3.1/8.9.3/usc) with ESMTP id LAA10908; Mon, 11 Dec 2000 11:35:05 -0800 (PST) Received: from localhost (demir@localhost) by aludra.usc.edu (8.9.3.1/8.9.3/usc) with ESMTP id LAA09880; Mon, 11 Dec 2000 11:35:03 -0800 (PST) Date: Mon, 11 Dec 2000 11:35:03 -0800 (PST) From: demir To: "Manfredi, Albert E" cc: "'Joel M. Halpern'" , diffserv@ietf.org Subject: RE: [Diffserv] Possible compromise between EFRESOLVE and draft-ch arny In-Reply-To: <4102273CEB77D211869200805FE6F593018C5BE7@xch-phl-01.he.boeing.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: diffserv-admin@ietf.org Errors-To: diffserv-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Diffserv Discussion List X-BeenThere: diffserv@ietf.org > Defining these two classes would make it plain that large S is not > necessarily acceptable, but is an option that might work in real-world > applications of EF. Why do we need "two classes" where we have a "superclass" and where we could "derive" "sub-classes" unless "redundancy" is "okay"? PDBs can "derive" "sub-classes". Alper K. Demir _______________________________________________ diffserv mailing list diffserv@ietf.org http://www1.ietf.org/mailman/listinfo/diffserv Archive: http://www2.ietf.org/mail-archive/working-groups/diffserv/current/maillist.html From diffserv-admin@ietf.org Mon Dec 11 14:59: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 SMTP id OAA29307 for ; Mon, 11 Dec 2000 14:59:02 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id OAA13958; Mon, 11 Dec 2000 14:39:09 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id OAA13937 for ; Mon, 11 Dec 2000 14:39:05 -0500 (EST) Received: from crufty.research.bell-labs.com (crufty.research.bell-labs.com [204.178.16.49]) by ietf.org (8.9.1a/8.9.1a) with SMTP id OAA26963 for ; Mon, 11 Dec 2000 14:39:01 -0500 (EST) Received: from chair.dnrc.bell-labs.com ([135.180.161.201]) by crufty; Mon Dec 11 14:37:22 EST 2000 Received: from harlem.dnrc.bell-labs.com (harlem [135.180.161.4]) by chair.dnrc.bell-labs.com (8.9.3/8.9.3) with ESMTP id OAA29150; Mon, 11 Dec 2000 14:34:46 -0500 (EST) From: Dimitrios Stiliadis Received: (from stiliadi@localhost) by harlem.dnrc.bell-labs.com (8.9.3/8.9.3) id OAA03679; Mon, 11 Dec 2000 14:38:20 -0500 (EST) Message-Id: <200012111938.OAA03679@harlem.dnrc.bell-labs.com> Subject: Re: [Diffserv] Possible compromise between EFRESOLVE and To: joel@longsys.com (Joel M. Halpern) Date: Mon, 11 Dec 2000 14:38:19 -0500 (EST) Cc: diffserv@ietf.org In-Reply-To: <4.2.2.20001211124946.00b4e870@localhost> from "Joel M. Halpern" at Dec 11, 2000 01:02:05 PM X-Mailer: ELM [version 2.5 PL2] MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: diffserv-admin@ietf.org Errors-To: diffserv-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Diffserv Discussion List X-BeenThere: diffserv@ietf.org Content-Transfer-Encoding: 7bit Joel, A couple of comments: . You assumed a 64 packet input burst. And that means that packets might get dropped, up-stream burstiness has created some more jitter.... but that is a general problem, so I ignore. > Assume for simplicity that the bursts are arriving at all inputs at once > (one can easily perform the math for more complex cases, but it does not > elucidate any more). Also assume that the input links are 44 megabits, and > the bursts arrive at wire rate. Thus this is an edge router and not a core router. Numbers are quite different if all links are 40Gbps, and you just have a small perecentage of traffic for EF. See below: > The last packet that will be leaving arrives on its interface at time > 64 * MTU / (input-wire) > It leaves the output interface at time > fixed-delay + 32,000 * MTU / (output-wire) > The earliest time it could have left is obviously its arrival time plus the > fixed delay. Therefore, in units of time the maximum time difference is > 32,000 * MTU / (output-wire) - 64 * MTU / (input-wire) > To show that S comes out fairly small even in bad cases, I will overstate > that S the implementor will calculate by ignoring ths second term. Then, > S = 32,0000 * (input-rate) / (output-EF) I hope you mean ^input-wire^ .. > Plugging back in the 4 megabits / second EF input rate and the 40 gigabits > / second output wire rate, and the alternate packet scheduling, we see that > S = 6.4 No problem ... though, you have an error. The input-wire rate in your example is 44Mbps and not 4Mbps. None guarantees that the input burst will arrive with 4Mbps. ... it can arrive at the full wire rate. Thus, based on my calculator S = 35.2 (following your equations). In addition, if input wire= output wire = 40Gbps, S= 32000 ... can you see the problem now ? (i.e. S becomes equal to your output burst size .. and it doesn't realy matter what scheduler you use .. the quality of the scheduler is hidden in the large numbers, that are dominated by the burst sizes) Dimitri _______________________________________________ diffserv mailing list diffserv@ietf.org http://www1.ietf.org/mailman/listinfo/diffserv Archive: http://www2.ietf.org/mail-archive/working-groups/diffserv/current/maillist.html From diffserv-admin@ietf.org Mon Dec 11 15:14: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 SMTP id PAA02394 for ; Mon, 11 Dec 2000 15:14:37 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id OAA14243; Mon, 11 Dec 2000 14:50:22 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id OAA14216 for ; Mon, 11 Dec 2000 14:50:18 -0500 (EST) Received: from DF-INET-1.dogfoodinternet.com (df-inet1.exchange.microsoft.com [131.107.8.8]) by ietf.org (8.9.1a/8.9.1a) with SMTP id OAA28283 for ; Mon, 11 Dec 2000 14:50:16 -0500 (EST) Received: from df-virus2.platinum.corp.microsoft.com ([172.30.236.33]) by DF-INET-1.dogfoodinternet.com with Microsoft SMTPSVC(5.0.2195.1600); Mon, 11 Dec 2000 10:43:15 -0800 Received: from 172.30.236.11 by df-virus2.platinum.corp.microsoft.com (InterScan E-Mail VirusWall NT); Mon, 11 Dec 2000 10:43:57 -0800 (Pacific Standard Time) Received: from DF-MILO.platinum.corp.microsoft.com ([172.30.236.125]) by yuri.dns.microsoft.com with Microsoft SMTPSVC(5.0.2195.2532); Mon, 11 Dec 2000 10:43:57 -0800 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C063A2.5165C972" Date: Mon, 11 Dec 2000 10:43:56 -0800 X-MimeOLE: Produced By Microsoft Exchange V6.0.4604.0 Message-ID: Thread-Topic: comments on the bulk handling draft Thread-Index: AcBjjySrFgLkX4oMQTO7TRAE7TtCdg== From: "Yoram Bernet" To: X-OriginalArrivalTime: 11 Dec 2000 18:43:57.0066 (UTC) FILETIME=[5190A6A0:01C063A2] Subject: [Diffserv] comments on the bulk handling 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 This is a multi-part message in MIME format. ------_=_NextPart_001_01C063A2.5165C972 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable First of all - i'm glad to see this. I think that it is a useful and necessary pdb. I'll comment on it, realizing that I have not been keeping up with the mailing list and that I missed the last IETF. So - pls pardon if I am restating the obvious or raising issues that have already been addressed/resolved.=20 One general comment I have relates to the name chosen for the pdb. I think that the name 'bulk handling' does a disservice to the pdb. In certain cases, there is an overlap between applications that 'bulk handle' and the service provided by the pdb. However, there are many bulk handling applications that cannot use the pdb and there are applications of the pdb that extend beyond bulk handling.=20 For example - 'transfer all accounting records from new york to london each night' can be considered a bulk handling task, yet would likely not be happy with what is effectively, less than best-effort (LBE) service. In addition, I see one of the primary applications of the bh pdb in the incremental deployment of aggressive multimedia applications (that use non-adaptive UDP). IT managers are reluctant to deploy (for example) streaming media over wan links because they cannot control the impact of these apps on the wan link resources. One way in which we might see these more likely to be deployed is if some controlled amount of the multimedia traffic could be given priopritized service (appropriate for the media), but any amount beyond this would be relegated to the bh pdb (to prevent it from seizing network resources required for best-effort. Based on these considerations - I would rather this pdb be called the LBE (less than best effort pdb) rather than the bh pdb - I think is is a much more descriptive name.=20 Another general comment - wasn't just this type of pdb proposed previously? I think that it was proposed as draft-mumble-lbe-xx. I can't remember the authors, but - one may have been Roland Bless. Whoever they were, those authors deserve acknowledgement.=20 As for specific comments: 1. Throughout, change 'bulk handling' to 'less-than-best-effort'. 2. In the 'Applicability' section - describe the application to new applications that use non-adaptive protocols (primarily multimedia). From expereince with customers and IT managers - this type of service is essential to the deployment of those types of applications. 3. I think the last sentence in section 2 is too strong. No operator intends to operate their network in a manner in which it is always congested. Certain applications may be deployable only if they are willing to take what is available. This means that on networks that are frequently congested, they may not get much - but then - that's what this pdb is all about. Basically - I think that this should be a warning to this effect, rather than a suggestion that the behaviour canot be used on congested networks. 4. I object to the following rules in section 3.1:=20 The network edge must include a classifier that selects the appropriate BH target group of packets out of all arriving packets and steers them to a marker which sets the appropriate DSCP to select a PHB configured as described in the next section. Why? In many cases, the customer may chose to premark packets for this pdb. In that case, why would the ingress need to classify beyond recognizing the dscp? No MF classification is required. No marking is required. Rather, it is optional. In fact - I think that this rule should be clairified for all pdbs, probably in the pdb specification draft itself. There are many complexities in requiring the ingress node of a diffserv domain to classify or mark (consider the case of encrypted packets). Classification and marking (beyond the dscp) should be optional for all pdbs.. 5. Wrt 3.2, last paragraph - the use of 'CS1' as the DSCP for this pdb is also appealing in its consistency with the interpretaion of 802.1p user_prioritiy codepoints. In that usage, a codepoint of 1 is also lesser than a codepoint of 0.=20 ------_=_NextPart_001_01C063A2.5165C972 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable comments on the bulk handling draft

First of all - i'm glad to see this. I = think that it is a useful and necessary pdb. I'll comment on it, = realizing that I have not been keeping up with the mailing list and that = I missed the last IETF. So - pls pardon if I am restating the obvious or = raising issues that have already been addressed/resolved.

One general comment I have relates to = the name chosen for the pdb. I think that the name 'bulk handling' does = a disservice to the pdb. In certain cases, there is an overlap between = applications that 'bulk handle' and the service provided by the pdb. = However, there are many bulk handling applications that cannot use the = pdb and there are applications of the pdb that extend beyond bulk = handling.

For example - 'transfer all accounting = records from new york to london each night' can be considered a bulk = handling task, yet would likely not be happy with what is effectively, = less than best-effort (LBE) service. In addition, I see one of the = primary applications of the bh pdb in the incremental deployment of = aggressive multimedia applications (that use non-adaptive UDP). IT = managers are reluctant to deploy (for example) streaming media over wan = links because they cannot control the impact of these apps on the wan = link resources. One way in which we might see these more likely to be = deployed is if some controlled amount of the multimedia traffic could be = given priopritized service (appropriate for the media), but any amount = beyond this would be relegated to the bh pdb (to prevent it from seizing = network resources required for best-effort. Based on these = considerations - I would rather  this pdb be called the LBE (less = than best effort pdb) rather than the bh pdb - I think is is a much more = descriptive name.

Another general comment - wasn't just = this type of pdb proposed previously? I think that it was proposed as = draft-mumble-lbe-xx. I can't remember the authors, but - one may have = been Roland Bless. Whoever they were, those authors deserve = acknowledgement.

As for specific comments:
1. Throughout, change 'bulk handling' = to 'less-than-best-effort'.
2. In the 'Applicability' section - = describe the application to new applications that use non-adaptive = protocols (primarily multimedia). From expereince with customers and IT = managers - this type of service is essential to the deployment of those = types of applications.

3. I think the last sentence in section = 2 is too strong. No operator intends to operate their network in a = manner in which it is always congested. Certain applications may be = deployable only if they are willing to take what is available. This = means that on networks that are frequently congested, they may not get = much - but then - that's what this pdb is all about. Basically - I think = that this should be a warning to this effect, rather than a suggestion = that the behaviour canot be used on congested networks.

4. I object to the following rules in = section 3.1:
The network edge must = include
a classifier that selects the = appropriate BH target group of packets
out of all arriving packets and = steers them to a marker which sets
the appropriate DSCP to select a = PHB configured as described in
the next section.
Why? In many cases, the customer may = chose to premark packets for this pdb. In that case, why would the = ingress need to classify beyond recognizing the dscp? No MF = classification is required. No marking is required. Rather, it is = optional. In fact - I think that this rule should be clairified for all = pdbs, probably in the pdb specification draft itself. There are many = complexities in requiring the ingress node of a diffserv domain to = classify or mark (consider the case of encrypted packets). = Classification and marking (beyond the dscp) should be optional for all = pdbs..

5. Wrt 3.2, last paragraph - the use of = 'CS1' as the DSCP for this pdb is also appealing in its consistency with = the interpretaion of 802.1p user_prioritiy codepoints. In that usage, a = codepoint of 1 is also lesser than a codepoint of 0.

------_=_NextPart_001_01C063A2.5165C972-- _______________________________________________ diffserv mailing list diffserv@ietf.org http://www1.ietf.org/mailman/listinfo/diffserv Archive: http://www2.ietf.org/mail-archive/working-groups/diffserv/current/maillist.html From diffserv-admin@ietf.org Mon Dec 11 16:24: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 SMTP id QAA12351 for ; Mon, 11 Dec 2000 16:24:01 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id QAA15634; Mon, 11 Dec 2000 16:02:34 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id QAA15602 for ; Mon, 11 Dec 2000 16:02:30 -0500 (EST) Received: from longsys.com (dmz.longsys.com [63.111.150.5]) by ietf.org (8.9.1a/8.9.1a) with SMTP id QAA09836 for ; Mon, 11 Dec 2000 16:02:27 -0500 (EST) Received: from joel (discordian.longsys.com [63.111.150.74]) by longsys.com (8.10.0/8.10.0) with ESMTP id eBBL2LS24713; Mon, 11 Dec 2000 21:02:21 GMT Message-Id: <4.2.2.20001211155525.00b577c0@localhost> X-Sender: joel@localhost X-Mailer: QUALCOMM Windows Eudora Pro Version 4.2.2 Date: Mon, 11 Dec 2000 16:00:03 -0500 To: Dimitrios Stiliadis From: "Joel M. Halpern" Subject: Re: [Diffserv] Possible compromise between EFRESOLVE and Cc: diffserv@ietf.org In-Reply-To: <200012111938.OAA03679@harlem.dnrc.bell-labs.com> References: <4.2.2.20001211124946.00b4e870@localhost> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: diffserv-admin@ietf.org Errors-To: diffserv-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Diffserv Discussion List X-BeenThere: diffserv@ietf.org A) The "input-rate" in the last part of the calculation is the input EF rate, not the input wire rate. B) The Output EF rate must exceed the total input EF rates. There is indeed a case that produces large S if you are trying to run a trunk and add traffic from a large number of small interfaces. If the input EF rate were 1 gig, the output were 1.5, and one was adding 400 1 megabit EF streams, each of which could burst several packets, one would have a large S. On the other hand, one would also really have a large variation in the potential delay. So a large S is indeed appropriate. C) The packet size did not actually appear in the formula. I actually assumed that all packets were of size = MTU, which then fell out of the equation. If the packets are smaller, the impact is reduced. D) It was pointed out to be that the EF output service rate in the example was unrealistically high. If you change the example to a 10 gig output link with the same scheduler (5 gig output EF service) the S is 26. Yours, Joel M. Halpern At 02:38 PM 12/11/00 -0500, Dimitrios Stiliadis wrote: >Joel, > >A couple of comments: > >. You assumed a 64 packet input burst. And that means that > packets might get dropped, up-stream burstiness has > created some more jitter.... but that is a general > problem, so I ignore. > > > Assume for simplicity that the bursts are arriving at all inputs at once > > (one can easily perform the math for more complex cases, but it does not > > elucidate any more). Also assume that the input links are 44 megabits, > and > > the bursts arrive at wire rate. > >Thus this is an edge router and not a core router. Numbers >are quite different if all links are 40Gbps, and you just >have a small perecentage of traffic for EF. See below: > > > The last packet that will be leaving arrives on its interface at time > > 64 * MTU / (input-wire) > > It leaves the output interface at time > > fixed-delay + 32,000 * MTU / (output-wire) > > The earliest time it could have left is obviously its arrival time plus > the > > fixed delay. Therefore, in units of time the maximum time difference is > > 32,000 * MTU / (output-wire) - 64 * MTU / (input-wire) > > To show that S comes out fairly small even in bad cases, I will overstate > > that S the implementor will calculate by ignoring ths second term. Then, > > S = 32,0000 * (input-rate) / (output-EF) > I hope you mean ^input-wire^ .. > > > Plugging back in the 4 megabits / second EF input rate and the 40 gigabits > > / second output wire rate, and the alternate packet scheduling, we see that > > S = 6.4 > >No problem ... though, you have an error. The input-wire rate >in your example is 44Mbps and not 4Mbps. None guarantees >that the input burst will arrive with 4Mbps. ... it can >arrive at the full wire rate. Thus, based on my >calculator S = 35.2 (following your equations). > >In addition, if input wire= output wire = 40Gbps, >S= 32000 ... can you see the problem now ? > (i.e. S becomes equal to your output burst size .. and it doesn't > realy matter what scheduler you use .. the quality > of the scheduler is hidden in the large numbers, that > are dominated by the burst sizes) > >Dimitri _______________________________________________ diffserv mailing list diffserv@ietf.org http://www1.ietf.org/mailman/listinfo/diffserv Archive: http://www2.ietf.org/mail-archive/working-groups/diffserv/current/maillist.html From diffserv-admin@ietf.org Mon Dec 11 16:24:22 2000 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with SMTP id QAA12394 for ; Mon, 11 Dec 2000 16:24:18 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id QAA15691; Mon, 11 Dec 2000 16:05:19 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id QAA15657 for ; Mon, 11 Dec 2000 16:05:14 -0500 (EST) Received: from longsys.com (dmz.longsys.com [63.111.150.5]) by ietf.org (8.9.1a/8.9.1a) with SMTP id QAA10162 for ; Mon, 11 Dec 2000 16:05:11 -0500 (EST) Received: from joel (discordian.longsys.com [63.111.150.74]) by longsys.com (8.10.0/8.10.0) with ESMTP id eBBL57t24757; Mon, 11 Dec 2000 21:05:07 GMT Message-Id: <4.2.2.20001211160030.00b57af0@localhost> X-Sender: joel@localhost X-Mailer: QUALCOMM Windows Eudora Pro Version 4.2.2 Date: Mon, 11 Dec 2000 16:02:49 -0500 To: demir , diffserv@ietf.org From: "Joel M. Halpern" Subject: Re: [Diffserv] Another restriction of EFRESOLVE on conformance test In-Reply-To: References: <4.2.2.20001211124946.00b4e870@localhost> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: diffserv-admin@ietf.org Errors-To: diffserv-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Diffserv Discussion List X-BeenThere: diffserv@ietf.org The specific decision in crafting this form of definition was that conformance testing can only be done in a test environment, It is certainly true that one can not characterize in the operational network the E(i) that an actually serviced stream would have received. However, if the device does EF you know what the bounds are anyway. Conformance testing in an operational environment while nice is simply not a feature of our definition. Yours, Joel M. Halpern At 11:13 AM 12/11/00 -0800, demir wrote: >I am not sure if anyone has already pointed out. If so, I appologize for >bringing it up again. > >An EF (EFRESOLVE) scheduler can make D(i) - E(i) conformance test only >before it sends a EF packet. If a non-EF packet arrives after a EF packet >where EF packet's conformance has already calculated, but non-EF packet >leaves before the EF packet though it has arrived after (for whatever >reason), then pre-calulated D(i) - E(i) will be wrong. Is that acceptable? > >Alper K. Demir > > > > >_______________________________________________ >diffserv mailing list >diffserv@ietf.org >http://www1.ietf.org/mailman/listinfo/diffserv >Archive: >http://www2.ietf.org/mail-archive/working-groups/diffserv/current/maillist.html _______________________________________________ diffserv mailing list diffserv@ietf.org http://www1.ietf.org/mailman/listinfo/diffserv Archive: http://www2.ietf.org/mail-archive/working-groups/diffserv/current/maillist.html From diffserv-admin@ietf.org Mon Dec 11 16:35:51 2000 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with SMTP id QAA13833 for ; Mon, 11 Dec 2000 16:35:51 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id QAA15872; Mon, 11 Dec 2000 16:15:51 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id QAA15850 for ; Mon, 11 Dec 2000 16:15:47 -0500 (EST) Received: from p-mail2.cnet.fr (p-mail2.rd.francetelecom.fr [193.49.124.32]) by ietf.org (8.9.1a/8.9.1a) with SMTP id QAA11382 for ; Mon, 11 Dec 2000 16:15:44 -0500 (EST) Received: by p-voyageur.issy.cnet.fr with Internet Mail Service (5.5.2650.21) id ; Mon, 11 Dec 2000 22:14:33 +0100 Message-ID: <98388C05D464D111B61800805F15041601418A5C@p-ibis.issy.cnet.fr> From: ROBERTS James FTRD/DAC/ISS To: "'Joel M. Halpern'" , diffserv@ietf.org Subject: RE: [Diffserv] Possible compromise between EFRESOLVE and draft-ch arny Date: Mon, 11 Dec 2000 22:14:32 +0100 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: text/plain; charset="iso-8859-1" Sender: diffserv-admin@ietf.org Errors-To: diffserv-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Diffserv Discussion List X-BeenThere: diffserv@ietf.org > > scheduling, we see that > S = 6.4 > > So, can we stop saying that we can not calculate S or that > all reasonable > schedulers give large S. > A delay of 6.4 seconds _is_ large for most of the applications I was thinking about like VoIP. And if the burstines of the aggregate leaving the router you consider is bounded, what about the burstiness of the particular EF pipes splitting out from that aggregate at the next router? And the burstiness of the output from that router? And so on? There is an exponential increase in burstiness. Except that the first router is probably the last router in the path of other aggregates so that it not even possible to make iterative calculations. It really is not simple to understand how worst case burstiness propagates, even in the absence of non-EF traffic. Jim _______________________________________________ diffserv mailing list diffserv@ietf.org http://www1.ietf.org/mailman/listinfo/diffserv Archive: http://www2.ietf.org/mail-archive/working-groups/diffserv/current/maillist.html From diffserv-admin@ietf.org Mon Dec 11 16:37:54 2000 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with SMTP id QAA14080 for ; Mon, 11 Dec 2000 16:37:54 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id QAA15813; Mon, 11 Dec 2000 16:14:06 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id QAA15786 for ; Mon, 11 Dec 2000 16:14:03 -0500 (EST) 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 QAA11189 for ; Mon, 11 Dec 2000 16:14:00 -0500 (EST) Received: from chair.dnrc.bell-labs.com ([135.180.161.201]) by dirty; Mon Dec 11 16:13:32 EST 2000 Received: from harlem.dnrc.bell-labs.com (harlem [135.180.161.4]) by chair.dnrc.bell-labs.com (8.9.3/8.9.3) with ESMTP id QAA00592; Mon, 11 Dec 2000 16:09:57 -0500 (EST) From: Dimitrios Stiliadis Received: (from stiliadi@localhost) by harlem.dnrc.bell-labs.com (8.9.3/8.9.3) id QAA04340; Mon, 11 Dec 2000 16:13:31 -0500 (EST) Message-Id: <200012112113.QAA04340@harlem.dnrc.bell-labs.com> Subject: Re: [Diffserv] Possible compromise between EFRESOLVE and To: joel@longsys.com (Joel M. Halpern) Date: Mon, 11 Dec 2000 16:13:31 -0500 (EST) Cc: diffserv@ietf.org In-Reply-To: <4.2.2.20001211155525.00b577c0@localhost> from "Joel M. Halpern" at Dec 11, 2000 04:00:03 PM X-Mailer: ELM [version 2.5 PL2] MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: diffserv-admin@ietf.org Errors-To: diffserv-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Diffserv Discussion List X-BeenThere: diffserv@ietf.org Content-Transfer-Encoding: 7bit > > A) The "input-rate" in the last part of the calculation is the input EF > rate, not the input wire rate. I am sorry, but I don't agree with that. The maximum burst can arrive with the wire-rate and not the EF rate. Thus, the larger the input wire rate the faster you receive the burst, and the higher the burst that will be observed at the output. (assume that the previous scheduler is a priority one) Even if assume the above statemtn is correct, that it is not, you can always assume that you have de-aggregation. (i.e. you have 40Mbits of input EF traffic, out of which only 4Mpbs go to the particular interface ... and thus the input rate becomes very close to the wire-rate ...). You can also make the argument that 80% EF is not normal .. but then, I will tell you assume 1Gbps links, and you will get again the same result. Dimitri _______________________________________________ diffserv mailing list diffserv@ietf.org http://www1.ietf.org/mailman/listinfo/diffserv Archive: http://www2.ietf.org/mail-archive/working-groups/diffserv/current/maillist.html From diffserv-admin@ietf.org Mon Dec 11 16:45: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 SMTP id QAA14987 for ; Mon, 11 Dec 2000 16:45:20 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id QAA15972; Mon, 11 Dec 2000 16:20:49 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id QAA15942 for ; Mon, 11 Dec 2000 16:20:45 -0500 (EST) Received: from p-mail1.cnet.fr (p-mail1.rd.francetelecom.fr [193.49.124.31]) by ietf.org (8.9.1a/8.9.1a) with SMTP id QAA11965 for ; Mon, 11 Dec 2000 16:20:42 -0500 (EST) Received: by p-biset.issy.cnet.fr with Internet Mail Service (5.5.2650.21) id ; Mon, 11 Dec 2000 22:20:04 +0100 Message-ID: <98388C05D464D111B61800805F15041601418A5D@p-ibis.issy.cnet.fr> From: ROBERTS James FTRD/DAC/ISS To: "'diffserv@ietf.org'" Subject: TR: [Diffserv] Possible compromise between EFRESOLVE and draft-ch arny Date: Mon, 11 Dec 2000 22:20:03 +0100 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: text/plain; charset="iso-8859-1" Sender: diffserv-admin@ietf.org Errors-To: diffserv-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Diffserv Discussion List X-BeenThere: diffserv@ietf.org A delay of 6.4 seconds _is_ large for most of the applications I was thinking about like VoIP. I'm sorry. This was a stupid error. S is of course a number of packet times. Jim _______________________________________________ diffserv mailing list diffserv@ietf.org http://www1.ietf.org/mailman/listinfo/diffserv Archive: http://www2.ietf.org/mail-archive/working-groups/diffserv/current/maillist.html From diffserv-admin@ietf.org Mon Dec 11 16:45: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 SMTP id QAA15040 for ; Mon, 11 Dec 2000 16:45:47 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id QAA16065; Mon, 11 Dec 2000 16:25:00 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id QAA16042 for ; Mon, 11 Dec 2000 16:24:56 -0500 (EST) Received: from longsys.com (dmz.longsys.com [63.111.150.5]) by ietf.org (8.9.1a/8.9.1a) with SMTP id QAA12481 for ; Mon, 11 Dec 2000 16:24:54 -0500 (EST) Received: from joel (discordian.longsys.com [63.111.150.74]) by longsys.com (8.10.0/8.10.0) with ESMTP id eBBLOoO25165; Mon, 11 Dec 2000 21:24:50 GMT Message-Id: <4.2.2.20001211162008.00b62da0@localhost> X-Sender: joel@localhost X-Mailer: QUALCOMM Windows Eudora Pro Version 4.2.2 Date: Mon, 11 Dec 2000 16:22:16 -0500 To: ROBERTS James FTRD/DAC/ISS , diffserv@ietf.org From: "Joel M. Halpern" Subject: RE: [Diffserv] Possible compromise between EFRESOLVE and draft-ch arny In-Reply-To: <98388C05D464D111B61800805F15041601418A5C@p-ibis.issy.cnet. fr> 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 S is not in units of seconds. S is in units of inverse packets (which is probably best thought of as dimensionless). Yours, Joel M. Halpern At 10:14 PM 12/11/00 +0100, ROBERTS James FTRD/DAC/ISS wrote: > > > > > scheduling, we see that > > S = 6.4 > > > > So, can we stop saying that we can not calculate S or that > > all reasonable > > schedulers give large S. > > > >A delay of 6.4 seconds _is_ large for most of the applications I was >thinking about like VoIP. > >And if the burstines of the aggregate leaving the router you consider is >bounded, what about the burstiness of the particular EF pipes splitting out >from that aggregate at the next router? And the burstiness of the output >from that router? And so on? There is an exponential increase in burstiness. >Except that the first router is probably the last router in the path of >other aggregates so that it not even possible to make iterative >calculations. > >It really is not simple to understand how worst case burstiness propagates, >even in the absence of non-EF traffic. > >Jim > _______________________________________________ diffserv mailing list diffserv@ietf.org http://www1.ietf.org/mailman/listinfo/diffserv Archive: http://www2.ietf.org/mail-archive/working-groups/diffserv/current/maillist.html From diffserv-admin@ietf.org Mon Dec 11 16:52:58 2000 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with SMTP id QAA15902 for ; Mon, 11 Dec 2000 16:52:58 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id QAA16341; Mon, 11 Dec 2000 16:31:47 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id QAA16308 for ; Mon, 11 Dec 2000 16:31:42 -0500 (EST) Received: from babar.switch.ch (babar.switch.ch [130.59.4.2]) by ietf.org (8.9.1a/8.9.1a) with SMTP id QAA13297 for ; Mon, 11 Dec 2000 16:31:38 -0500 (EST) Received: (from leinen@localhost) by babar.switch.ch (8.9.3+Sun/8.9.3) id WAA15763; Mon, 11 Dec 2000 22:31:05 +0100 (MET) X-Authentication-Warning: babar.switch.ch: leinen set sender to simon@limmat.switch.ch using -f To: "Yoram Bernet" Cc: Subject: LBE PHB [was: [Diffserv] comments on the bulk handling draft] References: X-Face: 1Nk*r=:$IBBb8|TyRB'2WSY6u:BzMO7N)#id#-4_}MsU5?vTI?dez|JiutW4sKBLjp.l7,F 7QOld^hORRtpCUj)!cP]gtK_SyK5FW(+o"!or:v^C^]OxX^3+IPd\z,@ttmwYVO7l`6OXXYR` From: Simon Leinen In-Reply-To: Date: 11 Dec 2000 22:31:04 +0100 Message-ID: Lines: 19 User-Agent: Gnus/5.09 (Gnus v5.9.0) Emacs/21.0.92 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 >>>>> "yb" == Yoram Bernet writes: > Another general comment - wasn't just this type of pdb proposed > previously? I think that it was proposed as draft-mumble-lbe-xx. I > can't remember the authors, but - one may have been Roland > Bless. Whoever they were, those authors deserve acknowledgement. Actually it was a PHB, not a PDB, and the draft suggests that it could be used for a variety of different PHBs. Title : A Lower Than Best-Effort Per-Hop Behavior Author(s) : R. Bless, K. Wehrle Filename : draft-bless-diffserv-lbe-phb-00.txt Pages : 9 Date : 08-Sep-99 http://www-nrg.ee.lbl.gov/diff-serv-arch/msg04311.html http://www.telematik.informatik.uni-karlsruhe.de/forschung/diffserv/lit/draft-bless-diffserv-lbe-phb-00.txt -- Simon. _______________________________________________ diffserv mailing list diffserv@ietf.org http://www1.ietf.org/mailman/listinfo/diffserv Archive: http://www2.ietf.org/mail-archive/working-groups/diffserv/current/maillist.html From diffserv-admin@ietf.org Mon Dec 11 17:07: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 SMTP id RAA17673 for ; Mon, 11 Dec 2000 17:07:02 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id QAA16557; Mon, 11 Dec 2000 16:38:31 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id QAA16526 for ; Mon, 11 Dec 2000 16:38:26 -0500 (EST) Received: from usc.edu (root@usc.edu [128.125.253.136]) by ietf.org (8.9.1a/8.9.1a) with SMTP id QAA14153 for ; Mon, 11 Dec 2000 16:38:23 -0500 (EST) Received: from aludra.usc.edu (demir@aludra.usc.edu [128.125.253.184]) by usc.edu (8.9.3.1/8.9.3/usc) with ESMTP id NAA24218; Mon, 11 Dec 2000 13:38:25 -0800 (PST) Received: from localhost (demir@localhost) by aludra.usc.edu (8.9.3.1/8.9.3/usc) with ESMTP id NAA21094; Mon, 11 Dec 2000 13:38:24 -0800 (PST) Date: Mon, 11 Dec 2000 13:38:23 -0800 (PST) From: demir To: "Joel M. Halpern" cc: diffserv@ietf.org Subject: Re: [Diffserv] Another restriction of EFRESOLVE on conformance test In-Reply-To: <4.2.2.20001211160030.00b57af0@localhost> 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 Joel, > The specific decision in crafting this form of definition was that > conformance testing can only be done in a test environment, It is > certainly true that one can not characterize in the operational network the > E(i) that an actually serviced stream would have received. However, if the > device does EF you know what the bounds are anyway. Conformance testing in > an operational environment while nice is simply not a feature of our > definition. I agree with above "statements". In addition, both E(i) and D(i) has the same problem. I accept that "conformance testing in an operational environment" is simply not a feature of your definition. Are we talking about a "utopian"/"misterious" PHB? It seems to me that EFRESOLVE is trying some "acrobatic" to tackle all problems related to it (Please no offence or harm to anyone. This is only what I see). If we assume "everything" (provided all conditions), we can construct a scale to hold the "earth" (I recall similiar phrase from physics class, sorry for not being able to write it down in English as it is said). Alper K. Demir > At 11:13 AM 12/11/00 -0800, demir wrote: > >I am not sure if anyone has already pointed out. If so, I appologize for > >bringing it up again. > > > >An EF (EFRESOLVE) scheduler can make D(i) - E(i) conformance test only > >before it sends a EF packet. If a non-EF packet arrives after a EF packet > >where EF packet's conformance has already calculated, but non-EF packet > >leaves before the EF packet though it has arrived after (for whatever > >reason), then pre-calulated D(i) - E(i) will be wrong. Is that acceptable? > > > >Alper K. Demir > > > > > > > > > >_______________________________________________ > >diffserv mailing list > >diffserv@ietf.org > >http://www1.ietf.org/mailman/listinfo/diffserv > >Archive: > >http://www2.ietf.org/mail-archive/working-groups/diffserv/current/maillist.html > _______________________________________________ diffserv mailing list diffserv@ietf.org http://www1.ietf.org/mailman/listinfo/diffserv Archive: http://www2.ietf.org/mail-archive/working-groups/diffserv/current/maillist.html From diffserv-admin@ietf.org Mon Dec 11 18:01: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 SMTP id SAA25850 for ; Mon, 11 Dec 2000 18:01:25 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id RAA18040; Mon, 11 Dec 2000 17:36:17 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id RAA18009 for ; Mon, 11 Dec 2000 17:36:13 -0500 (EST) 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 SMTP id RAA21490 for ; Mon, 11 Dec 2000 17:36:11 -0500 (EST) Received: from stl-av-02.boeing.com ([192.76.190.7]) by stl-smtpout-01.boeing.com (8.9.2/8.8.5-M2) with ESMTP id QAA13129 for ; Mon, 11 Dec 2000 16:36:12 -0600 (CST) Received: from stl-hub-01.boeing.com (localhost [127.0.0.1]) by stl-av-02.boeing.com (8.9.3/8.9.2) with ESMTP id QAA29604 for ; Mon, 11 Dec 2000 16:36:11 -0600 (CST) Received: from xch-phlbh-01.he.boeing.com by stl-hub-01.boeing.com with ESMTP; Mon, 11 Dec 2000 16:36:02 -0600 Received: by xch-phlbh-01.he.boeing.com with Internet Mail Service (5.5.2650.21) id ; Mon, 11 Dec 2000 17:36:01 -0500 Message-Id: <4102273CEB77D211869200805FE6F593018C5BEC@xch-phl-01.he.boeing.com> From: "Manfredi, Albert E" To: "'ROBERTS James FTRD/DAC/ISS'" , diffserv@ietf.org Subject: RE: [Diffserv] Possible compromise between EFRESOLVE and draft-ch arny Date: Mon, 11 Dec 2000 17:36:01 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: text/plain; charset="iso-8859-1" Sender: diffserv-admin@ietf.org Errors-To: diffserv-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Diffserv Discussion List X-BeenThere: diffserv@ietf.org ROBERTS James FTRD/DAC/ISS wrote: > And if the burstines of the aggregate leaving the router you > consider is > bounded, what about the burstiness of the particular EF pipes > splitting out > from that aggregate at the next router? And the burstiness of > the output > from that router? And so on? There is an exponential increase > in burstiness. True. That's why some on this list have been suggesting that shapers might be required in the core of DS nets. Bert _______________________________________________ diffserv mailing list diffserv@ietf.org http://www1.ietf.org/mailman/listinfo/diffserv Archive: http://www2.ietf.org/mail-archive/working-groups/diffserv/current/maillist.html From diffserv-admin@ietf.org Mon Dec 11 18:07:40 2000 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with SMTP id SAA27163 for ; Mon, 11 Dec 2000 18:07:40 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id RAA18181; Mon, 11 Dec 2000 17:46:28 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id RAA18149 for ; Mon, 11 Dec 2000 17:46:24 -0500 (EST) Received: from rmx441-mta.mail.com (rmx441-mta.mail.com [165.251.48.44]) by ietf.org (8.9.1a/8.9.1a) with SMTP id RAA22704 for ; Mon, 11 Dec 2000 17:46:21 -0500 (EST) Received: from web641-wra.mail.com (web641-wra.mail.com [165.251.33.76]) by rmx441-mta.mail.com (8.9.3/8.9.3) with SMTP id RAA15684; Mon, 11 Dec 2000 17:46:22 -0500 (EST) Message-ID: <391645842.976574781858.JavaMail.root@web641-wra.mail.com> Date: Mon, 11 Dec 2000 17:46:19 -0500 (EST) From: Bill Courtney To: Brian E Carpenter , diffserv@ietf.org Subject: Re: [Diffserv] Possible compromise between EFRESOLVE and draft-ch arny Mime-Version: 1.0 Content-Type: text/plain Content-Transfer-Encoding: 7bit X-Mailer: mail.com X-Originating-IP: 207.137.70.185 Content-Transfer-Encoding: 7bit Sender: diffserv-admin@ietf.org Errors-To: diffserv-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Diffserv Discussion List X-BeenThere: diffserv@ietf.org Content-Transfer-Encoding: 7bit Maybe, Brian. At least YOU decided that. Recent messages would suggest that many regard S as a figure of merit. (I am not among them. I think that nothing that performs as badly as S should be called a figure-of-merit.) Others cannot imagine an EF definition that admits every router that offers any finite delay variation bound (no matter how large) without any advertised value that might be used by engineers to configure their networks (i.e., without any advertised figure-of-merit). Bill Brian wrote: > We decided a couple of weeks ago that > a) the EFRESOLVE S should be renamed Scale instead of Score > b) it is not a figure of merit but merely a bound that must > exist as a finite value > So I suggest we stop asking the same question repeatedly. > Brian Carpenter > diffserv co-chair _______________________________________________ diffserv mailing list diffserv@ietf.org http://www1.ietf.org/mailman/listinfo/diffserv Archive: http://www2.ietf.org/mail-archive/working-groups/diffserv/current/maillist.html From diffserv-admin@ietf.org Mon Dec 11 18:25:02 2000 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with SMTP id SAA00860 for ; Mon, 11 Dec 2000 18:25:02 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id RAA18413; Mon, 11 Dec 2000 17:57:12 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id RAA18310 for ; Mon, 11 Dec 2000 17:57:04 -0500 (EST) Received: from pilgrim.cisco.com (pilgrim.cisco.com [171.69.204.12]) by ietf.org (8.9.1a/8.9.1a) with SMTP id RAA24913 for ; Mon, 11 Dec 2000 17:57:02 -0500 (EST) Received: from acharny-nt.cisco.com (sj-dial-3-240.cisco.com [171.68.180.241]) by pilgrim.cisco.com (8.8.8-Cisco List Logging/8.8.8) with ESMTP id RAA20889; Mon, 11 Dec 2000 17:55:59 -0500 (EST) Message-Id: <4.3.2.7.2.20001211173704.00c6c3e0@pilgrim.cisco.com> X-Sender: acharny@pilgrim.cisco.com X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Mon, 11 Dec 2000 18:01:40 -0500 To: "Manfredi, Albert E" , "'Anna Charny'" From: Anna Charny Subject: RE: [Diffserv] Possible compromise between EFRESOLVE and draft-ch arny Cc: diffserv@ietf.org In-Reply-To: <4102273CEB77D211869200805FE6F593018C5BDD@xch-phl-01.he.boe ing.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 Bert, At 05:53 PM 12/10/00 -0500, Manfredi, Albert E wrote: >Anna Charny wrote: > > > Alessio Casati wrote: > > > > > - non-FIFO treatment of EF will typically lead to a large > > value of S > > > > > > >It appears this concern was addressed on the list and > > >multiple voices supported that this point was not valid. > > >As such we don't need to discuss about this further. > > > > Do you mean to say that it is not true that devices with > > non-FIFO treatment > > will have large S, or that it is not important that they have large S? > > > > I would also like to point out that there were also multiple > > voices on the > > list that supported the opinion that this point was valid, so > > I suggest > > that we need to address this question > > with a more technical discussion. > >I'm afraid I don't understand the controversy regarding S. > >EFRESOLVE states that EF is defined as an aggregate flow for which the >difference between minimum possible delay and the maximum possible delay is >bounded by some number S X MTU transfer time when the arrival rate of this >incoming EF aggregate flow is specified as R. > >The underlying idea of EF, whether we can state this or no, has always been >(has it not?) to support a service similar to CBR, or approaching CBR, for >an aggregate flow. So S will determine how CBR-like this EF flow will be. > >If some non-FIFO schedulers will result in large values of S, seems to me >that those schedulers are simply not ideal for EF use. Why is this an issue? I think Bill may have answered this question, but let me give my answer. Consider an ideal output buffered device with 1000 ports, all links being the same speed. Suppose that 1/5000 of traffic from each input goes to each output (that is, all links in the router is exactly 50% booked with EF traffic). Suppose every output implements a strict priority queue. An ideal output buffered device with a PQ at each output seems to me as close to an ideal device as we can get for EF support. Suppose now a single packet destined for the same output j arrives at the same time to each one of 1000 inputs. Would you agree that S has to be at least 999? Now, let's go one step further and assume that we actually allow B back-to-back packet burst at each input. Do you agree that S must be at least 999 times B? Does this example answer your question? > > We are concerned, however, that the > > decision of the > > team to use the input rate only makes it difficult to generalize the > > definition to a device with a range of interface speeds in a > > way meaningful > > in the diffserv environment. While it is possible that we > > misunderstand how > > you plan to address this issue, we have not been able to get any > > clarification of this (and in fact at least two members of > > your team have > > acknowledged that such generalization is not obvious). > > > > It may help if you can give the answer to the following questions. > > Can you please let us know what is the maximum input rate R > > that a device > > can support in the case of multiple speeds of interfaces, > > when the device > > is just characterized by a single value of R (your draft > > says that this is > > the speed of the slowest interface - do you believe it is > > correct?). > >Wouldn't the total EF arrival rate at the box be R? And if so, if the speed >of the slowest egress >= R, then haven't we guaranteed that the delay >variation will remain bounded? I think you are quite right. Note however, that your statement above does not say anything about the max rate *at each input*, rather it says that the sum of R at all inputs must be at most the *output* capacity. The efresolve draft says that a device must advertise a value of R such that as long as the *input rate* on any interface does not exceed R, the device must guarantee a particular jitter bound. That seems to me to imply that in a device with n inputs, the input rate R cannot exceed 1/n of the output interface speed. This is because all you know is a constraint on the total amount of EF traffic at a given input, but you do not actually know where it goes. In particular, all of it may happen to go to the same output, and the efresolve says you must provide bounded jitter in that case. Suppose you have a router with 1000 identical speed interfaces. If you are specifying this router by a single value of *input rate* R, then you seem to be limited by R <= smallest output interface speed/1000 for *all EF traffic on a given input*. This seems like an unacceptably small number - it would be bad if all we could do was to support 0.1% of total EF traffic at each interface. Now, maybe it might be possible to solve this problem by specifying different combinations of R's and S's for different traffic matrices. But I frankly do not understand how that can be done in the standard hose model diffserv environment (true, for the pipe model, where you have information about how much traffic goes from each input to each output, it is possible top give such a matrix; but for the hose model you only know how much EF traffic there is going from a given input to all outputs together). This is what I meant when I asked Alessio to explain how you can specify the constraints in the multi-input multi-output case with different interface speeds. Regards, Anna >Bert > >_______________________________________________ >diffserv mailing list >diffserv@ietf.org >http://www1.ietf.org/mailman/listinfo/diffserv >Archive: >http://www2.ietf.org/mail-archive/working-groups/diffserv/current/maillist.html --------------------------------------- Anna Charny Cisco Systems, Inc 300 Apollo Drive Chelmsford, MA 01824 Tel. (978)-244-8172 Fax (978)-244-8126 _______________________________________________ diffserv mailing list diffserv@ietf.org http://www1.ietf.org/mailman/listinfo/diffserv Archive: http://www2.ietf.org/mail-archive/working-groups/diffserv/current/maillist.html From diffserv-admin@ietf.org Mon Dec 11 18:49: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 SMTP id SAA06076 for ; Mon, 11 Dec 2000 18:49:28 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id SAA18977; Mon, 11 Dec 2000 18:20:43 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id SAA18952 for ; Mon, 11 Dec 2000 18:20:39 -0500 (EST) Received: from pilgrim.cisco.com (pilgrim.cisco.com [171.69.204.12]) by ietf.org (8.9.1a/8.9.1a) with SMTP id SAA29859 for ; Mon, 11 Dec 2000 18:20:37 -0500 (EST) Received: from acharny-nt.cisco.com (sj-dial-3-240.cisco.com [171.68.180.241]) by pilgrim.cisco.com (8.8.8-Cisco List Logging/8.8.8) with ESMTP id SAA23196; Mon, 11 Dec 2000 18:19:35 -0500 (EST) Message-Id: <4.3.2.7.2.20001211180522.00c7c6c0@pilgrim.cisco.com> X-Sender: acharny@pilgrim.cisco.com X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Mon, 11 Dec 2000 18:25:16 -0500 To: "Joel M. Halpern" , diffserv@ietf.org From: Anna Charny Subject: RE: [Diffserv] Possible compromise between EFRESOLVE and draft-ch arny In-Reply-To: <4.2.2.20001211124946.00b4e870@localhost> References: <98388C05D464D111B61800805F15041601418A52@p-ibis.issy.cnet. fr> 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 Joel, Would you agree that S in your example is very much dependent on the traffic matrix you chose? For example, suppose that there happens to be no traffic going to the high-speed interface, but rather all traffic happens for the moment to be going between all low-speed interfaces, of which there are 500. (I am assuming that all interfaces are full-duplex, so for any input interface of speed X there is also an output interface of the same speed X. Suppose there is only 0.004 megabits of traffic on each of these inputs, but all this traffic happens to go to the same 4 megabit output interface. Do you agree that for that traffic matrix in the same device, you would have to have S at least equal to 499, because one packet destined to the same output interface can arrive at the same time for a given output, (and this does not even include the allowed input burstiness that would need to be used as an additional multiplier). So if you are specifying your device by a single triple (R, S, max input burstiness), which is what efresolve draft says is the default specification, then you will be forced in this case to declare a much greater S that your example suggests. Do you disagree with that? You may say that you can specify a S for each combination of possible traffic matrices. Although cumbersome, it may indeed be possible to do for the pipe model. But what about the hose model? How do you specify these multiple sets of constraints when all you have at your disposal is the total input traffic on each input interface, but no knowledge how much of this traffic actually goes to a given output? Thanks in advance for a clarification, Anna At 01:02 PM 12/11/00 -0500, Joel M. Halpern wrote: >If all the traffic is EF, then the full output is dedicated to EF, and >things work easily. > >Given the latest request for an example, here is one. I am sure that >people will argue that it is a bad example. So be it. > >The assumption in this example is a pipe model of EF usage. A number of >interfaces supporting EF traffic are directing that EF traffic to a common >output. The implementor must specify, for the burst limit that he is >willing to support, what the R and S are for each input. For simplicity, >all of the inputs will use the same R in this example. > >The configuration is 500 input interfaces, each allowing 4 megabits / >second of EF, and a total burst limit on the output of 32,000 >packets. The common output is a 40 gigabit link. The EF scheduler in use >alternates EF packets and everything else. > >Assume for simplicity that the bursts are arriving at all inputs at once >(one can easily perform the math for more complex cases, but it does not >elucidate any more). Also assume that the input links are 44 megabits, >and the bursts arrive at wire rate. >The last packet that will be leaving arrives on its interface at time > 64 * MTU / (input-wire) >It leaves the output interface at time > fixed-delay + 32,000 * MTU / (output-wire) >The earliest time it could have left is obviously its arrival time plus >the fixed delay. Therefore, in units of time the maximum time difference is > 32,000 * MTU / (output-wire) - 64 * MTU / (input-wire) >To show that S comes out fairly small even in bad cases, I will overstate >that S the implementor will calculate by ignoring ths second term. Then, > S = 32,0000 * (input-rate) / (output-EF) >Plugging back in the 4 megabits / second EF input rate and the 40 gigabits >/ second output wire rate, and the alternate packet scheduling, we see that > S = 6.4 > >So, can we stop saying that we can not calculate S or that all reasonable >schedulers give large S. > >Yours, >Joel M. Halpern > > >_______________________________________________ >diffserv mailing list >diffserv@ietf.org >http://www1.ietf.org/mailman/listinfo/diffserv >Archive: >http://www2.ietf.org/mail-archive/working-groups/diffserv/current/maillist.html > --------------------------------------- Anna Charny Cisco Systems, Inc 300 Apollo Drive Chelmsford, MA 01824 Tel. (978)-244-8172 Fax (978)-244-8126 _______________________________________________ diffserv mailing list diffserv@ietf.org http://www1.ietf.org/mailman/listinfo/diffserv Archive: http://www2.ietf.org/mail-archive/working-groups/diffserv/current/maillist.html From diffserv-admin@ietf.org Mon Dec 11 18:54:54 2000 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with SMTP id SAA07254 for ; Mon, 11 Dec 2000 18:54:54 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id SAA19100; Mon, 11 Dec 2000 18:26:38 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id SAA19068 for ; Mon, 11 Dec 2000 18:26:32 -0500 (EST) Received: from longsys.com (dmz.longsys.com [63.111.150.5]) by ietf.org (8.9.1a/8.9.1a) with SMTP id SAA01168 for ; Mon, 11 Dec 2000 18:26:30 -0500 (EST) Received: from joel (discordian.longsys.com [63.111.150.74]) by longsys.com (8.10.0/8.10.0) with ESMTP id eBBNQSE27672; Mon, 11 Dec 2000 23:26:28 GMT Message-Id: <4.2.2.20001211182246.00b66b20@localhost> X-Sender: joel@localhost X-Mailer: QUALCOMM Windows Eudora Pro Version 4.2.2 Date: Mon, 11 Dec 2000 18:24:08 -0500 To: Anna Charny , diffserv@ietf.org From: "Joel M. Halpern" Subject: RE: [Diffserv] Possible compromise between EFRESOLVE and draft-ch arny In-Reply-To: <4.3.2.7.2.20001211180522.00c7c6c0@pilgrim.cisco.com> References: <4.2.2.20001211124946.00b4e870@localhost> <98388C05D464D111B61800805F15041601418A52@p-ibis.issy.cnet. fr> 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 Yes, it (S) is dependent upon the matrix I chose. In fact, the zero-loss domain of the definitions in your document is also dependent upon such a matrix. Yours, Joel M. Halpern At 06:25 PM 12/11/00 -0500, Anna Charny wrote: >Joel, > >Would you agree that S in your example is very much dependent on the >traffic matrix you chose? For example, suppose that there happens to be no >traffic going to the high-speed interface, but rather all traffic happens >for the moment to be going between all low-speed interfaces, of which >there are 500. (I am assuming that all interfaces are full-duplex, so for >any input interface of speed X there is also an output interface of the >same speed X. >Suppose there is only 0.004 megabits of traffic on each of these inputs, >but all this traffic happens to go to the same 4 megabit output >interface. Do you agree that for that traffic matrix in the same device, >you would have to have S at least equal to 499, because one packet >destined to the same output interface can arrive at the same time for a >given output, (and this does not even include the allowed input burstiness >that would need to be used as an additional multiplier). So if you are >specifying your device by a single triple (R, S, max input burstiness), >which is what efresolve draft says is the default specification, then you >will be forced in this case to declare a much greater S that your example >suggests. Do you disagree with that? > >You may say that you can specify a S for each combination of possible >traffic matrices. Although cumbersome, it may indeed be possible to do >for the pipe model. But what about the hose model? How do you specify >these multiple sets of constraints when all you have at your disposal is >the total input traffic on each input interface, but no knowledge how much >of this traffic actually goes to a given output? > >Thanks in advance for a clarification, >Anna > >At 01:02 PM 12/11/00 -0500, Joel M. Halpern wrote: >>If all the traffic is EF, then the full output is dedicated to EF, and >>things work easily. >> >>Given the latest request for an example, here is one. I am sure that >>people will argue that it is a bad example. So be it. >> >>The assumption in this example is a pipe model of EF usage. A number of >>interfaces supporting EF traffic are directing that EF traffic to a >>common output. The implementor must specify, for the burst limit that he >>is willing to support, what the R and S are for each input. For >>simplicity, all of the inputs will use the same R in this example. >> >>The configuration is 500 input interfaces, each allowing 4 megabits / >>second of EF, and a total burst limit on the output of 32,000 >>packets. The common output is a 40 gigabit link. The EF scheduler in >>use alternates EF packets and everything else. >> >>Assume for simplicity that the bursts are arriving at all inputs at once >>(one can easily perform the math for more complex cases, but it does not >>elucidate any more). Also assume that the input links are 44 megabits, >>and the bursts arrive at wire rate. >>The last packet that will be leaving arrives on its interface at time >> 64 * MTU / (input-wire) >>It leaves the output interface at time >> fixed-delay + 32,000 * MTU / (output-wire) >>The earliest time it could have left is obviously its arrival time plus >>the fixed delay. Therefore, in units of time the maximum time difference is >> 32,000 * MTU / (output-wire) - 64 * MTU / (input-wire) >>To show that S comes out fairly small even in bad cases, I will overstate >>that S the implementor will calculate by ignoring ths second term. Then, >> S = 32,0000 * (input-rate) / (output-EF) >>Plugging back in the 4 megabits / second EF input rate and the 40 >>gigabits / second output wire rate, and the alternate packet scheduling, >>we see that >> S = 6.4 >> >>So, can we stop saying that we can not calculate S or that all reasonable >>schedulers give large S. >> >>Yours, >>Joel M. Halpern >> >> >>_______________________________________________ >>diffserv mailing list >>diffserv@ietf.org >>http://www1.ietf.org/mailman/listinfo/diffserv >>Archive: >>http://www2.ietf.org/mail-archive/working-groups/diffserv/current/maillist.html > > >--------------------------------------- >Anna Charny >Cisco Systems, Inc >300 Apollo Drive >Chelmsford, MA 01824 >Tel. (978)-244-8172 >Fax (978)-244-8126 _______________________________________________ diffserv mailing list diffserv@ietf.org http://www1.ietf.org/mailman/listinfo/diffserv Archive: http://www2.ietf.org/mail-archive/working-groups/diffserv/current/maillist.html From diffserv-admin@ietf.org Mon Dec 11 19: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 SMTP id TAA13633 for ; Mon, 11 Dec 2000 19:24:04 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id SAA19856; Mon, 11 Dec 2000 18:57:28 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id SAA19825 for ; Mon, 11 Dec 2000 18:57:24 -0500 (EST) Received: from mailhub1.almaden.ibm.com (mailhub1.almaden.ibm.com [198.4.83.44]) by ietf.org (8.9.1a/8.9.1a) with SMTP id SAA07828 for ; Mon, 11 Dec 2000 18:57:23 -0500 (EST) Received: from maui.almaden.ibm.com (maui.almaden.ibm.com [9.1.24.92]) by mailhub1.almaden.ibm.com (8.8.8/8.8.8) with ESMTP id PAA19464; Mon, 11 Dec 2000 15:54:33 -0800 Received: from hursley.ibm.com (gsine01.us.sine.ibm.com [9.14.6.41]) by maui.almaden.ibm.com (AIX4.3/8.9.3/8.7) with ESMTP id PAA32486; Mon, 11 Dec 2000 15:56:51 -0800 Message-ID: <3A356987.1453F7DE@hursley.ibm.com> Date: Mon, 11 Dec 2000 17:55:51 -0600 From: Brian E Carpenter Organization: IBM X-Mailer: Mozilla 4.61 [en] (Win98; I) X-Accept-Language: en,fr MIME-Version: 1.0 To: Simon Leinen CC: Yoram Bernet , diffserv@ietf.org Subject: Re: LBE PHB [was: [Diffserv] comments on the bulk handling draft] References: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: diffserv-admin@ietf.org Errors-To: diffserv-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Diffserv Discussion List X-BeenThere: diffserv@ietf.org Content-Transfer-Encoding: 7bit I agree that the draft deserves recognition. The reason Kathie and I wrote our draft was because we don't believe there is any reason to define a new PHB to support this type of PDB. As Kathie said today, the LBE name is no better chosen than BH. Maybe we should call the new PDB "NCT" for Non-Critical Traffic? Brian Simon Leinen wrote: > > >>>>> "yb" == Yoram Bernet writes: > > Another general comment - wasn't just this type of pdb proposed > > previously? I think that it was proposed as draft-mumble-lbe-xx. I > > can't remember the authors, but - one may have been Roland > > Bless. Whoever they were, those authors deserve acknowledgement. > > Actually it was a PHB, not a PDB, and the draft suggests that it could > be used for a variety of different PHBs. > > Title : A Lower Than Best-Effort Per-Hop Behavior > Author(s) : R. Bless, K. Wehrle > Filename : draft-bless-diffserv-lbe-phb-00.txt > Pages : 9 > Date : 08-Sep-99 > > http://www-nrg.ee.lbl.gov/diff-serv-arch/msg04311.html > http://www.telematik.informatik.uni-karlsruhe.de/forschung/diffserv/lit/draft-bless-diffserv-lbe-phb-00.txt > -- > Simon. > > _______________________________________________ > diffserv mailing list > diffserv@ietf.org > http://www1.ietf.org/mailman/listinfo/diffserv > Archive: http://www2.ietf.org/mail-archive/working-groups/diffserv/current/maillist.html _______________________________________________ diffserv mailing list diffserv@ietf.org http://www1.ietf.org/mailman/listinfo/diffserv Archive: http://www2.ietf.org/mail-archive/working-groups/diffserv/current/maillist.html From diffserv-admin@ietf.org Mon Dec 11 19:25: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 SMTP id TAA13973 for ; Mon, 11 Dec 2000 19:25:39 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id TAA20131; Mon, 11 Dec 2000 19:04:11 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id TAA20102 for ; Mon, 11 Dec 2000 19:04:07 -0500 (EST) Received: from mailhub1.almaden.ibm.com (mailhub1.almaden.ibm.com [198.4.83.44]) by ietf.org (8.9.1a/8.9.1a) with SMTP id TAA09305 for ; Mon, 11 Dec 2000 19:04:06 -0500 (EST) Received: from maui.almaden.ibm.com (maui.almaden.ibm.com [9.1.24.92]) by mailhub1.almaden.ibm.com (8.8.8/8.8.8) with ESMTP id QAA25100; Mon, 11 Dec 2000 16:01:17 -0800 Received: from hursley.ibm.com (gsine01.us.sine.ibm.com [9.14.6.41]) by maui.almaden.ibm.com (AIX4.3/8.9.3/8.7) with ESMTP id QAA24736; Mon, 11 Dec 2000 16:03:35 -0800 Message-ID: <3A356B1B.2AA12704@hursley.ibm.com> Date: Mon, 11 Dec 2000 18:02:35 -0600 From: Brian E Carpenter Organization: IBM X-Mailer: Mozilla 4.61 [en] (Win98; I) X-Accept-Language: en,fr MIME-Version: 1.0 To: demir CC: diffserv@ietf.org Subject: Re: [Diffserv] Another restriction of EFRESOLVE on conformance test 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 Your point isn't clear. There isn't any real difficulty in doing a lab test to measure the sequence E(i) with a standard traffic source, followed by a test to measure D(i) with the same source but in the presence of other traffic from one or more other standard traffic sources. There is a significant difficulty in doing the same thing outside the lab, but that is nothing new and nothing specific to EF. Brian demir wrote: > > Joel, > > The specific decision in crafting this form of definition was that > > conformance testing can only be done in a test environment, It is > > certainly true that one can not characterize in the operational network the > > E(i) that an actually serviced stream would have received. However, if the > > device does EF you know what the bounds are anyway. Conformance testing in > > an operational environment while nice is simply not a feature of our > > definition. > > I agree with above "statements". In addition, both E(i) and D(i) has the > same problem. I accept that "conformance testing in an operational > environment" is simply not a feature of your definition. Are we talking > about a "utopian"/"misterious" PHB? It seems to me that EFRESOLVE is > trying some "acrobatic" to tackle all problems related to it (Please no > offence or harm to anyone. This is only what I see). If we assume > "everything" (provided all conditions), we can construct a scale to hold > the "earth" (I recall similiar phrase from physics class, sorry for not > being able to write it down in English as it is said). > > Alper K. Demir > > > At 11:13 AM 12/11/00 -0800, demir wrote: > > >I am not sure if anyone has already pointed out. If so, I appologize for > > >bringing it up again. > > > > > >An EF (EFRESOLVE) scheduler can make D(i) - E(i) conformance test only > > >before it sends a EF packet. If a non-EF packet arrives after a EF packet > > >where EF packet's conformance has already calculated, but non-EF packet > > >leaves before the EF packet though it has arrived after (for whatever > > >reason), then pre-calulated D(i) - E(i) will be wrong. Is that acceptable? > > > > > >Alper K. Demir > > > > > > > > > > > > > > >_______________________________________________ > > >diffserv mailing list > > >diffserv@ietf.org > > >http://www1.ietf.org/mailman/listinfo/diffserv > > >Archive: > > >http://www2.ietf.org/mail-archive/working-groups/diffserv/current/maillist.html > > > > _______________________________________________ > diffserv mailing list > diffserv@ietf.org > http://www1.ietf.org/mailman/listinfo/diffserv > Archive: http://www2.ietf.org/mail-archive/working-groups/diffserv/current/maillist.html -- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - Brian E Carpenter Program Director, Internet Standards & Technology, IBM On assignment for IBM at http://www.iCAIR.org Board Chairman, Internet Society http://www.isoc.org Non-IBM email: brian@icair.org _______________________________________________ diffserv mailing list diffserv@ietf.org http://www1.ietf.org/mailman/listinfo/diffserv Archive: http://www2.ietf.org/mail-archive/working-groups/diffserv/current/maillist.html From diffserv-admin@ietf.org Mon Dec 11 19:47:31 2000 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with SMTP id TAA16766 for ; Mon, 11 Dec 2000 19:47:31 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id TAA20389; Mon, 11 Dec 2000 19:21:52 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id TAA20357 for ; Mon, 11 Dec 2000 19:21:48 -0500 (EST) Received: from yarilo.pluris.com (pluris.com [208.227.9.12]) by ietf.org (8.9.1a/8.9.1a) with SMTP id TAA13133 for ; Mon, 11 Dec 2000 19:21:42 -0500 (EST) Received: from DL100779.pluris.com (volsung.pluris.com [172.16.50.19]) by yarilo.pluris.com (8.9.2/8.9.1) with ESMTP id QAA19908; Mon, 11 Dec 2000 16:21:39 -0800 (PST) Message-Id: <5.0.2.1.0.20001211162022.02836668@localhost> X-Sender: akyol@localhost X-Mailer: QUALCOMM Windows Eudora Version 5.0.2 Date: Mon, 11 Dec 2000 16:21:33 -0800 To: Brian E Carpenter From: Bora Akyol Subject: Re: LBE PHB [was: [Diffserv] comments on the bulk handling draft] Cc: diffserv@ietf.org In-Reply-To: <3A356987.1453F7DE@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 Brian Despite what was presented today, PDB smells awfully like a service definition to me. This is fine by me. Does this mean that we finally are starting to consider the services that the PHBs are designed to support? Bora At 03:55 PM 12/11/2000, Brian E Carpenter wrote: >I agree that the draft deserves recognition. The reason Kathie and I >wrote our draft was because we don't believe there is any reason >to define a new PHB to support this type of PDB. > >As Kathie said today, the LBE name is no better chosen than >BH. Maybe we should call the new PDB "NCT" for Non-Critical Traffic? > > Brian > >Simon Leinen wrote: > > > > >>>>> "yb" == Yoram Bernet writes: > > > Another general comment - wasn't just this type of pdb proposed > > > previously? I think that it was proposed as draft-mumble-lbe-xx. I > > > can't remember the authors, but - one may have been Roland > > > Bless. Whoever they were, those authors deserve acknowledgement. > > > > Actually it was a PHB, not a PDB, and the draft suggests that it could > > be used for a variety of different PHBs. > > > > Title : A Lower Than Best-Effort Per-Hop Behavior > > Author(s) : R. Bless, K. Wehrle > > Filename : draft-bless-diffserv-lbe-phb-00.txt > > Pages : 9 > > Date : 08-Sep-99 > > > > http://www-nrg.ee.lbl.gov/diff-serv-arch/msg04311.html > > > http://www.telematik.informatik.uni-karlsruhe.de/forschung/diffserv/lit/draft-bless-diffserv-lbe-phb-00.txt > > -- > > Simon. > > > > _______________________________________________ > > diffserv mailing list > > diffserv@ietf.org > > http://www1.ietf.org/mailman/listinfo/diffserv > > Archive: > http://www2.ietf.org/mail-archive/working-groups/diffserv/current/maillist.html > >_______________________________________________ >diffserv mailing list >diffserv@ietf.org >http://www1.ietf.org/mailman/listinfo/diffserv >Archive: >http://www2.ietf.org/mail-archive/working-groups/diffserv/current/maillist.html > Bora Akyol Pluris akyol@pluris.com _______________________________________________ diffserv mailing list diffserv@ietf.org http://www1.ietf.org/mailman/listinfo/diffserv Archive: http://www2.ietf.org/mail-archive/working-groups/diffserv/current/maillist.html From diffserv-admin@ietf.org Mon Dec 11 19:50: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 SMTP id TAA17140 for ; Mon, 11 Dec 2000 19:50:45 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id TAA20452; Mon, 11 Dec 2000 19:23:14 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id TAA20418 for ; Mon, 11 Dec 2000 19:23:09 -0500 (EST) Received: from mailhub1.almaden.ibm.com (mailhub1.almaden.ibm.com [198.4.83.44]) by ietf.org (8.9.1a/8.9.1a) with SMTP id TAA13430 for ; Mon, 11 Dec 2000 19:23:08 -0500 (EST) Received: from maui.almaden.ibm.com (maui.almaden.ibm.com [9.1.24.92]) by mailhub1.almaden.ibm.com (8.8.8/8.8.8) with ESMTP id QAA57276; Mon, 11 Dec 2000 16:20:19 -0800 Received: from hursley.ibm.com (gsine01.us.sine.ibm.com [9.14.6.41]) by maui.almaden.ibm.com (AIX4.3/8.9.3/8.7) with ESMTP id QAA09700; Mon, 11 Dec 2000 16:22:37 -0800 Message-ID: <3A356F91.38FB6799@hursley.ibm.com> Date: Mon, 11 Dec 2000 18:21:37 -0600 From: Brian E Carpenter Organization: IBM X-Mailer: Mozilla 4.61 [en] (Win98; I) X-Accept-Language: en,fr MIME-Version: 1.0 To: Bill Courtney CC: diffserv@ietf.org Subject: Re: [Diffserv] Possible compromise between EFRESOLVE and draft-ch arny References: <391645842.976574781858.JavaMail.root@web641-wra.mail.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: diffserv-admin@ietf.org Errors-To: diffserv-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Diffserv Discussion List X-BeenThere: diffserv@ietf.org Content-Transfer-Encoding: 7bit Bill, Actually I believe the design team accepted the change in interpretation. I agree that you wouldn't comparison shop based on S. I would expect vendors to characterise their products with other metrics entirely, but it doesn't follow that we attempt to standardise them. Brian Bill Courtney wrote: > > Maybe, Brian. At least YOU decided that. Recent messages would > suggest that many regard S as a figure of merit. (I am not > among them. I think that nothing that performs as badly as S > should be called a figure-of-merit.) > > Others cannot imagine an EF definition that admits every router > that offers any finite delay variation bound (no matter how > large) without any advertised value that might be used by > engineers to configure their networks (i.e., without any > advertised figure-of-merit). > > Bill > > Brian wrote: > > > We decided a couple of weeks ago that > > a) the EFRESOLVE S should be renamed Scale instead of Score > > b) it is not a figure of merit but merely a bound that must > > exist as a finite value > > > So I suggest we stop asking the same question repeatedly. > > > Brian Carpenter > > diffserv co-chair _______________________________________________ diffserv mailing list diffserv@ietf.org http://www1.ietf.org/mailman/listinfo/diffserv Archive: http://www2.ietf.org/mail-archive/working-groups/diffserv/current/maillist.html From diffserv-admin@ietf.org Mon Dec 11 19:54: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 SMTP id TAA17632 for ; Mon, 11 Dec 2000 19:54:45 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id TAA20739; Mon, 11 Dec 2000 19:31:06 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id TAA20704 for ; Mon, 11 Dec 2000 19:31:00 -0500 (EST) Received: from mailhub1.almaden.ibm.com (mailhub1.almaden.ibm.com [198.4.83.44]) by ietf.org (8.9.1a/8.9.1a) with SMTP id TAA14888 for ; Mon, 11 Dec 2000 19:30:59 -0500 (EST) Received: from maui.almaden.ibm.com (maui.almaden.ibm.com [9.1.24.92]) by mailhub1.almaden.ibm.com (8.8.8/8.8.8) with ESMTP id QAA31426; Mon, 11 Dec 2000 16:28:10 -0800 Received: from hursley.ibm.com (gsine01.us.sine.ibm.com [9.14.6.41]) by maui.almaden.ibm.com (AIX4.3/8.9.3/8.7) with ESMTP id QAA22370; Mon, 11 Dec 2000 16:30:29 -0800 Message-ID: <3A357168.11AEB189@hursley.ibm.com> Date: Mon, 11 Dec 2000 18:29:28 -0600 From: Brian E Carpenter Organization: IBM X-Mailer: Mozilla 4.61 [en] (Win98; I) X-Accept-Language: en,fr MIME-Version: 1.0 To: Anna Charny CC: diffserv@ietf.org Subject: Re: [Diffserv] Possible compromise between EFRESOLVE anddraft-ch arny References: <4.3.2.7.2.20001211173704.00c6c3e0@pilgrim.cisco.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: diffserv-admin@ietf.org Errors-To: diffserv-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Diffserv Discussion List X-BeenThere: diffserv@ietf.org Content-Transfer-Encoding: 7bit Anna Charny wrote: ... > I think Bill may have answered this question, but let me give my > answer. Consider an ideal output buffered device with 1000 ports, all > links being the same speed. Suppose that 1/5000 of traffic from each input > goes to each output (that is, all links in the router is exactly 50% booked > with EF traffic). Suppose every output implements a strict priority > queue. An ideal output buffered device with a PQ at each output seems to > me as close to an ideal device as we can get for EF support. Suppose now a > single packet destined for the same output j arrives at the same time to > each one of 1000 inputs. Would you agree that S has to be at least > 999? Now, let's go one step further and assume that we actually allow B > back-to-back packet burst at each input. Do you agree that S must be at > least 999 times B? Isn't it the case that this (the fact that the queue will instantaneously contain at least 999 or 999B packets) is a truism whatever scheduler and EF definition is in use? Brian _______________________________________________ diffserv mailing list diffserv@ietf.org http://www1.ietf.org/mailman/listinfo/diffserv Archive: http://www2.ietf.org/mail-archive/working-groups/diffserv/current/maillist.html From diffserv-admin@ietf.org Mon Dec 11 20:05: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 SMTP id UAA18869 for ; Mon, 11 Dec 2000 20:05:00 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id TAA20971; Mon, 11 Dec 2000 19:43:35 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id TAA20940 for ; Mon, 11 Dec 2000 19:43:30 -0500 (EST) Received: from web4206.mail.yahoo.com (web4206.mail.yahoo.com [216.115.104.139]) by ietf.org (8.9.1a/8.9.1a) with SMTP id TAA16300 for ; Mon, 11 Dec 2000 19:43:29 -0500 (EST) From: g_mercankosk@yahoo.com Message-ID: <20001212004300.15215.qmail@web4206.mail.yahoo.com> Received: from [207.137.71.20] by web4206.mail.yahoo.com; Mon, 11 Dec 2000 16:43:00 PST Date: Mon, 11 Dec 2000 16:43:00 -0800 (PST) Subject: RE: [Diffserv] Possible compromise between EFRESOLVE and draft-ch arny To: ROBERTS James FTRD/DAC/ISS , "'Joel M. Halpern'" , diffserv@ietf.org Cc: guven@ee.uwa.edu.au 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 Jim, > > And if the burstines of the aggregate leaving the > router you consider is > bounded, what about the burstiness of the particular > EF pipes splitting out > from that aggregate at the next router? And the > burstiness of the output > from that router? And so on? There is an exponential > increase in burstiness. > Except that the first router is probably the last > router in the path of > other aggregates so that it not even possible to > make iterative > calculations. > > It really is not simple to understand how worst case > burstiness propagates, > even in the absence of non-EF traffic. > I would like to believe that you are making the above comments in the absence of a specification on how the EF aggregate is formed. Also, if micro flows are individually spaced at the ingress then I would like to think that we can bound the burstiness as a function of routers traversed however the splitting and merging occurs provided that the loading resulting at each output remains below the input rate R. Guven. __________________________________________________ Do You Yahoo!? Yahoo! Shopping - Thousands of Stores. Millions of Products. http://shopping.yahoo.com/ _______________________________________________ diffserv mailing list diffserv@ietf.org http://www1.ietf.org/mailman/listinfo/diffserv Archive: http://www2.ietf.org/mail-archive/working-groups/diffserv/current/maillist.html From diffserv-admin@ietf.org Mon Dec 11 20:14: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 SMTP id UAA20226 for ; Mon, 11 Dec 2000 20:14:24 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id TAA21019; Mon, 11 Dec 2000 19:44:06 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id TAA20988 for ; Mon, 11 Dec 2000 19:44:02 -0500 (EST) Received: from mailhub1.almaden.ibm.com (mailhub1.almaden.ibm.com [198.4.83.44]) by ietf.org (8.9.1a/8.9.1a) with SMTP id TAA16362 for ; Mon, 11 Dec 2000 19:44:00 -0500 (EST) Received: from maui.almaden.ibm.com (maui.almaden.ibm.com [9.1.24.92]) by mailhub1.almaden.ibm.com (8.8.8/8.8.8) with ESMTP id QAA17736; Mon, 11 Dec 2000 16:41:11 -0800 Received: from hursley.ibm.com (gsine01.us.sine.ibm.com [9.14.6.41]) by maui.almaden.ibm.com (AIX4.3/8.9.3/8.7) with ESMTP id QAA09710; Mon, 11 Dec 2000 16:43:30 -0800 Message-ID: <3A357475.E21CD62F@hursley.ibm.com> Date: Mon, 11 Dec 2000 18:42:29 -0600 From: Brian E Carpenter Organization: IBM X-Mailer: Mozilla 4.61 [en] (Win98; I) X-Accept-Language: en,fr MIME-Version: 1.0 To: Bora Akyol CC: diffserv@ietf.org Subject: Re: LBE PHB [was: [Diffserv] comments on the bulk handlingdraft] References: <5.0.2.1.0.20001211162022.02836668@localhost> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: diffserv-admin@ietf.org Errors-To: diffserv-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Diffserv Discussion List X-BeenThere: diffserv@ietf.org Content-Transfer-Encoding: 7bit Bora, My personal view is that an edge to edge service is simply an instance of a PDB with the PDB's parameters filled in with specific values. But that is still not an end to end service. See you in the SLS BOF? Brian Bora Akyol wrote: > > Brian > > Despite what was presented today, PDB smells awfully like a service > definition to me. This is fine by me. Does this mean that we finally are > starting to consider the services that the PHBs are designed to support? > > Bora > > At 03:55 PM 12/11/2000, Brian E Carpenter wrote: > >I agree that the draft deserves recognition. The reason Kathie and I > >wrote our draft was because we don't believe there is any reason > >to define a new PHB to support this type of PDB. > > > >As Kathie said today, the LBE name is no better chosen than > >BH. Maybe we should call the new PDB "NCT" for Non-Critical Traffic? > > > > Brian > > > >Simon Leinen wrote: > > > > > > >>>>> "yb" == Yoram Bernet writes: > > > > Another general comment - wasn't just this type of pdb proposed > > > > previously? I think that it was proposed as draft-mumble-lbe-xx. I > > > > can't remember the authors, but - one may have been Roland > > > > Bless. Whoever they were, those authors deserve acknowledgement. > > > > > > Actually it was a PHB, not a PDB, and the draft suggests that it could > > > be used for a variety of different PHBs. > > > > > > Title : A Lower Than Best-Effort Per-Hop Behavior > > > Author(s) : R. Bless, K. Wehrle > > > Filename : draft-bless-diffserv-lbe-phb-00.txt > > > Pages : 9 > > > Date : 08-Sep-99 > > > > > > http://www-nrg.ee.lbl.gov/diff-serv-arch/msg04311.html > > > > > http://www.telematik.informatik.uni-karlsruhe.de/forschung/diffserv/lit/draft-bless-diffserv-lbe-phb-00.txt > > > -- > > > Simon. > > > > > > _______________________________________________ > > > diffserv mailing list > > > diffserv@ietf.org > > > http://www1.ietf.org/mailman/listinfo/diffserv > > > Archive: > > http://www2.ietf.org/mail-archive/working-groups/diffserv/current/maillist.html > > > >_______________________________________________ > >diffserv mailing list > >diffserv@ietf.org > >http://www1.ietf.org/mailman/listinfo/diffserv > >Archive: > >http://www2.ietf.org/mail-archive/working-groups/diffserv/current/maillist.html > > > > Bora Akyol > Pluris > akyol@pluris.com _______________________________________________ diffserv mailing list diffserv@ietf.org http://www1.ietf.org/mailman/listinfo/diffserv Archive: http://www2.ietf.org/mail-archive/working-groups/diffserv/current/maillist.html From diffserv-admin@ietf.org Mon Dec 11 21:33:10 2000 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with SMTP id VAA02109 for ; Mon, 11 Dec 2000 21:33:06 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id VAA22715; Mon, 11 Dec 2000 21:05:36 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id VAA22615 for ; Mon, 11 Dec 2000 21:05:29 -0500 (EST) Received: from mailserver.terawave.com (mailserver.terawave.com [38.168.8.12] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with SMTP id VAA26588 for ; Mon, 11 Dec 2000 21:05:26 -0500 (EST) Received: by mailserver.terawave.com with Internet Mail Service (5.5.2650.21) id ; Mon, 11 Dec 2000 18:07:25 -0800 Message-ID: <5797CFC7D8B8D3119028009027DCDADD705F58@mailserver.terawave.com> From: Justin Fletcher To: "'diffserv@ietf.org '" Cc: "'khchan@nortelnetworks.com '" , Justin Fletcher Date: Mon, 11 Dec 2000 18:07:21 -0800 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C063E0.42DDA520" Subject: [Diffserv] MIB MF classifier Sender: diffserv-admin@ietf.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_01C063E0.42DDA520 Content-Type: text/plain I realize this is late in the process, so my apologies in advance. The model defines a generic MF classifier based on the standard 6-tuple, as exemplified in the model: "A common type of MF classifier is a 6-tuple classifier that classifies based on six fields from the IP and TCP or UDP headers (destination address, source address, IP protocol, source port, destination port, and DSCP)." However, its representation in the MIB is much more specific, limiting fields to a single value or a single range: diffServSixTupleClfrDstAddrType InetAddressType, diffServSixTupleClfrDstAddr InetAddress, diffServSixTupleClfrDstAddrMask Unsigned32, diffServSixTupleClfrSrcAddrType InetAddressType, diffServSixTupleClfrSrcAddr InetAddress, diffServSixTupleClfrSrcAddrMask Unsigned32, diffServSixTupleClfrDscp Dscp, diffServSixTupleClfrProtocol Unsigned32, diffServSixTupleClfrDstL4PortMin SixTupleClfrL4Port, diffServSixTupleClfrDstL4PortMax SixTupleClfrL4Port, diffServSixTupleClfrSrcL4PortMin SixTupleClfrL4Port, diffServSixTupleClfrSrcL4PortMax SixTupleClfrL4Port, With this representation, it is impossible to specify a single classifier entry which matches "protocol TCP or UDP." Can this representation be generalized to permit individual values, a list of values, a range (or value/mask, as appropriate) or a list of ranges? In addition, how is "unspecified" represented for each field? Justin Fletcher jfletcher@terawave.com ------_=_NextPart_001_01C063E0.42DDA520 Content-Type: text/html MIB MF classifier

I realize this is late in the process, so my apologies in advance.

The model defines a generic MF classifier based on the standard 6-tuple,
as exemplified in the model:

"A common type of MF classifier is a 6-tuple classifier that classifies
based on six fields from the IP and TCP or UDP headers (destination
address, source address, IP protocol, source port, destination port, and
DSCP)."

However, its representation in the MIB is much more specific,
limiting fields to a single value or a single range:

    diffServSixTupleClfrDstAddrType  InetAddressType,
    diffServSixTupleClfrDstAddr      InetAddress,
    diffServSixTupleClfrDstAddrMask  Unsigned32,
    diffServSixTupleClfrSrcAddrType  InetAddressType,
    diffServSixTupleClfrSrcAddr      InetAddress,
    diffServSixTupleClfrSrcAddrMask  Unsigned32,
    diffServSixTupleClfrDscp         Dscp,
    diffServSixTupleClfrProtocol     Unsigned32,
    diffServSixTupleClfrDstL4PortMin SixTupleClfrL4Port,
    diffServSixTupleClfrDstL4PortMax SixTupleClfrL4Port,
    diffServSixTupleClfrSrcL4PortMin SixTupleClfrL4Port,
    diffServSixTupleClfrSrcL4PortMax SixTupleClfrL4Port,

With this representation, it is impossible to specify a single
classifier entry which matches "protocol TCP or UDP."

Can this representation be generalized to permit individual
values, a list of values, a range (or value/mask, as appropriate)
or a list of ranges?

In addition, how is "unspecified" represented for each field?

Justin Fletcher
jfletcher@terawave.com

------_=_NextPart_001_01C063E0.42DDA520-- _______________________________________________ diffserv mailing list diffserv@ietf.org http://www1.ietf.org/mailman/listinfo/diffserv Archive: http://www2.ietf.org/mail-archive/working-groups/diffserv/current/maillist.html From diffserv-admin@ietf.org Mon Dec 11 22: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 SMTP id WAA14170 for ; Mon, 11 Dec 2000 22:16:48 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id VAA23157; Mon, 11 Dec 2000 21:42:49 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id VAA23132 for ; Mon, 11 Dec 2000 21:42:45 -0500 (EST) Received: from procyon.pmc-sierra.bc.ca (procyon.pmc-sierra.bc.ca [134.87.115.1]) by ietf.org (8.9.1a/8.9.1a) with SMTP id VAA05652 for ; Mon, 11 Dec 2000 21:42:30 -0500 (EST) Received: from bby1exi01.pmc-sierra.bc.ca (bby1exi01.pmc-sierra.bc.ca [216.241.231.251]) by procyon.pmc-sierra.bc.ca (6.6.6/6.6.6) with ESMTP id SAA11500 for ; Mon, 11 Dec 2000 18:41:55 -0800 (PST) Received: by bby1exi01.pmc-sierra.bc.ca with Internet Mail Service (5.5.2650.21) id ; Mon, 11 Dec 2000 18:42:31 -0800 Message-ID: <9DC5E2ABE65BD54CA9088DA3194461D6010C9AEA@BBY1EXM01> From: Shahram Davari To: "'diffserv@ietf.org'" Date: Mon, 11 Dec 2000 18:42:30 -0800 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: text/plain Subject: [Diffserv] Token bucket suggestion in Diffserv Model draft Sender: diffserv-admin@ietf.org Errors-To: diffserv-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Diffserv Discussion List X-BeenThere: diffserv@ietf.org Hi, Here are the wording suggestions, that was asked in the Diffserv WG meeting today (Monday): 5.2.3. Two-Parameter Token Bucket Meter A more sophisticated meter might measure conformance to a token bucket (TB) profile. A TB profile generally has two parameters, an average token rate and a burst size. TB meters compare the arrival rate of packets to the average rate specified by the TB profile. Logically, tokens accumulate in a bucket at the average rate, up to a maximum credit which is the burst size. Depending on what type of TB is used, packets of length L bytes are considered conforming if 1) Either any tokens are available in the bucket at the time of packet arrival: up to L bytes may then be borrowed from future token allocations. This is called a "negative-count" TB. 2) Or, if the number of tokens in the bucket is more than or equal to the size of the packet at the time of the packet arrival: no bytes are borrowed from future token allocations. This is called a "positive-count" TB. Packets are allowed to exceed the average rate in bursts up to the burst size. Packets which arrive to find a bucket with no tokens in it are deemed non-conforming. A two-parameter TB meter has exactly two possible conformance levels (conforming, non-conforming). TB implementation details are discussed in Appendix A. A two-parameter TB meter might appear as follows: Meter3: Type: NegativeTokenBucket Profile: Profile3 ConformingOutput: Queue1 NonConformingOutput: AbsoluteDropper1 Profile3: Type: SimpleTokenBucket AverageRate: 200 kbps BurstSize: 100 kbytes 12. Appendix A. Simple Token Bucket Discussion and Definition Internet Protocol (IP) packets are of variable-length but theoretical token buckets operate using fixed-length time intervals or pieces of data. This leaves an implementor of a token bucket scheme with a dilemma, of what kind of TB to use. Essentially three type of TB can be used, which differ in how a packet is processed when the amount of bandwidth tokens, TB, left in the token bucket is positive but less than the size of the packet being operated on. (1) Assuming a TB of size B and rate R, the whole size of the packet can be subtracted from the bucket, leaving it negative, remembering that the token bucket size must be added to TB rather than simply setting it "full". This potentially puts more than the token bucket size into this token bucket interval and less into the next. It does, however, make the average amount accepted per token bucket interval equal to the token burst. This approach accepts traffic if any bit in the packet would be accepted and borrows up to one MTU of capacity from one or more subsequent intervals when necessary. Such a token bucket implementation is said to be a "negative-count" token bucket. (2) Alternatively if we use a TB of size B+MTU and rate R, the amount can be left unchanged (and maybe an attempt could be made to accept the packet under another threshold in another bucket). This potentially puts less than the token bucket size into this token bucket interval and more into the next. Like the first option, it makes the average amount accepted per token bucket interval equal to the token burst. This approach accepts traffic if every bit in the packet would be accepted and borrows up to one MTU of capacity from one or more previous intervals when necessary. Such a token bucket implementation is said to be a "positive-count" token bucket. (3) The TB variable can be set to zero to account for the first part of the packet and the remainder of the packet size can be taken out of the next-colored bucket. This, of course, has another bug: the same packet cannot have both conforming and nonconforming components in the Diffserv architecture and so is not really appropriate here. Unfortunately, the thing that cannot be done is exactly to fit the token burst specification with random sized packets: therefore token buckets in a variable length packet environment always have a some variance from theoretical reality. This has also been observed in the ATM Guaranteed Frame Rate (GFR) service category specification and Frame Relay. Positive-count TB is commonly used in ATM and Frame Relay. However, the positive-count TB approach has some characteristics which are important to keep in mind: (1) The maximum TB burst must be greater than the MTU, otherwise it is possible that traffic never matches the specification. As an example suppose that the maximum burst size is exactly the size of the packets being sent. In such a case, when one packet has been accepted, the token depth becomes zero, and starts to accumulate. If the next packet is received any time earlier than a token interval later, it will not be accepted. If the next packet arrives exactly on time, it will be accepted and the token depth again set to zero. If it arrives later, however, the token depth will stop accumulating, as it is capped by the maximum burst size, and tokens that would have accumulated between the end of that token interval and the actual arrival of the packet are lost. As a result, natural jitter in the network conspires against the algorithm to reduce the actual acceptance rate. However, this problem can be overcome by setting the maximum token buc! ke! t size to be greater than the MTU to absorb the jitter. (2) Operationally, a positive-count token bucket is reasonable for traffic which has been shaped by a leaky bucket shaper or a serial line. However, traffic in the Internet is rarely shaped in that way. TCP applies no shaping to its traffic, but rather depends on longer-range Ack Clocking behavior to help it approximate a certain rate and explicitly sends traffic bursts during slow start, retransmission and fast recovery. Video-on-IP implementations such as [VIC] may have a leaky bucket shaper available to them, but often do not, and simply enqueue the output of their codec for transmission on the appropriate interface. As a result a positive-count TB may reject traffic in the short term (single token interval),which it would have accepted if it had a longer time in view and which it needs to accept for the application to work properly. To work around this, the token interval (B/R) must approximate or exceed the RTT of the session or sessions in question and the burst size must accommodate the largest burst that the originator might send. In other words in the absence of shaping, the max. burst size of the positive-count TB must be set to a large value to accept the incoming bursts. A negative count TB has also some characteristics which are important to keep in mind. (1) The negative-count TB does not accept packets, while the TB count is negative. This means that when a large packet has borrowed token form future, if we receive even a small packet such as 40-byte TCP ACK/SYN packets, they will not be accepted by the TB. (2) A negative-count TB has granularity problem. This means that even if we set the TB depth to 1-bit, the maximum burst size that can pass through the TB can't be smaller than MTU (this behavior is essentially equivalent to positive-count TB, in which the TB depth must be set to a larger value than MTU). Another consequence is that if one restricts the maximum TB burst to MTU, then the TB depth must be set to 1-bit. By doing so And if you do that you can't basically accept any back to back packets at all, no matter how small they are. (3) Similar to positive-count TB, a negative-count token bucket is reasonable for traffic which has been shaped by a leaky bucket shaper or a serial line. As a result a negative-count TB may reject traffic in the short term (single token interval), which it would have accepted if it had a longer time in view and which it needs to accept for the application to work properly. To work around this, the token interval (B/R) must approximate or exceed the RTT of the session or sessions in question and the burst size must accommodate the largest burst that the originator might send. In other words in the absence of shaping, the max. burst size of the negative-count TB must be set to a large value to accept the incoming bursts. In summary the positive-count TB favors more the small packets, while the negative-count TB favors more the large packets. Each one might be useful in various scenarios. Yours, Shahram Davari Systems Engineer Product Research Group PMC-Sierra, Inc. (Ottawa) Phone: (613) 271-4018 Fax: (613) 271-7007 _______________________________________________ diffserv mailing list diffserv@ietf.org http://www1.ietf.org/mailman/listinfo/diffserv Archive: http://www2.ietf.org/mail-archive/working-groups/diffserv/current/maillist.html From diffserv-admin@ietf.org Mon Dec 11 23:26:08 2000 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with SMTP id XAA28593 for ; Mon, 11 Dec 2000 23:26:08 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id XAA24110; Mon, 11 Dec 2000 23:02:08 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id XAA24079 for ; Mon, 11 Dec 2000 23:02:04 -0500 (EST) Received: from mailhub1.almaden.ibm.com (mailhub1.almaden.ibm.com [198.4.83.44]) by ietf.org (8.9.1a/8.9.1a) with SMTP id XAA23624 for ; Mon, 11 Dec 2000 23:02:01 -0500 (EST) Received: from maui.almaden.ibm.com (maui.almaden.ibm.com [9.1.24.92]) by mailhub1.almaden.ibm.com (8.8.8/8.8.8) with ESMTP id TAA28104 for ; Mon, 11 Dec 2000 19:59:10 -0800 Received: from hursley.ibm.com (gsine02.us.sine.ibm.com [9.14.6.42]) by maui.almaden.ibm.com (AIX4.3/8.9.3/8.7) with ESMTP id UAA22386 for ; Mon, 11 Dec 2000 20:01:31 -0800 Message-ID: <3A35A2E1.7497AD08@hursley.ibm.com> Date: Mon, 11 Dec 2000 22:00:33 -0600 From: Brian E Carpenter Organization: IBM X-Mailer: Mozilla 4.61 [en] (Win98; I) X-Accept-Language: en,fr MIME-Version: 1.0 To: "'diffserv@ietf.org'" Subject: Re: [Diffserv] Token bucket suggestion in Diffserv Model draft References: <9DC5E2ABE65BD54CA9088DA3194461D6010C9AEA@BBY1EXM01> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: diffserv-admin@ietf.org Errors-To: diffserv-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Diffserv Discussion List X-BeenThere: diffserv@ietf.org Content-Transfer-Encoding: 7bit Shahram, Thanks for all the suggested text. I will leave the document editor to decide how much of it he adopts - I hadn't expected so much change from today's discussion. As for the terminology change from "strict/loose" to "positive-count/negative-count", we would need a consensus for that. WG comments are welcome. Thanks Brian _______________________________________________ diffserv mailing list diffserv@ietf.org http://www1.ietf.org/mailman/listinfo/diffserv Archive: http://www2.ietf.org/mail-archive/working-groups/diffserv/current/maillist.html From diffserv-admin@ietf.org Tue Dec 12 00:07: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 SMTP id AAA07952 for ; Tue, 12 Dec 2000 00:07:13 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id XAA24633; Mon, 11 Dec 2000 23:36:24 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id XAA24601 for ; Mon, 11 Dec 2000 23:36:15 -0500 (EST) Received: from hoemail2.firewall.lucent.com (hoemail2.lucent.com [192.11.226.163]) by ietf.org (8.9.1a/8.9.1a) with SMTP id XAA01567 for ; Mon, 11 Dec 2000 23:36:12 -0500 (EST) Received: from hoemail2.firewall.lucent.com (localhost [127.0.0.1]) by hoemail2.firewall.lucent.com (Pro-8.9.3/8.9.3) with ESMTP id XAA06388 for ; Mon, 11 Dec 2000 23:36:13 -0500 (EST) Received: from nl0006exch001h.wins.lucent.com (h135-85-76-62.lucent.com [135.85.76.62]) by hoemail2.firewall.lucent.com (Pro-8.9.3/8.9.3) with ESMTP id XAA06376 for ; Mon, 11 Dec 2000 23:36:13 -0500 (EST) Received: by nl0006exch001h.nl.lucent.com with Internet Mail Service (5.5.2650.21) id ; Tue, 12 Dec 2000 05:36:07 +0100 Message-ID: <2413FED0DFE6D111B3F90008C7FA61FB0A671168@nl0006exch002u.nl.lucent.com> From: "Wijnen, Bert (Bert)" To: Kwok-Ho Chan Cc: diffserv@ietf.org Date: Tue, 12 Dec 2000 05:35:56 +0100 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: text/plain Subject: [Diffserv] Diffserv MIB - Dscp TC Sender: diffserv-admin@ietf.org Errors-To: diffserv-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Diffserv Discussion List X-BeenThere: diffserv@ietf.org One more comment on rev 06 The TC: Dscp ::= TEXTUAL-CONVENTION DISPLAY-HINT "d" STATUS current DESCRIPTION "The IP header Diffserv Code-Point that may be used for discriminating or marking a traffic stream. The value -1 ( 4294967295 for Integer32 ) is used to indicate a wildcard i.e. any value." SYNTAX Integer32 (4294967295 | 0..63) Needs change I think. An Interger32 is a signed value, and you are trying to put the largest Unsigned32 value in this Integer to mean -1. That is not valid. Either your base type should be Unsigned32 (in which case you cannot speak about -1 any more). Or you should just specift -1. So: SYNTAX Integer32 (-1 | 0..63) I think the latter is the best way to go. Or maybe you might want two TCs, a Dscp with values 0..63 and another TC(say DscpValueOrAny) which would be 0..63 plus -1 and -1 would mean any Dscp value. This would be similar to how we defined InterfaceIndex (which can only contain a VALID IfIndex) and InterfaceIndexOrZero. Bert _______________________________________________ diffserv mailing list diffserv@ietf.org http://www1.ietf.org/mailman/listinfo/diffserv Archive: http://www2.ietf.org/mail-archive/working-groups/diffserv/current/maillist.html From diffserv-admin@ietf.org Tue Dec 12 00:11: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 SMTP id AAA09077 for ; Tue, 12 Dec 2000 00:11:34 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id XAA24812; Mon, 11 Dec 2000 23:50:07 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id XAA24783 for ; Mon, 11 Dec 2000 23:50:03 -0500 (EST) 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 XAA04757 for ; Mon, 11 Dec 2000 23:49:59 -0500 (EST) Received: from scummy.research.bell-labs.com ([135.104.2.10]) by dirty; Mon Dec 11 23:49:21 EST 2000 Received: from mail1.pa.bell-labs.com ([135.250.8.11]) by scummy; Mon Dec 11 23:49:20 EST 2000 Received: from research.bell-labs.com (ex-vpn64.pa.bell-labs.com [135.250.1.64]) by mail1.pa.bell-labs.com (Mirapoint) with ESMTP id AAW16403 (AUTH gja); Mon, 11 Dec 2000 20:49:17 -0800 (PST) Message-ID: <3A35AE9A.737447BA@research.bell-labs.com> Date: Mon, 11 Dec 2000 20:50:34 -0800 From: Grenville Armitage Organization: Bell Labs Research Silicon Valley X-Mailer: Mozilla 4.61 [en] (WinNT; U) X-Accept-Language: en MIME-Version: 1.0 To: Anna Charny CC: diffserv@ietf.org Subject: Traffic matrices Re: [Diffserv] Possible compromise between EFRESOLVE anddraft-ch arny References: <4.3.2.7.2.20001211173704.00c6c3e0@pilgrim.cisco.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: diffserv-admin@ietf.org Errors-To: diffserv-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Diffserv Discussion List X-BeenThere: diffserv@ietf.org Content-Transfer-Encoding: 7bit Anna Charny wrote: [..] > Now, maybe it might be possible to solve this problem by specifying > different combinations of R's and S's for different traffic matrices. Yes (including burst tolerances), that is the intention. cheers, gja _______________________________________________ diffserv mailing list diffserv@ietf.org http://www1.ietf.org/mailman/listinfo/diffserv Archive: http://www2.ietf.org/mail-archive/working-groups/diffserv/current/maillist.html From diffserv-admin@ietf.org Tue Dec 12 00:55:28 2000 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with SMTP id AAA20621 for ; Tue, 12 Dec 2000 00:55:28 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id AAA25716; Tue, 12 Dec 2000 00:34:08 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id AAA25677 for ; Tue, 12 Dec 2000 00:34:03 -0500 (EST) Received: from lisanza.net (ietf.207.137.74.155.tx.verio.net [207.137.74.155]) by ietf.org (8.9.1a/8.9.1a) with SMTP id AAA15246; Tue, 12 Dec 2000 00:34:01 -0500 (EST) Received: from covalent.net (localhost [127.0.0.1]) by lisanza.net (8.9.3/8.9.3) with ESMTP id NAA01266; Mon, 11 Dec 2000 13:32:44 -0800 (PST) (envelope-from harrie@covalent.net) Message-ID: <3A3547FC.8E393EBD@covalent.net> Date: Mon, 11 Dec 2000 13:32:44 -0800 From: Harrie Hazewinkel Organization: Covalent Technologies X-Mailer: Mozilla 4.73 [en] (X11; I; FreeBSD 4.1-RELEASE i386) X-Accept-Language: en MIME-Version: 1.0 To: rmonmib@ietf.org, diffserv@ietf.org Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Subject: [Diffserv] The DsCodePoint definition Sender: diffserv-admin@ietf.org Errors-To: diffserv-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Diffserv Discussion List X-BeenThere: diffserv@ietf.org Content-Transfer-Encoding: 7bit HI, I was wondering why there is a difference between 2 definitions of the DiffServ CodePoint in different MIB modules. The two different MIMB modules are the DIFFSERV-MIB (of diffserv) and the DSMON-MIB (of RMON). I beleive these 2 TCs should be the same and taken from the DIFFSERV-MIB, because that is from the diffserv WG. ----------- From the DIFFSERV-MIB (draft 05) ----------------- Dscp ::= TEXTUAL-CONVENTION DISPLAY-HINT "d" STATUS current DESCRIPTION "The IP header Diffserv Code-Point that may be used for discriminating or marking a traffic stream. The value -1 ( 4294967295 for Integer32 ) is used to indicate a wildcard i.e. any value." SYNTAX Integer32 (4294967295 | 0..63) -------------------------------------------------------------- ------------ From the DSMON-MIB (draft 03) ------------------- DsmonDSCodePoint ::= TEXTUAL-CONVENTION STATUS current DESCRIPTION "This TC describes an object which identifies the Differentiated Services Codepoint (DSCP) value found within the DS field in a network layer packet header (e.g., IPv4 and IPv6)." REFERENCE "Definition of the Differentiated Services Field (DS Field) in the IPv4 and IPv6 Headers [RFC2474]." SYNTAX Integer32 (0..63) -------------------------------------------------------------- OK, I will admit the definition of the DiffServ-MIB is currently broken, but that will be fixed (this week at the IETF, I hope). Harrie _______________________________________________ diffserv mailing list diffserv@ietf.org http://www1.ietf.org/mailman/listinfo/diffserv Archive: http://www2.ietf.org/mail-archive/working-groups/diffserv/current/maillist.html From diffserv-admin@ietf.org Tue Dec 12 01:35: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 SMTP id BAA01202 for ; Tue, 12 Dec 2000 01:35:07 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id BAA00924; Tue, 12 Dec 2000 01:09:11 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id BAA00801 for ; Tue, 12 Dec 2000 01:09:03 -0500 (EST) Received: from pilgrim.cisco.com (pilgrim.cisco.com [171.69.204.12]) by ietf.org (8.9.1a/8.9.1a) with SMTP id BAA23912 for ; Tue, 12 Dec 2000 01:09:03 -0500 (EST) Received: from acharny-nt.cisco.com (sj-dial-3-171.cisco.com [171.68.180.172]) by pilgrim.cisco.com (8.8.8-Cisco List Logging/8.8.8) with ESMTP id BAA18608; Tue, 12 Dec 2000 01:07:56 -0500 (EST) Message-Id: <4.3.2.7.2.20001212005109.00c8add0@pilgrim.cisco.com> X-Sender: acharny@pilgrim.cisco.com X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Tue, 12 Dec 2000 01:13:37 -0500 To: g_mercankosk@yahoo.com, ROBERTS James FTRD/DAC/ISS , "'Joel M. Halpern'" , diffserv@ietf.org From: Anna Charny Subject: RE: [Diffserv] Possible compromise between EFRESOLVE and draft-ch arny Cc: guven@ee.uwa.edu.au In-Reply-To: <20001212004300.15215.qmail@web4206.mail.yahoo.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 Guven, At 04:43 PM 12/11/00 -0800, g_mercankosk@yahoo.com wrote: >Also, if micro flows are individually spaced at the >ingress then I would like to think that we can bound >the burstiness as a function of routers traversed >however the splitting and merging occurs provided that >the loading resulting at each output remains below the >input rate R. > >Guven. To the best of my knowledge as of today it is not known how to deterministically limit burstiness even for ideally shaped microflows in a general network with aggregate scheduling (unless severe constraints on EF utilization, or complicated constraints of the rates and the number of merges and splits of different "ef flows" are imposed). Neither it is known (at least to me) how to describe a useful range of topologies for which such bound can be found. Hence, I am afraid you may be overly optimistic in your statement. However, if you are aware of any results that shed more light on this problem, I would be very interested in learning what they are. Anna > > >__________________________________________________ >Do You Yahoo!? >Yahoo! Shopping - Thousands of Stores. Millions of Products. >http://shopping.yahoo.com/ > >_______________________________________________ >diffserv mailing list >diffserv@ietf.org >http://www1.ietf.org/mailman/listinfo/diffserv >Archive: >http://www2.ietf.org/mail-archive/working-groups/diffserv/current/maillist.html --------------------------------------- Anna Charny Cisco Systems, Inc 300 Apollo Drive Chelmsford, MA 01824 Tel. (978)-244-8172 Fax (978)-244-8126 _______________________________________________ diffserv mailing list diffserv@ietf.org http://www1.ietf.org/mailman/listinfo/diffserv Archive: http://www2.ietf.org/mail-archive/working-groups/diffserv/current/maillist.html From diffserv-admin@ietf.org Tue Dec 12 01:43:14 2000 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with SMTP id BAA04652 for ; Tue, 12 Dec 2000 01:43:14 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id BAA02328; Tue, 12 Dec 2000 01:23:26 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id BAA02292 for ; Tue, 12 Dec 2000 01:23:20 -0500 (EST) Received: from pilgrim.cisco.com (pilgrim.cisco.com [171.69.204.12]) by ietf.org (8.9.1a/8.9.1a) with SMTP id BAA28096 for ; Tue, 12 Dec 2000 01:23:20 -0500 (EST) Received: from acharny-nt.cisco.com (sj-dial-3-171.cisco.com [171.68.180.172]) by pilgrim.cisco.com (8.8.8-Cisco List Logging/8.8.8) with ESMTP id BAA19232; Tue, 12 Dec 2000 01:22:46 -0500 (EST) Message-Id: <4.3.2.7.2.20001212004406.00bf5340@pilgrim.cisco.com> X-Sender: acharny@pilgrim.cisco.com X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Tue, 12 Dec 2000 01:28:26 -0500 To: Brian E Carpenter From: Anna Charny Subject: Re: [Diffserv] Possible compromise between EFRESOLVE anddraft-ch arny Cc: diffserv@ietf.org In-Reply-To: <3A357168.11AEB189@hursley.ibm.com> References: <4.3.2.7.2.20001211173704.00c6c3e0@pilgrim.cisco.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: diffserv-admin@ietf.org Errors-To: diffserv-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Diffserv Discussion List X-BeenThere: diffserv@ietf.org Brian, At 06:29 PM 12/11/00 -0600, you wrote: >Anna Charny wrote: >... > > I think Bill may have answered this question, but let me give my > > answer. Consider an ideal output buffered device with 1000 ports, all > > links being the same speed. Suppose that 1/5000 of traffic from each input > > goes to each output (that is, all links in the router is exactly 50% booked > > with EF traffic). Suppose every output implements a strict priority > > queue. An ideal output buffered device with a PQ at each output seems to > > me as close to an ideal device as we can get for EF support. Suppose now a > > single packet destined for the same output j arrives at the same time to > > each one of 1000 inputs. Would you agree that S has to be at least > > 999? Now, let's go one step further and assume that we actually allow B > > back-to-back packet burst at each input. Do you agree that S must be at > > least 999 times B? > >Isn't it the case that this (the fact that the queue will instantaneously >contain at least 999 or 999B packets) is a truism whatever scheduler and >EF definition is in use? I think it is perfectly fine for a scheduler or a device to cope with simultaneous arrivals, and you are most certainly right that every device must deal with it. And in fact every reasonable device does. But the example I gave was in response to Bert saying: >If some non-FIFO schedulers will result in large values of S, seems to me >that those schedulers are simply not ideal for EF use. Why is this an issue? I gave an example of an ideal (large) output buffered device with PQ at the output, which gave a large value of S. Since I doubt that it is reasonable to say that large ideal output-buffered routers with a PQ at the output are bad for EF, I belive my example indicates that is is NOT true that devices with large S "are simply not ideal for EF use". Anna Anna > Brian --------------------------------------- Anna Charny Cisco Systems, Inc 300 Apollo Drive Chelmsford, MA 01824 Tel. (978)-244-8172 Fax (978)-244-8126 _______________________________________________ diffserv mailing list diffserv@ietf.org http://www1.ietf.org/mailman/listinfo/diffserv Archive: http://www2.ietf.org/mail-archive/working-groups/diffserv/current/maillist.html From diffserv-admin@ietf.org Tue Dec 12 04:17:23 2000 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with SMTP id EAA25439 for ; Tue, 12 Dec 2000 04:17:18 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id DAA03974; Tue, 12 Dec 2000 03:36:05 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id DAA03943 for ; Tue, 12 Dec 2000 03:36:01 -0500 (EST) Received: from iraun1.ira.uka.de (iraun1.ira.uka.de [129.13.10.90]) by ietf.org (8.9.1a/8.9.1a) with SMTP id DAA19858 for ; Tue, 12 Dec 2000 03:35:59 -0500 (EST) Received: from blackfoot.telematik.informatik.uni-karlsruhe.de by iraun1 (PP) with ESMTP; Tue, 12 Dec 2000 09:35:04 +0100 Received: from tpce10.telematik.informatik.uni-karlsruhe.de (root@tpce10.telematik.informatik.uni-karlsruhe.de [129.13.41.110]) by blackfoot.telematik.informatik.uni-karlsruhe.de (8.9.3/8.9.3) with ESMTP id JAA02515; Tue, 12 Dec 2000 09:35:03 +0100 (MET) Received: from mailhost (bless@tpce10.telematik.informatik.uni-karlsruhe.de [129.13.41.110]) by tpce10.telematik.informatik.uni-karlsruhe.de (8.9.3/8.9.3) with ESMTP id JAA17342; Tue, 12 Dec 2000 09:35:02 +0100 Message-Id: <200012120835.JAA17342@tpce10.telematik.informatik.uni-karlsruhe.de> X-Mailer: exmh version 2.1.1 10/15/1999 To: Yoram Bernet cc: diffserv@ietf.org Subject: Re: [Diffserv] comments on the bulk handling draft In-Reply-To: Message from "Yoram Bernet" of "Mon, 11 Dec 2000 10:43:56 PST." Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Tue, 12 Dec 2000 09:35:02 +0100 From: Roland Bless Sender: diffserv-admin@ietf.org Errors-To: diffserv-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Diffserv Discussion List X-BeenThere: diffserv@ietf.org See comments below. yoramb@Exchange.Microsoft.com said: > For example - 'transfer all accounting records from new york to london > each night' can be considered a bulk handling task, yet would likely > not be happy with what is effectively, less than best-effort (LBE) > service. In addition, I see one of the primary applications of the bh > pdb in the incremental deployment of aggressive multimedia > applications (that use non-adaptive UDP). IT managers are reluctant to > deploy (for example) streaming media over wan links because they > cannot control the impact of these apps on the wan link resources. One > way in which we might see these more likely to be deployed is if some > controlled amount of the multimedia traffic could be given > priopritized service (appropriate for the media), but any amount > beyond this would be relegated to the bh pdb (to prevent it from > seizing network resources required for best-effort. Based on these > considerations - I would rather this pdb be called the LBE (less than > best effort pdb) rather than the bh pdb - I think is is a much more > descriptive name. > Another general comment - wasn't just this type of pdb proposed > previously? I think that it was proposed as draft-mumble-lbe-xx. I > can't remember the authors, but - one may have been Roland Bless. > Whoever they were, those authors deserve acknowledgement. Yes, it was draft-bless-diffserv-phb-lbe-00.txt by Klaus Wehrle and me. We're just rewriting the draft and are going to resubmit it. However, we decided to change the name to "Limited Effort" (LE) PHB due to the fact that it's nearly the same behavior as best-effort, but compared to the default PHB, it uses resources only up to a defined limit in case of congestion. There is a very important difference between LE and the proposed BH behavior: while our definition requires a non-starvation guarantee for the LE BA, BH PDB does not. Moreover, I see LE and BH as PHBs, because no traffic conditioning mechanisms are required, no attributes can be specified and no really predictable behavior can be given from ingress to egress of a DS domain. However, this PHB can be implemented by using already existing other PHB _implementations_ like AF (AF is a very generic PHB). > As for specific comments: 1. Throughout, change 'bulk handling' to > 'less-than-best-effort'. 2. In the 'Applicability' section - describe We propose limited effort. > deployable only if they are willing to take what is available. This > means that on networks that are frequently congested, they may not get > much - but then - that's what this pdb is all about. Basically - I > think that this should be a warning to this effect, rather than a > suggestion that the behaviour canot be used on congested networks. 4. Our definition requires a non-starvation guarantee, therefore it would be useful even and particularly during congestion. On the other hand LE traffic can be preempted by best effort traffic, but only down to a configured limit. > I object to the following rules in section 3.1: The network edge must > include a classifier that selects the appropriate BH target group of > packets out of all arriving packets and steers them to a marker which > sets the appropriate DSCP to select a PHB configured as described in > the next section. Why? In many cases, the customer may chose to > premark packets for this pdb. In that case, why would the ingress need > to classify beyond recognizing the dscp? No MF classification is Correct. > required. No marking is required. Rather, it is optional. In fact - I > think that this rule should be clairified for all pdbs, probably in > the pdb specification draft itself. There are many complexities in > requiring the ingress node of a diffserv domain to classify or mark > (consider the case of encrypted packets). Classification and marking > (beyond the dscp) should be optional for all pdbs.. 5. Wrt 3.2, last > paragraph - the use of 'CS1' as the DSCP for this pdb is also > appealing in its consistency with the interpretaion of 802.1p > user_prioritiy codepoints. In that usage, a codepoint of 1 is also > lesser than a codepoint of 0. That was mentioned in the BH PDB draft. Regards, Roland -- Roland Bless -- e-Mail: bless@telematik.informatik.uni-karlsruhe.de Institute of Telematics, University of Karlsruhe, F.R. of Germany Zirkel 2, D-76128 Karlsruhe -- Office: Engesserstr.2 (Bld. 20.50), 1st floor Phone: +49 721 608-6396 Fax: +49 721 388097 _______________________________________________ diffserv mailing list diffserv@ietf.org http://www1.ietf.org/mailman/listinfo/diffserv Archive: http://www2.ietf.org/mail-archive/working-groups/diffserv/current/maillist.html From diffserv-admin@ietf.org Tue Dec 12 05:04: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 SMTP id FAA00831 for ; Tue, 12 Dec 2000 05:04:14 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id EAA04618; Tue, 12 Dec 2000 04:41:45 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id EAA04589 for ; Tue, 12 Dec 2000 04:41:40 -0500 (EST) Received: from p-mail2.cnet.fr (p-mail2.rd.francetelecom.fr [193.49.124.32]) by ietf.org (8.9.1a/8.9.1a) with SMTP id EAA28189 for ; Tue, 12 Dec 2000 04:41:37 -0500 (EST) Received: by p-voyageur.issy.cnet.fr with Internet Mail Service (5.5.2650.21) id ; Tue, 12 Dec 2000 10:40:13 +0100 Message-ID: <91A311FF6A85D3118DDF0060080C3D82B7DAAE@lat3721.lannion.cnet.fr> From: GARBISU Jean-Pierre FTRD/DMI/CAE To: "'Brian E Carpenter'" , Simon Leinen Cc: Yoram Bernet , diffserv@ietf.org Subject: RE: LBE PHB [was: [Diffserv] comments on the bulk handling draft] Date: Tue, 12 Dec 2000 10:38:23 +0100 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: text/plain; charset="iso-8859-1" X-MIME-Autoconverted: from quoted-printable to 8bit by optimus.ietf.org id EAA04590 Sender: diffserv-admin@ietf.org Errors-To: diffserv-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Diffserv Discussion List X-BeenThere: diffserv@ietf.org X-MIME-Autoconverted: from 8bit to quoted-printable by optimus.ietf.org id EAA04618 Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by ietf.org id FAA00831 "in the litterature" critical traffic is very often referring to ERP and transactional oriented application non-critical is very often referring to best effort or any kind of AF-like gradation between best effort and critical (e.g non critical enterprise trafic somewhere between main public best effort and enterprise critical) so I wouldn't support this NCT (many possible confusions) imho LBE was very explicit (and has already been quite often adopted, without dilemma : see e.g. QBone) perhaps even more explicit than LE, as newly suggested by R.Bless what will be the recommended precedence : 1 ? jeanpierre.garbisu@francetelecom.fr -----Message d'origine----- De : Brian E Carpenter [mailto:brian@hursley.ibm.com] Envoyé : mardi 12 décembre 2000 00:56 À : Simon Leinen Cc : Yoram Bernet; diffserv@ietf.org Objet : Re: LBE PHB [was: [Diffserv] comments on the bulk handling draft] I agree that the draft deserves recognition. The reason Kathie and I wrote our draft was because we don't believe there is any reason to define a new PHB to support this type of PDB. As Kathie said today, the LBE name is no better chosen than BH. Maybe we should call the new PDB "NCT" for Non-Critical Traffic? Brian _______________________________________________ diffserv mailing list diffserv@ietf.org http://www1.ietf.org/mailman/listinfo/diffserv Archive: http://www2.ietf.org/mail-archive/working-groups/diffserv/current/maillist.html From diffserv-admin@ietf.org Tue Dec 12 05:04:57 2000 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with SMTP id FAA00923 for ; Tue, 12 Dec 2000 05:04:57 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id EAA04680; Tue, 12 Dec 2000 04:44:10 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id EAA04655 for ; Tue, 12 Dec 2000 04:44:06 -0500 (EST) Received: from p-mail2.cnet.fr (p-mail2.rd.francetelecom.fr [193.49.124.32]) by ietf.org (8.9.1a/8.9.1a) with SMTP id EAA28502 for ; Tue, 12 Dec 2000 04:44:03 -0500 (EST) Received: by p-voyageur.issy.cnet.fr with Internet Mail Service (5.5.2650.21) id ; Tue, 12 Dec 2000 10:43:17 +0100 Message-ID: <98388C05D464D111B61800805F15041601418A5E@p-ibis.issy.cnet.fr> From: ROBERTS James FTRD/DAC/ISS To: "'g_mercankosk@yahoo.com'" , diffserv@ietf.org Cc: guven@ee.uwa.edu.au Subject: RE: [Diffserv] Possible compromise between EFRESOLVE and draft-ch arny Date: Tue, 12 Dec 2000 10:43:16 +0100 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: text/plain; charset="iso-8859-1" Sender: diffserv-admin@ietf.org Errors-To: diffserv-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Diffserv Discussion List X-BeenThere: diffserv@ietf.org Guven, > > It really is not simple to understand how worst case > > burstiness propagates, > > even in the absence of non-EF traffic. > > > > I would like to believe that you are making the above > comments in the absence of a specification on how the > EF aggregate is formed. > > Also, if micro flows are individually spaced at the > ingress then I would like to think that we can bound > the burstiness as a function of routers traversed > however the splitting and merging occurs provided that > the loading resulting at each output remains below the > input rate R. > I was referring to the calculation of worst case burstiness necessary to define deterministic bounds. Rereading your draft from July, I imagine you are thinking more in terms of probabilistic bounds, eg, the probability end to end delay is greater some bound D should not exceed epsilon. I would certainly agree that this is a more satisfactory approach. However, even here, I don't think it is possible to characterize burstiness at interfaces within the network. At least not in terms of maximally sized bursts or an envelope arrival function like that defined by a token bucket. This was a problem considered in the context of ATM where CBR connections are characterized in terms of the GCRA (almost a token bucket). I am not aware of any work successfully explaining how the GCRA parameters should evolve as the CBR stream acquires burstiness along its path through the network. This is an unsolved problem. In your draft, if my interpretation is correct, you assume the acquired burstiness is negligible in the sense that you can assume (M+D)/D/1 queuing at any node to derive the statistical delay bound. In this way you do not need to characterize burstiness in a quantifiable way. I am inclined to agree with you and we have some work which claims more or less the same thing. To justify your probabilistic arguments you assume first that the EF aggregates only interfere with each other in FIFO queues. You then consider the impact of non-EF packets assuming priority queuing. It seems to me therefore that you should be agreeing with me that an EF PHB definition allowing a clear expression of these assumptions is preferable to one which relies on an unspecified characterization of burstiness in order to justify deterministic bounds. Jim _______________________________________________ diffserv mailing list diffserv@ietf.org http://www1.ietf.org/mailman/listinfo/diffserv Archive: http://www2.ietf.org/mail-archive/working-groups/diffserv/current/maillist.html From diffserv-admin@ietf.org Tue Dec 12 05:19: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 SMTP id FAA02595 for ; Tue, 12 Dec 2000 05:19:36 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id EAA04852; Tue, 12 Dec 2000 04:58:21 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id EAA04824 for ; Tue, 12 Dec 2000 04:58:17 -0500 (EST) Received: from p-mail1.cnet.fr (p-mail1.rd.francetelecom.fr [193.49.124.31]) by ietf.org (8.9.1a/8.9.1a) with SMTP id EAA00094 for ; Tue, 12 Dec 2000 04:58:14 -0500 (EST) Received: by p-biset.issy.cnet.fr with Internet Mail Service (5.5.2650.21) id ; Tue, 12 Dec 2000 10:56:03 +0100 Message-ID: <98388C05D464D111B61800805F15041601418A60@p-ibis.issy.cnet.fr> From: ROBERTS James FTRD/DAC/ISS To: "'Manfredi, Albert E'" , diffserv@ietf.org Subject: RE: [Diffserv] Possible compromise between EFRESOLVE and draft-ch arny Date: Tue, 12 Dec 2000 10:56:02 +0100 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: text/plain; charset="iso-8859-1" Sender: diffserv-admin@ietf.org Errors-To: diffserv-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Diffserv Discussion List X-BeenThere: diffserv@ietf.org > > And if the burstines of the aggregate leaving the router you > > consider is > > bounded, what about the burstiness of the particular EF pipes > > splitting out > > from that aggregate at the next router? And the burstiness of > > the output > > from that router? And so on? There is an exponential increase > > in burstiness. > > True. That's why some on this list have been suggesting that > shapers might > be required in the core of DS nets. > Exactly what would you shape? If you shape the whole aggregate on an incoming interface to a configured rate, you typically add more burstiness to the component sub-aggregates going to the different outgoing interfaces. It is the latter burstiness which needs to be accounted for in calculating the delay bounds. To shape the sub-aggregates individually seems to be contrary to the Diffserv principles. Jim _______________________________________________ diffserv mailing list diffserv@ietf.org http://www1.ietf.org/mailman/listinfo/diffserv Archive: http://www2.ietf.org/mail-archive/working-groups/diffserv/current/maillist.html From diffserv-admin@ietf.org Tue Dec 12 05:21: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 SMTP id FAA02809 for ; Tue, 12 Dec 2000 05:21:27 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id FAA05106; Tue, 12 Dec 2000 05:01:39 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id FAA05006 for ; Tue, 12 Dec 2000 05:01:31 -0500 (EST) Received: from iraun1.ira.uka.de (iraun1.ira.uka.de [129.13.10.90]) by ietf.org (8.9.1a/8.9.1a) with SMTP id FAA00499 for ; Tue, 12 Dec 2000 05:01:29 -0500 (EST) Received: from blackfoot.telematik.informatik.uni-karlsruhe.de by iraun1 (PP) with ESMTP; Tue, 12 Dec 2000 10:29:21 +0100 Received: from tpce10.telematik.informatik.uni-karlsruhe.de (root@tpce10.telematik.informatik.uni-karlsruhe.de [129.13.41.110]) by blackfoot.telematik.informatik.uni-karlsruhe.de (8.9.3/8.9.3) with ESMTP id KAA02887; Tue, 12 Dec 2000 10:29:16 +0100 (MET) Received: from mailhost (bless@tpce10.telematik.informatik.uni-karlsruhe.de [129.13.41.110]) by tpce10.telematik.informatik.uni-karlsruhe.de (8.9.3/8.9.3) with ESMTP id KAA17546; Tue, 12 Dec 2000 10:29:15 +0100 Message-Id: <200012120929.KAA17546@tpce10.telematik.informatik.uni-karlsruhe.de> X-Mailer: exmh version 2.1.1 10/15/1999 To: Brian E Carpenter cc: Simon Leinen , Yoram Bernet , diffserv@ietf.org Subject: Re: LBE PHB [was: [Diffserv] comments on the bulk handling draft] In-Reply-To: Message from Brian E Carpenter of "Mon, 11 Dec 2000 17:55:51 CST." <3A356987.1453F7DE@hursley.ibm.com> Mime-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Mime-Version: 1.0 X-Encoded: Changed encoding from 8bit for 7bit transmission Date: Tue, 12 Dec 2000 10:29:15 +0100 From: Roland Bless Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by optimus.ietf.org id FAA05007 Sender: diffserv-admin@ietf.org Errors-To: diffserv-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Diffserv Discussion List X-BeenThere: diffserv@ietf.org Content-Transfer-Encoding: 8bit See comments below. > I agree that the draft deserves recognition. The reason Kathie and I > wrote our draft was because we don't believe there is any reason > to define a new PHB to support this type of PDB. We don't agree here: 1. Our formerly proposed LBE PHB (we call it now Limited Effort (LE) PHB) is solely defined by PHB mechanisms within a node, no traffic conditioning mechanisms are required. It is however possible to use a specialized AF PHB _implementation_ to obtain the desired behavior. But this is also true for many other PHBs (e.g., EF and CS PHBs). One can surely consider the (old and forthcoming new) EF PHB definition as a special case of the CS 7 PHB, on which the EF PHB _implementation_ can be based upon. In our point of view the EF PHB specification just defines certain requirements and constraints which can be applied to the more generic CS PHB definition. If a CS PHB _implementation_ fulfills these particular EF requirements, one gets actually an EF PHB. 2. Packets from excess traffic may be re-marked to LE within a node (as proposed in our multicast draft), therefore there is no real "edge to edge" behavior in this case. 3. We don't see any "overhead" by this PHB definition. One doesn't need new mechanisms for its implementation. For instance, you can use a common RED queue for best-effort and LE packets with respective different parameter sets, or, alternatively you can use two AF PHBs from an AF class, one for BE traffic, one for LE traffic. However, how you implement it doesn't really matter, as long as the desired and specified LE behavior is met. > As Kathie said today, the LBE name is no better chosen than > BH. Maybe we should call the new PDB "NCT" for Non-Critical Traffic? We propose Limited Effort (LE) PHB (draft will follow). However, our definition has a non-starvation guarantee for the traffic, while BH PDB allows total starvation of the traffic, resulting in a different behavior. Regards, Roland -- Roland Bless -- e-Mail: bless@telematik.informatik.uni-karlsruhe.de Institute of Telematics, University of Karlsruhe, F.R. of Germany Zirkel 2, D-76128 Karlsruhe -- Office: Engesserstr.2 (Bld. 20.50), 1st floor Phone: +49 721 608-6396 Fax: +49 721 388097 _______________________________________________ diffserv mailing list diffserv@ietf.org http://www1.ietf.org/mailman/listinfo/diffserv Archive: http://www2.ietf.org/mail-archive/working-groups/diffserv/current/maillist.html From diffserv-admin@ietf.org Tue Dec 12 07:55: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 SMTP id HAA19727 for ; Tue, 12 Dec 2000 07:55:29 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id HAA06626; Tue, 12 Dec 2000 07:18:46 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id HAA06596 for ; Tue, 12 Dec 2000 07:18:42 -0500 (EST) Received: from usc.edu (root@usc.edu [128.125.253.136]) by ietf.org (8.9.1a/8.9.1a) with SMTP id HAA15718 for ; Tue, 12 Dec 2000 07:18:40 -0500 (EST) Received: from koh-sun017.usc.edu (demir@koh-sun017.usc.edu [128.125.5.125]) by usc.edu (8.9.3.1/8.9.3/usc) with ESMTP id EAA03091; Tue, 12 Dec 2000 04:18:40 -0800 (PST) Received: from localhost (demir@localhost) by koh-sun017.usc.edu (8.9.3.1/8.9.3/usc) with ESMTP id EAA04901; Tue, 12 Dec 2000 04:18:40 -0800 (PST) Date: Tue, 12 Dec 2000 04:18:39 -0800 (PST) From: demir To: Brian E Carpenter cc: diffserv@ietf.org Subject: Re: [Diffserv] Another restriction of EFRESOLVE on conformance test In-Reply-To: <3A356B1B.2AA12704@hursley.ibm.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: diffserv-admin@ietf.org Errors-To: diffserv-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Diffserv Discussion List X-BeenThere: diffserv@ietf.org Brian, My point was about in the presence of other traffic (non-EF traffic). Alper K. Demir On Mon, 11 Dec 2000, Brian E Carpenter wrote: > Your point isn't clear. There isn't any real difficulty in doing a lab > test to measure the sequence E(i) with a standard traffic source, > followed by a test to measure D(i) with the same source but in the > presence of other traffic from one or more other standard traffic > sources. There is a significant difficulty in doing the same thing > outside the lab, but that is nothing new and nothing specific to EF. > > Brian > > demir wrote: > > > > Joel, > > > The specific decision in crafting this form of definition was that > > > conformance testing can only be done in a test environment, It is > > > certainly true that one can not characterize in the operational network the > > > E(i) that an actually serviced stream would have received. However, if the > > > device does EF you know what the bounds are anyway. Conformance testing in > > > an operational environment while nice is simply not a feature of our > > > definition. > > > > I agree with above "statements". In addition, both E(i) and D(i) has the > > same problem. I accept that "conformance testing in an operational > > environment" is simply not a feature of your definition. Are we talking > > about a "utopian"/"misterious" PHB? It seems to me that EFRESOLVE is > > trying some "acrobatic" to tackle all problems related to it (Please no > > offence or harm to anyone. This is only what I see). If we assume > > "everything" (provided all conditions), we can construct a scale to hold > > the "earth" (I recall similiar phrase from physics class, sorry for not > > being able to write it down in English as it is said). > > > > Alper K. Demir > > > > > At 11:13 AM 12/11/00 -0800, demir wrote: > > > >I am not sure if anyone has already pointed out. If so, I appologize for > > > >bringing it up again. > > > > > > > >An EF (EFRESOLVE) scheduler can make D(i) - E(i) conformance test only > > > >before it sends a EF packet. If a non-EF packet arrives after a EF packet > > > >where EF packet's conformance has already calculated, but non-EF packet > > > >leaves before the EF packet though it has arrived after (for whatever > > > >reason), then pre-calulated D(i) - E(i) will be wrong. Is that acceptable? > > > > > > > >Alper K. Demir > > > > > > > > > > > > > > > > > > > >_______________________________________________ > > > >diffserv mailing list > > > >diffserv@ietf.org > > > >http://www1.ietf.org/mailman/listinfo/diffserv > > > >Archive: > > > >http://www2.ietf.org/mail-archive/working-groups/diffserv/current/maillist.html > > > > > > > _______________________________________________ > > diffserv mailing list > > diffserv@ietf.org > > http://www1.ietf.org/mailman/listinfo/diffserv > > Archive: http://www2.ietf.org/mail-archive/working-groups/diffserv/current/maillist.html > > -- > - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - > Brian E Carpenter > Program Director, Internet Standards & Technology, IBM > On assignment for IBM at http://www.iCAIR.org > Board Chairman, Internet Society http://www.isoc.org > Non-IBM email: brian@icair.org > _______________________________________________ diffserv mailing list diffserv@ietf.org http://www1.ietf.org/mailman/listinfo/diffserv Archive: http://www2.ietf.org/mail-archive/working-groups/diffserv/current/maillist.html From diffserv-admin@ietf.org Tue Dec 12 10:39: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 SMTP id KAA09406 for ; Tue, 12 Dec 2000 10:39:42 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id KAA08201; Tue, 12 Dec 2000 10:09:06 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id KAA08172 for ; Tue, 12 Dec 2000 10:09:01 -0500 (EST) Received: from auemail2.firewall.lucent.com (auemail2.lucent.com [192.11.223.163]) by ietf.org (8.9.1a/8.9.1a) with SMTP id KAA05951 for ; Tue, 12 Dec 2000 10:09:00 -0500 (EST) Received: from auemail2.firewall.lucent.com (localhost [127.0.0.1]) by auemail2.firewall.lucent.com (Pro-8.9.3/8.9.3) with ESMTP id KAA15359 for ; Tue, 12 Dec 2000 10:09:01 -0500 (EST) Received: from uk0006exch001h.wins.lucent.com (h135-86-160-150.lucent.com [135.86.160.150]) by auemail2.firewall.lucent.com (Pro-8.9.3/8.9.3) with ESMTP id KAA15315 for ; Tue, 12 Dec 2000 10:09:00 -0500 (EST) Received: by uk0006exch001h.uk.lucent.com with Internet Mail Service (5.5.2650.21) id ; Tue, 12 Dec 2000 15:08:59 -0000 Message-ID: <976F7C55E3B2D111A0720008C728549C04877623@en0060exch001u.uk.lucent.com> From: "Casati, Alessio (Alessio)" To: Brian E Carpenter , "'Anna Charny'" Cc: diffserv@ietf.org Subject: RE: [Diffserv] Possible compromise between EFRESOLVE anddraft-ch arny Date: Tue, 12 Dec 2000 15:08:54 -0000 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: text/plain Sender: diffserv-admin@ietf.org Errors-To: diffserv-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Diffserv Discussion List X-BeenThere: diffserv@ietf.org > ---------- > From: Anna Charny[SMTP:acharny@cisco.com] > > >... > > > I think Bill may have answered this question, but let me give my > > > answer. Consider an ideal output buffered device with 1000 ports, all > > > links being the same speed. Suppose that 1/5000 of traffic from each > input > > > goes to each output (that is, all links in the router is exactly 50% > booked > > > with EF traffic). Suppose every output implements a strict priority > > > queue. An ideal output buffered device with a PQ at each output seems > to > > > me as close to an ideal device as we can get for EF support. Suppose > now a > > > single packet destined for the same output j arrives at the same time > to > > > each one of 1000 inputs. Would you agree that S has to be at least > > > 999? Now, let's go one step further and assume that we actually allow > B > > > back-to-back packet burst at each input. Do you agree that S must be > at > > > least 999 times B? > > > > S is the measure (in number of packet times) > of the bound on delay variation. The packet time is computed > using the expected rate at the input interface. > > Now, let's suppose we have M input interfaces, > and that we accept a burst B MTU sized packets from each. > > Let's suppose the accepted EF input rate is R and that the > output interface is a link served at a rate R(out) at least such that > MTU/R = MTU*M*B/R(out). In this case S=1. You can scale the output rate to obtain any value of S that satisfies the service goals. The EFresolve does not enter the business of defining this output rate. This is implicit, left to the engineers to figure out, depending on the instance of router they are dealing with. The same holds for any other router specific knob that can be used to obtain the S goal. alessio _______________________________________________ diffserv mailing list diffserv@ietf.org http://www1.ietf.org/mailman/listinfo/diffserv Archive: http://www2.ietf.org/mail-archive/working-groups/diffserv/current/maillist.html From diffserv-admin@ietf.org Tue Dec 12 11:24: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 SMTP id LAA14802 for ; Tue, 12 Dec 2000 11:24:42 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id LAA08931; Tue, 12 Dec 2000 11:03:26 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id LAA08902 for ; Tue, 12 Dec 2000 11:03:22 -0500 (EST) 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 SMTP id LAA12263 for ; Tue, 12 Dec 2000 11:03:20 -0500 (EST) Received: from stl-av-02.boeing.com ([192.76.190.7]) by stl-smtpout-01.boeing.com (8.9.2/8.8.5-M2) with ESMTP id KAA07497 for ; Tue, 12 Dec 2000 10:03:21 -0600 (CST) Received: from stl-hub-01.boeing.com (localhost [127.0.0.1]) by stl-av-02.boeing.com (8.9.3/8.9.2) with ESMTP id KAA15931 for ; Tue, 12 Dec 2000 10:03:01 -0600 (CST) Received: from xch-phlbh-01.he.boeing.com by stl-hub-01.boeing.com with ESMTP; Tue, 12 Dec 2000 10:02:51 -0600 Received: by xch-phlbh-01.he.boeing.com with Internet Mail Service (5.5.2650.21) id ; Tue, 12 Dec 2000 11:02:50 -0500 Message-Id: <4102273CEB77D211869200805FE6F593018C5BED@xch-phl-01.he.boeing.com> From: "Manfredi, Albert E" To: "'Anna Charny'" Cc: diffserv@ietf.org Subject: RE: [Diffserv] Possible compromise between EFRESOLVE anddraft-ch arny Date: Tue, 12 Dec 2000 11:02:49 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: text/plain; charset="iso-8859-1" Sender: diffserv-admin@ietf.org Errors-To: diffserv-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Diffserv Discussion List X-BeenThere: diffserv@ietf.org Anna Charny wrote: > I think it is perfectly fine for a scheduler or a device to cope with > simultaneous arrivals, and you are most certainly right that > every device > must deal with it. And in fact every reasonable device does. To a point. In your example, Anna, you are assuming that the EF device must accept simultaneously EF traffic from any of the interfaces and spit this out any one or more output interfaces. But there's no reason to assume such unconstrained behavior, is there? I think it's easier to think of R as the aggregate incoming EF traffic rate at that EF device, and to specify S for cases in which the capacity of each egress is at least as high as the EF traffic directed to it. In the worst case, all incoming R goes out a single interface. If you design the box for this worst case and for non-blocking behavior at all times, _then_ you would have to specify that ingress EF traffic on any interface must be <= R/n, where n is the number of interfaces. But there is no reason to mandate such behavior, is there? EF traffic might only exist at a small number of interfaces at any given time. And there will be times when people try to send too much EF traffic through, and the box must somehow indicate that it is overbooked. > I gave an example of an ideal (large) output buffered device > with PQ at the > output, which gave a large value of S. Since I doubt that it > is reasonable > to say that large ideal output-buffered routers with a PQ at > the output are > bad for EF, I belive my example indicates that is is NOT true > that devices > with large S "are simply not ideal for EF use". On the other hand, large S might not lead to acceptable EF behavior. I'm simply suggesting that the uncontrained, non-blocking scenario you postulated, when it leads to large values of S, results in large queue-related latency, which this sort of traffic might not be able to accept. CBR traffic is hard to handle. It's always been the case. I'm suggesting that the D(j) - E(j) <= a certain number of packets in queue definition of EFRESOLVE is valid for actual _traffic_ requirements in the real world. I don't think this behavior can necessarily be provided by a never-busy sort of device, unless you put onerous constraints on incoming EF traffic. Bert _______________________________________________ diffserv mailing list diffserv@ietf.org http://www1.ietf.org/mailman/listinfo/diffserv Archive: http://www2.ietf.org/mail-archive/working-groups/diffserv/current/maillist.html From diffserv-admin@ietf.org Tue Dec 12 11:26: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 SMTP id LAA15043 for ; Tue, 12 Dec 2000 11:26:48 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id LAA08974; Tue, 12 Dec 2000 11:05:30 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id LAA08943 for ; Tue, 12 Dec 2000 11:05:26 -0500 (EST) Received: from mailhub1.almaden.ibm.com (mailhub1.almaden.ibm.com [198.4.83.44]) by ietf.org (8.9.1a/8.9.1a) with SMTP id LAA12518 for ; Tue, 12 Dec 2000 11:05:23 -0500 (EST) Received: from maui.almaden.ibm.com (maui.almaden.ibm.com [9.1.24.92]) by mailhub1.almaden.ibm.com (8.8.8/8.8.8) with ESMTP id IAA44322; Tue, 12 Dec 2000 08:02:23 -0800 Received: from hursley.ibm.com (gsine01.us.sine.ibm.com [9.14.6.41]) by maui.almaden.ibm.com (AIX4.3/8.9.3/8.7) with ESMTP id IAA20942; Tue, 12 Dec 2000 08:04:53 -0800 Message-ID: <3A364C62.837C3D23@hursley.ibm.com> Date: Tue, 12 Dec 2000 10:03:46 -0600 From: Brian E Carpenter Organization: IBM X-Mailer: Mozilla 4.61 [en] (Win98; I) X-Accept-Language: en,fr MIME-Version: 1.0 To: GARBISU Jean-Pierre FTRD/DMI/CAE CC: Simon Leinen , Yoram Bernet , diffserv@ietf.org Subject: Re: LBE PHB [was: [Diffserv] comments on the bulk handling draft] References: <91A311FF6A85D3118DDF0060080C3D82B7DAAE@lat3721.lannion.cnet.fr> 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 GARBISU Jean-Pierre FTRD/DMI/CAE wrote: ... > what will be the recommended precedence : 1 ? The suggested PHB was Class Selector 1, which can be viewed as backwards-compatible with TOS Precedence 1. Brian _______________________________________________ diffserv mailing list diffserv@ietf.org http://www1.ietf.org/mailman/listinfo/diffserv Archive: http://www2.ietf.org/mail-archive/working-groups/diffserv/current/maillist.html From diffserv-admin@ietf.org Tue Dec 12 11:32: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 SMTP id LAA16185 for ; Tue, 12 Dec 2000 11:32:17 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id LAA09069; Tue, 12 Dec 2000 11:10:12 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id LAA09038 for ; Tue, 12 Dec 2000 11:10:07 -0500 (EST) Received: from pilgrim.cisco.com (pilgrim.cisco.com [171.69.204.12]) by ietf.org (8.9.1a/8.9.1a) with SMTP id LAA13073 for ; Tue, 12 Dec 2000 11:10:04 -0500 (EST) Received: from acharny-nt.cisco.com (sj-dial-4-122.cisco.com [171.68.181.251]) by pilgrim.cisco.com (8.8.8-Cisco List Logging/8.8.8) with ESMTP id LAA23955; Tue, 12 Dec 2000 11:09:24 -0500 (EST) Message-Id: <4.3.2.7.2.20001212101751.00bc0dc0@pilgrim.cisco.com> X-Sender: acharny@pilgrim.cisco.com X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Tue, 12 Dec 2000 11:15:04 -0500 To: "Casati, Alessio (Alessio)" , Brian E Carpenter , "'Anna Charny'" From: Anna Charny Subject: RE: [Diffserv] Possible compromise between EFRESOLVE anddraft-ch arny Cc: diffserv@ietf.org In-Reply-To: <976F7C55E3B2D111A0720008C728549C04877623@en0060exch001u.uk .lucent.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: diffserv-admin@ietf.org Errors-To: diffserv-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Diffserv Discussion List X-BeenThere: diffserv@ietf.org At 03:08 PM 12/12/00 +0000, Casati, Alessio (Alessio) wrote: > > ---------- > > From: Anna Charny[SMTP:acharny@cisco.com] > > > > >... > > > > I think Bill may have answered this question, but let me give my > > > > answer. Consider an ideal output buffered device with 1000 ports, all > > > > links being the same speed. Suppose that 1/5000 of traffic from each > > input > > > > goes to each output (that is, all links in the router is exactly 50% > > booked > > > > with EF traffic). Suppose every output implements a strict priority > > > > queue. An ideal output buffered device with a PQ at each output seems > > to > > > > me as close to an ideal device as we can get for EF support. Suppose > > now a > > > > single packet destined for the same output j arrives at the same time > > to > > > > each one of 1000 inputs. Would you agree that S has to be at least > > > > 999? Now, let's go one step further and assume that we actually allow > > B > > > > back-to-back packet burst at each input. Do you agree that S must be > > at > > > > least 999 times B? > > > > > > > S is the measure (in number of packet times) > > of the bound on delay variation. The packet time is computed > > using the expected rate at the input interface. > > > > Now, let's suppose we have M input interfaces, > > and that we accept a burst B MTU sized packets from each. > > > > Let's suppose the accepted EF input rate is R and that the > > output interface is a link served at a rate R(out) at least such that > > MTU/R = MTU*M*B/R(out). > >In this case S=1. You can scale the output rate to obtain any value >of S that satisfies the service goals. From the piece of text you have taken out from the example (which I think may be Dimitri's?) I cannot tell whether what you are saying is correct or not. But your message above does not seem to make sense to me in general. I want to remind you the context of the example I gave to show large S for which no reasonable scaling would help. You have am ideal output buffered router with no internal delay, N identical speed C interfaces, and a PQ at each interface. You have C/2 -worth of total EF traffic going from each input interfaces to all other outputs, which means that the configured input rate is R=C/2. From the total EF traffic at every input only C/2N goes to each individual output. Therefore, each output has R=C/2 EF traffic as well. Consider any single output. It can experience a simultaneous arrival of N packets of MTU size, one from each input interface (even for the case wen there is no input burstiness at all). This means that there could be an instantaneous queue of N packets, which can be drained at most at the speed of the interface C=2R. Therefore, a delay experienced by the last packet in this queue will be N*MTU/2R. That means in this case D=N*MTU/2R for this packet. In the absence of competing traffic this packet would have left at time E=MTU/C=MTU/2R. This means that D-E = (N-1)/2 * MTU/R. So for a N=1000 port device S must be at least 999/2=499.5 for ideally shaped inputs. If you allow a burst B at each input, you would need to have S=499.5*B, and NOT S=1. Anna > The EFresolve does not >enter the business of defining this output rate. >This is implicit, left to the engineers >to figure out, depending on the instance of router they >are dealing with. The same holds for any other router specific knob >that can be used to obtain the S goal. > >alessio --------------------------------------- Anna Charny Cisco Systems, Inc 300 Apollo Drive Chelmsford, MA 01824 Tel. (978)-244-8172 Fax (978)-244-8126 _______________________________________________ diffserv mailing list diffserv@ietf.org http://www1.ietf.org/mailman/listinfo/diffserv Archive: http://www2.ietf.org/mail-archive/working-groups/diffserv/current/maillist.html From diffserv-admin@ietf.org Tue Dec 12 12:16: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 SMTP id MAA27550 for ; Tue, 12 Dec 2000 12:16:20 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id LAA09769; Tue, 12 Dec 2000 11:48:06 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id LAA09738 for ; Tue, 12 Dec 2000 11:48:02 -0500 (EST) Received: from pilgrim.cisco.com (pilgrim.cisco.com [171.69.204.12]) by ietf.org (8.9.1a/8.9.1a) with SMTP id LAA19713 for ; Tue, 12 Dec 2000 11:47:59 -0500 (EST) Received: from acharny-nt.cisco.com (sj-dial-4-122.cisco.com [171.68.181.251]) by pilgrim.cisco.com (8.8.8-Cisco List Logging/8.8.8) with ESMTP id LAA28623; Tue, 12 Dec 2000 11:46:48 -0500 (EST) Message-Id: <4.3.2.7.2.20001212111604.00bb8100@pilgrim.cisco.com> X-Sender: acharny@pilgrim.cisco.com X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Tue, 12 Dec 2000 11:52:29 -0500 To: "Manfredi, Albert E" , "'Anna Charny'" From: Anna Charny Subject: RE: [Diffserv] Possible compromise between EFRESOLVE anddraft-ch arny Cc: diffserv@ietf.org In-Reply-To: <4102273CEB77D211869200805FE6F593018C5BED@xch-phl-01.he.boe ing.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 Bert, At 11:02 AM 12/12/00 -0500, Manfredi, Albert E wrote: >Anna Charny wrote: > > > I think it is perfectly fine for a scheduler or a device to cope with > > simultaneous arrivals, and you are most certainly right that > > every device > > must deal with it. And in fact every reasonable device does. > >To a point. In your example, Anna, you are assuming that the EF device must >accept simultaneously EF traffic from any of the interfaces and spit this >out any one or more output interfaces. But there's no reason to assume such >unconstrained behavior, is there? I think you mean that a 1000 port device should be specified as being only able to support EF traffic on a small number of its interfaces? I would agree that if you want the jitter bound of one packet time at the rate that VW draft wants, you may need to impose such drastic constraints. But in that case, you are also limiting any EF traffic that does not need such stringent requirements. For example VoIP does not seem to need that - there are jitter buffers that you can use to absorb a much larger device. So either you would have to say that your S is large, or you have to say "if up to i interfaces support EF with max input rate of R_j, then S=S(i, j), And that seems to become rather a difficult task to specify all possible reasonable combinations when interface speeds are different, and the number of ports are large. >I think it's easier to think of R as the aggregate incoming EF traffic rate >at that EF device, and to specify S for cases in which the capacity of each >egress is at least as high as the EF traffic directed to it. It seems to me that this would require going from the input-rate based definition to an output rate based definition. I agree that that would be the correct thing to do. >In the worst case, all incoming R goes out a single interface. If you design >the box for this worst case and for non-blocking behavior at all times, >_then_ you would have to specify that ingress EF traffic on any interface >must be <= R/n, where n is the number of interfaces. I do not agree that the above is the worst case, if R is the max rate of the total input EF traffic a some interface, as the current definition says. It would indeed be so if R were the configured rate of the output. We have suggested it several times to the efresolve team, but they always insisted that the input rate R is the correct approach, and the one they actually meant. >But there is no reason to mandate such behavior, is there? EF traffic might >only exist at a small number of interfaces at any given time. And there will >be times when people try to send too much EF traffic through, and the box >must somehow indicate that it is overbooked. I think I addressed this at the beginning. What you are saying seems to imply that either you give huge S numbers and do not specify restrictions, or you need to figure out how to specify the restrictions in a meaningful way. If you tell me that you have a 1000 port device with S=1 in Ef traffic is coming from a single input only (or some small number of ports), that would be a true statement, but I am not sure it would be useful for me to understand whether I can use that device to support a less restrictive environment. > > I gave an example of an ideal (large) output buffered device > > with PQ at the > > output, which gave a large value of S. Since I doubt that it > > is reasonable > > to say that large ideal output-buffered routers with a PQ at > > the output are > > bad for EF, I belive my example indicates that is is NOT true > > that devices > > with large S "are simply not ideal for EF use". > >On the other hand, large S might not lead to acceptable EF behavior. I'm >simply suggesting that the uncontrained, non-blocking scenario you >postulated, when it leads to large values of S, results in large >queue-related latency, which this sort of traffic might not be able to >accept. I think that there is a very large range of Ef traffic, such as VoIP, that would be perfectly supportable in a large device. I am not sure we can say that EF is ONLY traffic that needs a strict worst case guarantee that jitter dos not exceed a small number of packet intervals. If that is what is indeed what you are saying, I think that should be very carefully considered by the WG. >CBR traffic is hard to handle. It's always been the case. I'm suggesting >that the D(j) - E(j) <= a certain number of packets in queue definition of >EFRESOLVE is valid for actual _traffic_ requirements in the real world. I >don't think this behavior can necessarily be provided by a never-busy sort >of device, unless you put onerous constraints on incoming EF traffic. Again, I have to repeat that this is a serious statement that I think you are making. If we say that all EF traffic MUST get a deterministic worst case jitter guarantee of a small number of packet intervals at its rate, we need to make sure that 1) it is actually possible to achieve end-to-end (which we do not know at the moment), and b) that the working group accepts that you can only support an onerously small amount of EF VoIP traffic in large devices. Anna >Bert --------------------------------------- Anna Charny Cisco Systems, Inc 300 Apollo Drive Chelmsford, MA 01824 Tel. (978)-244-8172 Fax (978)-244-8126 _______________________________________________ diffserv mailing list diffserv@ietf.org http://www1.ietf.org/mailman/listinfo/diffserv Archive: http://www2.ietf.org/mail-archive/working-groups/diffserv/current/maillist.html From diffserv-admin@ietf.org Tue Dec 12 13:02: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 SMTP id NAA08686 for ; Tue, 12 Dec 2000 13:02:00 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id MAA10805; Tue, 12 Dec 2000 12:34:42 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id MAA10776 for ; Tue, 12 Dec 2000 12:34:35 -0500 (EST) Received: from mta5.snfc21.pbi.net (mta5.snfc21.pbi.net [206.13.28.241]) by ietf.org (8.9.1a/8.9.1a) with SMTP id MAA01567 for ; Tue, 12 Dec 2000 12:34:34 -0500 (EST) Received: from allegronetworks.com ([206.170.32.29]) by mta5.snfc21.pbi.net (Sun Internet Mail Server sims.3.5.2000.01.05.12.18.p9) with ESMTP id <0G5G00JWETEDL5@mta5.snfc21.pbi.net> for diffserv@ietf.org; Tue, 12 Dec 2000 09:18:14 -0800 (PST) Date: Tue, 12 Dec 2000 09:26:13 -0800 From: Andrew Smith Subject: Re: [Diffserv] Token bucket suggestion in Diffserv Model draft To: Brian E Carpenter Cc: "'diffserv@ietf.org'" Message-id: <3A365FB5.9040604@allegronetworks.com> Organization: Allegro Networks MIME-version: 1.0 Content-type: text/plain; charset=us-ascii; format=flowed Content-transfer-encoding: 7bit User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; m18) Gecko/20001108 Netscape6/6.0 X-Accept-Language: en References: <9DC5E2ABE65BD54CA9088DA3194461D6010C9AEA@BBY1EXM01> <3A35A2E1.7497AD08@hursley.ibm.com> Content-Transfer-Encoding: 7bit Sender: diffserv-admin@ietf.org Errors-To: diffserv-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Diffserv Discussion List X-BeenThere: diffserv@ietf.org Content-Transfer-Encoding: 7bit I prefer strict/loose (but I'll go with the flow if the WG wants to change it). Regarding Shahram's proposed re-wording: I need to parse it further but on first read, parts of it seem more confused than before (in particular, confusion whether some "either/or" pairs refer to (a) implementation options or (b) to choices made in the behaviour of a given implementation). Detailed comments to follow. Can someone please summarise what the WG meeting agreed to w.r.t. this document? My apologies for not having been there ... Andrew (Model draft editor - still) Brian E Carpenter wrote: > Shahram, > > Thanks for all the suggested text. I will leave the document editor to > decide how much of it he adopts - I hadn't expected so much change from today's > discussion. > > As for the terminology change from "strict/loose" to > "positive-count/negative-count", we would need a consensus for that. > WG comments are welcome. > > Thanks > Brian _______________________________________________ diffserv mailing list diffserv@ietf.org http://www1.ietf.org/mailman/listinfo/diffserv Archive: http://www2.ietf.org/mail-archive/working-groups/diffserv/current/maillist.html From diffserv-admin@ietf.org Tue Dec 12 13:28: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 SMTP id NAA14239 for ; Tue, 12 Dec 2000 13:28:15 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id NAA11450; Tue, 12 Dec 2000 13:03:20 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id NAA11426 for ; Tue, 12 Dec 2000 13:03:16 -0500 (EST) 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 SMTP id NAA09082 for ; Tue, 12 Dec 2000 13:03:15 -0500 (EST) Received: from stl-av-02.boeing.com ([192.76.190.7]) by stl-smtpout-01.boeing.com (8.9.2/8.8.5-M2) with ESMTP id MAA29700 for ; Tue, 12 Dec 2000 12:03:15 -0600 (CST) Received: from stl-hub-01.boeing.com (localhost [127.0.0.1]) by stl-av-02.boeing.com (8.9.3/8.9.2) with ESMTP id MAA19863 for ; Tue, 12 Dec 2000 12:03:01 -0600 (CST) Received: from xch-phlbh-01.he.boeing.com by stl-hub-01.boeing.com with ESMTP; Tue, 12 Dec 2000 12:02:50 -0600 Received: by xch-phlbh-01.he.boeing.com with Internet Mail Service (5.5.2650.21) id ; Tue, 12 Dec 2000 13:02:50 -0500 Message-Id: <4102273CEB77D211869200805FE6F593018C5BF1@xch-phl-01.he.boeing.com> From: "Manfredi, Albert E" To: "'Anna Charny'" Cc: diffserv@ietf.org Subject: RE: [Diffserv] Possible compromise between EFRESOLVE anddraft-ch arny Date: Tue, 12 Dec 2000 13:02:47 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: text/plain; charset="iso-8859-1" Sender: diffserv-admin@ietf.org Errors-To: diffserv-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Diffserv Discussion List X-BeenThere: diffserv@ietf.org Anna Charny wrote: > Again, I have to repeat that this is a serious statement that > I think you > are making. If we say that all EF traffic MUST get a > deterministic worst > case jitter guarantee of a small number of packet intervals > at its rate, we > need to make sure that 1) it is actually possible to achieve > end-to-end > (which we do not know at the moment), and b) that the working > group accepts > that you can only support an onerously small amount of EF > VoIP traffic in > large devices. Indeed, Anna. Onerously small _only_ if the EF device must be available at all times, for simultaneous EF traffic from any and all of its interfaces. But such availability would be astonishing from any CBR net, so it should be equally astonishing from an EF net. Yes, I think what you summarize above is quite correct for EF. That is what makes EF different from AF, in my view anyway. Is this not a consensus view? Bert _______________________________________________ diffserv mailing list diffserv@ietf.org http://www1.ietf.org/mailman/listinfo/diffserv Archive: http://www2.ietf.org/mail-archive/working-groups/diffserv/current/maillist.html From diffserv-admin@ietf.org Tue Dec 12 14:18: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 SMTP id OAA24758 for ; Tue, 12 Dec 2000 14:18:20 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id NAA12371; Tue, 12 Dec 2000 13:52:01 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id NAA12341 for ; Tue, 12 Dec 2000 13:51:57 -0500 (EST) Received: from mailhub1.almaden.ibm.com (mailhub1.almaden.ibm.com [198.4.83.44]) by ietf.org (8.9.1a/8.9.1a) with SMTP id NAA19166 for ; Tue, 12 Dec 2000 13:51:54 -0500 (EST) Received: from maui.almaden.ibm.com (maui.almaden.ibm.com [9.1.24.92]) by mailhub1.almaden.ibm.com (8.8.8/8.8.8) with ESMTP id KAA63190; Tue, 12 Dec 2000 10:48:50 -0800 Received: from hursley.ibm.com (gsine03.us.sine.ibm.com [9.14.6.43]) by maui.almaden.ibm.com (AIX4.3/8.9.3/8.7) with ESMTP id KAA24804; Tue, 12 Dec 2000 10:51:23 -0800 Message-ID: <3A36736E.D96E8F03@hursley.ibm.com> Date: Tue, 12 Dec 2000 12:50:22 -0600 From: Brian E Carpenter Organization: IBM X-Mailer: Mozilla 4.61 [en] (Win98; I) X-Accept-Language: en,fr MIME-Version: 1.0 To: Andrew Smith CC: "'diffserv@ietf.org'" Subject: Re: [Diffserv] Token bucket suggestion in Diffserv Model draft References: <9DC5E2ABE65BD54CA9088DA3194461D6010C9AEA@BBY1EXM01> <3A35A2E1.7497AD08@hursley.ibm.com> <3A365FB5.9040604@allegronetworks.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: diffserv-admin@ietf.org Errors-To: diffserv-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Diffserv Discussion List X-BeenThere: diffserv@ietf.org Content-Transfer-Encoding: 7bit Andrew, the official summary will be in the minutes of course. I sent you a personal note yesterday with my own interpretation. Brian Andrew Smith wrote: > > I prefer strict/loose (but I'll go with the flow if the WG wants to change it). > > Regarding Shahram's proposed re-wording: I need to parse it further but on first > read, parts of it seem more confused than before (in particular, confusion > whether some "either/or" pairs refer to (a) implementation options or (b) to > choices made in the behaviour of a given implementation). Detailed comments to > follow. > > Can someone please summarise what the WG meeting agreed to w.r.t. this document? > My apologies for not having been there ... > > Andrew > (Model draft editor - still) > > Brian E Carpenter wrote: > > > Shahram, > > > > Thanks for all the suggested text. I will leave the document editor to > > decide how much of it he adopts - I hadn't expected so much change from today's > > discussion. > > > > As for the terminology change from "strict/loose" to > > "positive-count/negative-count", we would need a consensus for that. > > WG comments are welcome. > > > > Thanks > > Brian > > _______________________________________________ > diffserv mailing list > diffserv@ietf.org > http://www1.ietf.org/mailman/listinfo/diffserv > Archive: http://www2.ietf.org/mail-archive/working-groups/diffserv/current/maillist.html _______________________________________________ diffserv mailing list diffserv@ietf.org http://www1.ietf.org/mailman/listinfo/diffserv Archive: http://www2.ietf.org/mail-archive/working-groups/diffserv/current/maillist.html From diffserv-admin@ietf.org Tue Dec 12 14:51: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 SMTP id OAA01217 for ; Tue, 12 Dec 2000 14:51:10 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id OAA12964; Tue, 12 Dec 2000 14:24:16 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id OAA12937 for ; Tue, 12 Dec 2000 14:24:12 -0500 (EST) Received: from mailman.packetdesign.com (dns.PACKETDESIGN.NET [216.15.46.10]) by ietf.org (8.9.1a/8.9.1a) with SMTP id OAA26000 for ; Tue, 12 Dec 2000 14:24:10 -0500 (EST) Received: from packetdesign.com (main-fw-eth1.packetdesign.com [192.168.0.254]) by mailman.packetdesign.com (8.11.0/8.11.0) with ESMTP id eBCJMrQ57612; Tue, 12 Dec 2000 11:22:53 -0800 (PST) (envelope-from nichols@packetdesign.com) Message-ID: <3A367B2A.8AF9847@packetdesign.com> Date: Tue, 12 Dec 2000 11:23:22 -0800 From: Kathleen Nichols X-Mailer: Mozilla 4.61 [en] (Win98; U) X-Accept-Language: en MIME-Version: 1.0 To: Roland Bless CC: Yoram Bernet , diffserv@ietf.org Subject: Re: [Diffserv] comments on the bulk handling draft References: <200012120835.JAA17342@tpce10.telematik.informatik.uni-karlsruhe.de> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: diffserv-admin@ietf.org Errors-To: diffserv-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Diffserv Discussion List X-BeenThere: diffserv@ietf.org Content-Transfer-Encoding: 7bit Roland Bless wrote: > ... > > > Another general comment - wasn't just this type of pdb proposed > > previously? I think that it was proposed as draft-mumble-lbe-xx. I > > can't remember the authors, but - one may have been Roland Bless. > > Whoever they were, those authors deserve acknowledgement. Yes, as Brian has said and we mentioned this in the WG. This should have gone into the acks that several people have requested a "less than best effort" behavior and draft-bless proposed a PHB. Since we felt it didn't require a new PHB and that a PDB was the ideal vehicle, we wrote this. And this was a very quickly written draft and will require editing. > > Yes, it was draft-bless-diffserv-phb-lbe-00.txt by Klaus Wehrle and me. > We're just rewriting the draft and are going to resubmit it. However, > we decided to change the name to "Limited Effort" (LE) PHB due to the fact that It's a shame you see it as a PHB...I really like that name, "limited effort", it would be nice for a PDB. In fact, I think we should have more "mechanistic" or "behavioral" names for PHBs, but that's my opinion. > it's nearly the same behavior as best-effort, but compared to the default > PHB, it uses resources only up to a defined limit in case of congestion. Now I'm really confused. This is kind of at the core of diffserv. The CS PHB group is derived from the old used of IP precedence and CBQ schedulers. It's been meant from the start that one could configure PHBs to have "resources only up to a defined limit in case of congestion". This can even be said of EF. The notion we heard was for something that uses ONLY the excess capacity. (Maybe there's a PDB name in there somewhere.) > > There is a very important difference between LE and the proposed BH behavior: > while our definition requires a non-starvation guarantee for the LE BA, BH PDB So we were looking for something that PERMITS starvation, but doesn't require it. As I said above, I think that non-starvation, but a possible limit is easily covered by a CS. The earlier problem with using a CS had been concerns over breaking the SHOULD to do starvation. I spoke about this yesterday and Brian posted on this after you proposed your initial draft some months ago. > does not. Moreover, I see LE and BH as PHBs, because no traffic conditioning > mechanisms are required, no attributes can be specified and no really > predictable behavior can be given from ingress to egress of a DS domain. > However, this PHB can be implemented by using already existing other > PHB _implementations_ like AF (AF is a very generic PHB). > But we want to describe a behavior across a domain. Both BE and BH have null traffic conditioning, though there may be classification required, may be marking, and may even be policing. .... > > deployable only if they are willing to take what is available. This > > means that on networks that are frequently congested, they may not get > > much - but then - that's what this pdb is all about. Basically - I > > think that this should be a warning to this effect, rather than a > > suggestion that the behaviour canot be used on congested networks. 4. > This is actually Yoram's comments which I partially answered in the WG meeting and will get to an on-line version. Mostly, I agree with Yoram, but on the above, I think it's possibly something about the way we worded things. It's not that you can not use it on a network that is congested, but the words were meant only to say that if a network has no capacity to spare (that isn't being taken up by other types of traffic), it may not be a good network to deploy this on. So, I don't believe there is a conflict of philosophy here. Yoram's going to send some word on applicability, I'm going to fix some words (particularly the implication that one MUST classify and mark...we didn't intend to change the intent of the diffserv architecture as stated in 2475 that this can be "null", we just got sloppy.), and we'll repost at some point. Trying to get in other comments as well. Kathie _______________________________________________ diffserv mailing list diffserv@ietf.org http://www1.ietf.org/mailman/listinfo/diffserv Archive: http://www2.ietf.org/mail-archive/working-groups/diffserv/current/maillist.html From diffserv-admin@ietf.org Tue Dec 12 14:53:30 2000 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with SMTP id OAA01526 for ; Tue, 12 Dec 2000 14:53:30 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id OAA13317; Tue, 12 Dec 2000 14:34:05 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id OAA13295 for ; Tue, 12 Dec 2000 14:34:01 -0500 (EST) Received: from pilgrim.cisco.com (pilgrim.cisco.com [171.69.204.12]) by ietf.org (8.9.1a/8.9.1a) with SMTP id OAA28120 for ; Tue, 12 Dec 2000 14:33:59 -0500 (EST) Received: from acharny-nt.cisco.com (sj-dial-3-252.cisco.com [171.68.180.253]) by pilgrim.cisco.com (8.8.8-Cisco List Logging/8.8.8) with ESMTP id OAA19373; Tue, 12 Dec 2000 14:32:46 -0500 (EST) Message-Id: <4.3.2.7.2.20001212142716.00ca6da0@pilgrim.cisco.com> X-Sender: acharny@pilgrim.cisco.com X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Tue, 12 Dec 2000 14:38:27 -0500 To: "Manfredi, Albert E" , "'Anna Charny'" From: Anna Charny Subject: RE: [Diffserv] Possible compromise between EFRESOLVE anddraft-ch arny Cc: diffserv@ietf.org In-Reply-To: <4102273CEB77D211869200805FE6F593018C5BF1@xch-phl-01.he.boe ing.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 Bert, At 01:02 PM 12/12/00 -0500, Manfredi, Albert E wrote: >Anna Charny wrote: > > > Again, I have to repeat that this is a serious statement that > > I think you > > are making. If we say that all EF traffic MUST get a > > deterministic worst > > case jitter guarantee of a small number of packet intervals > > at its rate, we > > need to make sure that 1) it is actually possible to achieve > > end-to-end > > (which we do not know at the moment), and b) that the working > > group accepts > > that you can only support an onerously small amount of EF > > VoIP traffic in > > large devices. > >Indeed, Anna. I just want to make sure that you agree with what I think you have just agreed on. I think you have just agreed that in the context of efresolve definition which requires a theoretical *worst case* jitter bound you are forced to limit the amount of Ef traffic to an onerously small number (in my example 0.1% of the available capacity for a 1000 port device) if you want the jitter bound to be small. I think we are in agreement then. >Onerously small _only_ if the EF device must be available at all times, for >simultaneous EF traffic from any and all of its interfaces. But such >availability would be astonishing from any CBR net, so it should be equally >astonishing from an EF net. The above statement is clearly of statistical nature. If you are talking about statistical behavior, I would immediately agree with you - it is not very likely that Ef traffic is completely synchronized all the time. This is, however, irrelevant in the context of the current EF approach that has chosen to concentrate on the worst case behavior, and wants to provide hard deterministic delay bounds. For that goal you have to consider the rare occasions of syncronisation, and so you comment above seems a moot point. If the working group decides that it is not the worst case guarantees that it is after, but statistical, then a) we need to make sure there is concensus for such a change; b) I would claim that it is difficulat to estimate the statistical probability of bad things happening withing the framework of efreesolve in particular, and not easy in principle. The current work on this subject has been in the context of a rate-based model, and in my view the work of Jim Roberts is one of the most interesting inb this respect. >Yes, I think what you summarize above is quite correct for EF. That is what >makes EF different from AF, in my view anyway. Is this not a consensus view? > >Bert > >_______________________________________________ >diffserv mailing list >diffserv@ietf.org >http://www1.ietf.org/mailman/listinfo/diffserv >Archive: >http://www2.ietf.org/mail-archive/working-groups/diffserv/current/maillist.html --------------------------------------- Anna Charny Cisco Systems, Inc 300 Apollo Drive Chelmsford, MA 01824 Tel. (978)-244-8172 Fax (978)-244-8126 _______________________________________________ diffserv mailing list diffserv@ietf.org http://www1.ietf.org/mailman/listinfo/diffserv Archive: http://www2.ietf.org/mail-archive/working-groups/diffserv/current/maillist.html From diffserv-admin@ietf.org Tue Dec 12 15:14:31 2000 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with SMTP id PAA04059 for ; Tue, 12 Dec 2000 15:14:31 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id OAA13659; Tue, 12 Dec 2000 14:52:26 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id OAA13595 for ; Tue, 12 Dec 2000 14:52:21 -0500 (EST) Received: from sj-msg-core-1.cisco.com (sj-msg-core-1.cisco.com [171.71.163.11]) by ietf.org (8.9.1a/8.9.1a) with SMTP id OAA01391; Tue, 12 Dec 2000 14:52:18 -0500 (EST) Received: from sj-msg-av-1.cisco.com (sj-msg-av-1.cisco.com [171.69.11.130]) by sj-msg-core-1.cisco.com (8.9.3/8.9.1) with ESMTP id LAA03737; Tue, 12 Dec 2000 11:51:24 -0800 (PST) Received: from mailman.cisco.com (localhost [127.0.0.1]) by sj-msg-av-1.cisco.com (8.10.1/8.10.1) with ESMTP id eBCJpVF08231; Tue, 12 Dec 2000 11:51:31 -0800 (PST) Received: from cisco.com (ssh-sj1.cisco.com [171.68.225.134]) by mailman.cisco.com (8.9.3/8.9.1) with ESMTP id LAA12649; Tue, 12 Dec 2000 11:51:16 -0800 (PST) Message-ID: <3A3681EA.B2C42C8@cisco.com> Date: Tue, 12 Dec 2000 11:52:10 -0800 From: Andy Bierman Organization: Cisco Systems, Inc. X-Mailer: Mozilla 4.73 [en] (Win98; U) X-Accept-Language: en MIME-Version: 1.0 To: Harrie Hazewinkel CC: rmonmib@ietf.org, diffserv@ietf.org Subject: Re: [Diffserv] The DsCodePoint definition References: <3A3547FC.8E393EBD@covalent.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 Harrie Hazewinkel wrote: > > HI, > > I was wondering why there is a difference between > 2 definitions of the DiffServ CodePoint in different > MIB modules. The two different MIMB modules are > the DIFFSERV-MIB (of diffserv) and the DSMON-MIB (of RMON). > > I beleive these 2 TCs should be the same and taken from the > DIFFSERV-MIB, because that is from the diffserv WG. But the TCs are obviously designed for different purposes. The DSMON TC represents the actual values that the DSCP field may contain. There is no need for a value of -1, typecast as the value 2G-1. The extra semantics would break the DSMON MIB aggregation control tables. Andy > > ----------- From the DIFFSERV-MIB (draft 05) ----------------- > Dscp ::= TEXTUAL-CONVENTION > DISPLAY-HINT "d" > STATUS current > DESCRIPTION > "The IP header Diffserv Code-Point that may be used > for discriminating or marking a traffic stream. The > value -1 ( 4294967295 for Integer32 ) is used to > indicate a wildcard i.e. any value." > SYNTAX Integer32 (4294967295 | 0..63) > -------------------------------------------------------------- > > ------------ From the DSMON-MIB (draft 03) ------------------- > DsmonDSCodePoint ::= TEXTUAL-CONVENTION > STATUS current > DESCRIPTION > "This TC describes an object which identifies the > Differentiated Services Codepoint (DSCP) value found within > the DS field in a network layer packet header (e.g., IPv4 > and IPv6)." > REFERENCE > "Definition of the Differentiated Services Field (DS Field) > in the IPv4 and IPv6 Headers [RFC2474]." > SYNTAX Integer32 (0..63) > -------------------------------------------------------------- > > OK, I will admit the definition of the DiffServ-MIB is currently > broken, but that will be fixed (this week at the IETF, I hope). > > Harrie > > _______________________________________________ > diffserv mailing list > diffserv@ietf.org > http://www1.ietf.org/mailman/listinfo/diffserv > Archive: http://www2.ietf.org/mail-archive/working-groups/diffserv/current/maillist.html _______________________________________________ diffserv mailing list diffserv@ietf.org http://www1.ietf.org/mailman/listinfo/diffserv Archive: http://www2.ietf.org/mail-archive/working-groups/diffserv/current/maillist.html From diffserv-admin@ietf.org Tue Dec 12 15:20: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 SMTP id PAA04746 for ; Tue, 12 Dec 2000 15:20:10 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id OAA13745; Tue, 12 Dec 2000 14:56:01 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id OAA13713 for ; Tue, 12 Dec 2000 14:55:57 -0500 (EST) Received: from DF-INET-1.dogfoodinternet.com (df-inet1.exchange.microsoft.com [131.107.8.8]) by ietf.org (8.9.1a/8.9.1a) with SMTP id OAA01819 for ; Tue, 12 Dec 2000 14:55:54 -0500 (EST) Received: from df-virus2.platinum.corp.microsoft.com ([172.30.236.33]) by DF-INET-1.dogfoodinternet.com with Microsoft SMTPSVC(5.0.2195.1600); Tue, 12 Dec 2000 10:48:20 -0800 Received: from 172.30.236.11 by df-virus2.platinum.corp.microsoft.com (InterScan E-Mail VirusWall NT); Tue, 12 Dec 2000 10:49:02 -0800 (Pacific Standard Time) Received: from DF-MILO.platinum.corp.microsoft.com ([172.30.236.125]) by yuri.dns.microsoft.com with Microsoft SMTPSVC(5.0.2195.2532); Tue, 12 Dec 2000 10:49:01 -0800 X-MimeOLE: Produced By Microsoft Exchange V6.0.4604.0 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Date: Tue, 12 Dec 2000 10:49:00 -0800 Message-ID: Thread-Topic: LBE PHB [was: [Diffserv] comments on the bulk handling draft] Thread-Index: AcBj09UGB2wdi6KxR2mGP+pxcKn0uQAlt6yw From: "Yoram Bernet" To: Cc: "Brian E Carpenter" , X-OriginalArrivalTime: 12 Dec 2000 18:49:01.0749 (UTC) FILETIME=[31955650:01C0646C] Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by optimus.ietf.org id OAA13714 Subject: [Diffserv] Application for the LBE, BH, NCT, LB whatever it's called... Sender: diffserv-admin@ietf.org Errors-To: 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 After yesterday's WG meeting I offered to send some text describing an application for the proposed pdb (currently called the BH pdb). BTW - I think that this is a key enabling application for DiffServ. Here's the text: ***************** start text ****************** Traditionally, QoS has been viewed as a set of tools that would *prioritize* access to network resources for certain applications (primarily multimedia applications). Over time, we have found that many network managers want to use QoS to *protect* the network from certain applications, in particular, from multimedia applications (that typically use non-adaptive protocols - e.g. UDP). Conventional QoS mechanisms that focus on prirotization offer the network manager the ability to control the amount of multimedia traffic that is given prioritized resources. Excess is relegated to best-effort. The problem is that this excess traffic can wreak havoc with network resources even when it is relegated to best-effort service. Because this traffic is non-adaptive and because it is significant in volume and duration, it tends to sieze network resources, thereby compromising the performance of other, more important applications that are also relegated to best-effort service but that use adaptive protocols (TCP). As a result, network managers often simply refuse to allow multimedia applications to be deployed in resource constrained parts of the network. The [foo] PDB enables the network manager to allow the deployment of multimedia applications without losing control of network resources. A limited amount of multimedia traffic may (or may not) be given prioritized service using any of the prioritizing PDBs (e.g. VW, or other AF based prioritizing services). Excess multimedia traffic can be prevented from wreaking havoc with network resources by forcing it to the [foo] PDB. ***************** end text ********************** _______________________________________________ diffserv mailing list diffserv@ietf.org http://www1.ietf.org/mailman/listinfo/diffserv Archive: http://www2.ietf.org/mail-archive/working-groups/diffserv/current/maillist.html From diffserv-admin@ietf.org Tue Dec 12 15:33: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 SMTP id PAA06348 for ; Tue, 12 Dec 2000 15:33:41 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id PAA14104; Tue, 12 Dec 2000 15:08:03 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id PAA14030 for ; Tue, 12 Dec 2000 15:07:57 -0500 (EST) Received: from sj-msg-core-2.cisco.com (sj-msg-core-2.cisco.com [171.69.43.88]) by ietf.org (8.9.1a/8.9.1a) with SMTP id PAA03221; Tue, 12 Dec 2000 15:07:54 -0500 (EST) Received: from sj-msg-av-1.cisco.com (sj-msg-av-1.cisco.com [171.69.11.130]) by sj-msg-core-2.cisco.com (8.9.3/8.9.1) with ESMTP id MAA13963; Tue, 12 Dec 2000 12:06:59 -0800 (PST) Received: from mailman.cisco.com (localhost [127.0.0.1]) by sj-msg-av-1.cisco.com (8.10.1/8.10.1) with ESMTP id eBCK79E23614; Tue, 12 Dec 2000 12:07:09 -0800 (PST) Received: from cisco.com (ssh-sj1.cisco.com [171.68.225.134]) by mailman.cisco.com (8.9.3/8.9.1) with ESMTP id MAA20203; Tue, 12 Dec 2000 12:06:54 -0800 (PST) Message-ID: <3A368594.A68F9240@cisco.com> Date: Tue, 12 Dec 2000 12:07:48 -0800 From: Andy Bierman Organization: Cisco Systems, Inc. X-Mailer: Mozilla 4.73 [en] (Win98; U) X-Accept-Language: en MIME-Version: 1.0 To: Harrie Hazewinkel CC: rmonmib@ietf.org, diffserv@ietf.org Subject: Re: [Diffserv] The DsCodePoint definition References: <3A3547FC.8E393EBD@covalent.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 Harrie Hazewinkel wrote: > > HI, > > I was wondering why there is a difference between > 2 definitions of the DiffServ CodePoint in different > MIB modules. The two different MIMB modules are > the DIFFSERV-MIB (of diffserv) and the DSMON-MIB (of RMON). > > I beleive these 2 TCs should be the same and taken from the > DIFFSERV-MIB, because that is from the diffserv WG. > > ----------- From the DIFFSERV-MIB (draft 05) ----------------- > Dscp ::= TEXTUAL-CONVENTION > DISPLAY-HINT "d" > STATUS current > DESCRIPTION > "The IP header Diffserv Code-Point that may be used > for discriminating or marking a traffic stream. The > value -1 ( 4294967295 for Integer32 ) is used to > indicate a wildcard i.e. any value." > SYNTAX Integer32 (4294967295 | 0..63) just noticed how broken this TC is... 1) an Integer32 object cannot contain the value 4294967295 2) missing REFERENCE clause (where exactly in 2474 is the 'wildcard' DSCP value discussed?) Andy > -------------------------------------------------------------- > > ------------ From the DSMON-MIB (draft 03) ------------------- > DsmonDSCodePoint ::= TEXTUAL-CONVENTION > STATUS current > DESCRIPTION > "This TC describes an object which identifies the > Differentiated Services Codepoint (DSCP) value found within > the DS field in a network layer packet header (e.g., IPv4 > and IPv6)." > REFERENCE > "Definition of the Differentiated Services Field (DS Field) > in the IPv4 and IPv6 Headers [RFC2474]." > SYNTAX Integer32 (0..63) > -------------------------------------------------------------- > > OK, I will admit the definition of the DiffServ-MIB is currently > broken, but that will be fixed (this week at the IETF, I hope). > > Harrie > > _______________________________________________ > diffserv mailing list > diffserv@ietf.org > http://www1.ietf.org/mailman/listinfo/diffserv > Archive: http://www2.ietf.org/mail-archive/working-groups/diffserv/current/maillist.html _______________________________________________ diffserv mailing list diffserv@ietf.org http://www1.ietf.org/mailman/listinfo/diffserv Archive: http://www2.ietf.org/mail-archive/working-groups/diffserv/current/maillist.html From diffserv-admin@ietf.org Tue Dec 12 15:53: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 SMTP id PAA08669 for ; Tue, 12 Dec 2000 15:53:16 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id PAA14400; Tue, 12 Dec 2000 15:24:07 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id PAA14374 for ; Tue, 12 Dec 2000 15:24:03 -0500 (EST) 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 PAA05203 for ; Tue, 12 Dec 2000 15:24:00 -0500 (EST) Received: from grubby.research.bell-labs.com ([135.104.2.9]) by dirty; Tue Dec 12 15:22:10 EST 2000 Received: from mail1.pa.bell-labs.com ([135.250.8.11]) by grubby; Tue Dec 12 15:22:10 EST 2000 Received: from research.bell-labs.com (ex-vpn68.pa.bell-labs.com [135.250.1.68]) by mail1.pa.bell-labs.com (Mirapoint) with ESMTP id AAW17476 (AUTH gja); Tue, 12 Dec 2000 12:22:07 -0800 (PST) Message-ID: <3A36893C.75EE736C@research.bell-labs.com> Date: Tue, 12 Dec 2000 12:23:24 -0800 From: Grenville Armitage Organization: Bell Labs Research Silicon Valley X-Mailer: Mozilla 4.61 [en] (WinNT; U) X-Accept-Language: en MIME-Version: 1.0 To: demir CC: diffserv@ietf.org Subject: Re: [Diffserv] need for clear definition of "assurance" in EF References: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: diffserv-admin@ietf.org Errors-To: diffserv-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Diffserv Discussion List X-BeenThere: diffserv@ietf.org Content-Transfer-Encoding: 7bit demir wrote: [..] > That is an "interesting" intention. It seems both AF and EF PHB have > already picked their "transport" protocol. No, they haven't. Bert is observing that the key behavior provided by AF is three levels of drop precedence (quite useful to TCP or TCP-like congestion control algorithms) while the behavior desired of EF is predictably bounded delay variance (useful for loss-intolerant or non-reactive apps). cheers, gja _______________________________________________ diffserv mailing list diffserv@ietf.org http://www1.ietf.org/mailman/listinfo/diffserv Archive: http://www2.ietf.org/mail-archive/working-groups/diffserv/current/maillist.html From diffserv-admin@ietf.org Tue Dec 12 16:24: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 SMTP id QAA12228 for ; Tue, 12 Dec 2000 16:24:14 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id QAA15380; Tue, 12 Dec 2000 16:04:56 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id QAA15353 for ; Tue, 12 Dec 2000 16:04:52 -0500 (EST) Received: from albatross-ext.wise.edt.ericsson.se (albatross-ext.wise.edt.ericsson.se [194.237.142.116]) by ietf.org (8.9.1a/8.9.1a) with SMTP id QAA09994 for ; Tue, 12 Dec 2000 16:04:48 -0500 (EST) Received: from era-t.ericsson.se (koff.ericsson.se [147.214.173.137]) by albatross.wise.edt.ericsson.se (8.11.0/8.11.0/WIREfire-1.3) with SMTP id eBCL4i401088; Tue, 12 Dec 2000 22:04:44 +0100 (MET) Received: from ericsson.com by era-t.ericsson.se (SMI-8.6/LME-DOM-2.2.5(ERA/T)) id WAA16530; Tue, 12 Dec 2000 22:04:42 +0100 Message-ID: <3A368B24.E40B1961@ericsson.com> Date: Tue, 12 Dec 2000 21:31:32 +0100 From: =?iso-8859-1?Q?B=F6rje?= Ohlman Organization: Ericsson X-Mailer: Mozilla 4.7 [en] (Win95; U) X-Accept-Language: en MIME-Version: 1.0 To: Brian E Carpenter CC: Yoram Bernet , diffserv@ietf.org Subject: Re: LBE PHB [was: [Diffserv] comments on the bulk handling draft] References: <3A356987.1453F7DE@hursley.ibm.com> Content-Type: text/plain; charset=iso-8859-1 X-MIME-Autoconverted: from quoted-printable to 8bit by optimus.ietf.org id QAA15354 Sender: diffserv-admin@ietf.org Errors-To: diffserv-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Diffserv Discussion List X-BeenThere: diffserv@ietf.org X-MIME-Autoconverted: from 8bit to quoted-printable by optimus.ietf.org id QAA15380 Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by ietf.org id QAA12228 Brian E Carpenter wrote: > As Kathie said today, the LBE name is no better chosen than > BH. Maybe we should call the new PDB "NCT" for Non-Critical Traffic? > I think Non-Critical Traffic is better than both of the previously suggested names. Another alternative which I find quite intuitive for this type of traffic would be "Background Traffic". Börje -- 
=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
Börje Ohlman               Tel.   +46- 8-508 780 95
KI/ERA/T/NI (Switchlab)    Mobil. +46-70-519 3187
Ericsson Research          Fax.   +46-70-616 3187
Torshamnsgatan 23 (Kista)  Mailto:Borje.Ohlman@ericsson.com
S-164 80 Stockholm         WWW:   http://switchlab.ericsson.se/~eraboje/
Sweden                               (only from within Ericsson)
                           Priv.: http://www.abc.se/~m10181




_______________________________________________
diffserv mailing list
diffserv@ietf.org
http://www1.ietf.org/mailman/listinfo/diffserv
Archive: http://www2.ietf.org/mail-archive/working-groups/diffserv/current/maillist.html



From diffserv-admin@ietf.org  Tue Dec 12 16:24: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 SMTP id QAA12256
	for ; Tue, 12 Dec 2000 16:24:26 -0500 (EST)
Received: from optimus.ietf.org (localhost [127.0.0.1])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id PAA15071;
	Tue, 12 Dec 2000 15:56:28 -0500 (EST)
Received: from ietf.org (odin [132.151.1.176])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id PAA15043
	for ; Tue, 12 Dec 2000 15:56:24 -0500 (EST)
Received: from usc.edu (root@usc.edu [128.125.253.136])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id PAA09018
	for ; Tue, 12 Dec 2000 15:56:21 -0500 (EST)
Received: from aludra.usc.edu (demir@aludra.usc.edu [128.125.253.184])
	by usc.edu (8.9.3.1/8.9.3/usc) with ESMTP
	id MAA19674; Tue, 12 Dec 2000 12:56:21 -0800 (PST)
Received: from localhost (demir@localhost)
	by aludra.usc.edu (8.9.3.1/8.9.3/usc) with ESMTP
	id MAA12017; Tue, 12 Dec 2000 12:56:21 -0800 (PST)
Date: Tue, 12 Dec 2000 12:56:21 -0800 (PST)
From: demir 
To: Grenville Armitage 
cc: diffserv@ietf.org
Subject: Re: [Diffserv] need for clear definition of "assurance" in EF
In-Reply-To: <3A36893C.75EE736C@research.bell-labs.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

Grenville,
I don't have any problem accepting the fact that what apps is more
suitable for what PHBs. My point was that it doesn't seem reasonable to
relate "transport" protocols to them. I agree, there is a trend on
that. It is a matter of choice that should be left to apps. I understand
your points.

Alper K. Demir


On Tue, 12 Dec 2000, Grenville Armitage wrote:

> 
> 
> demir wrote:
> 	[..]
> > That is an "interesting" intention. It seems both AF and EF PHB have
> > already picked their "transport" protocol.
> 
> No, they haven't. Bert is observing that the key behavior
> provided by AF is three levels of drop precedence (quite useful
> to TCP or TCP-like congestion control algorithms) while the behavior
> desired of EF is predictably bounded delay variance (useful for
> loss-intolerant or non-reactive apps).
> 
> cheers,
> gja
> 


_______________________________________________
diffserv mailing list
diffserv@ietf.org
http://www1.ietf.org/mailman/listinfo/diffserv
Archive: http://www2.ietf.org/mail-archive/working-groups/diffserv/current/maillist.html



From diffserv-admin@ietf.org  Tue Dec 12 16:24:54 2000
Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged))
	by ietf.org (8.9.1a/8.9.1a) with SMTP id QAA12311
	for ; Tue, 12 Dec 2000 16:24:49 -0500 (EST)
Received: from optimus.ietf.org (localhost [127.0.0.1])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id PAA15024;
	Tue, 12 Dec 2000 15:55:09 -0500 (EST)
Received: from ietf.org (odin [132.151.1.176])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id PAA14996
	for ; Tue, 12 Dec 2000 15:55:05 -0500 (EST)
Received: from diablo.cisco.com (diablo.cisco.com [171.68.224.210])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id PAA08870
	for ; Tue, 12 Dec 2000 15:55:02 -0500 (EST)
Received: from jschnizl1-pc (ssh-sj1.cisco.com [171.68.225.134]) by diablo.cisco.com (8.8.6 (PHNE_14041)/CISCO.SERVER.1.2) with SMTP id MAA10234; Tue, 12 Dec 2000 12:54:01 -0800 (PST)
Message-Id: <4.1.20001212154727.00a5f1b0@diablo.cisco.com>
X-Sender: jschnizl@localhost
X-Mailer: QUALCOMM Windows Eudora Pro Version 4.1 
Date: Tue, 12 Dec 2000 15:54:14 -0500
To: Anna Charny ,
        "Manfredi, Albert E" 
From: John Schnizlein 
Cc: diffserv@ietf.org
In-Reply-To: <4.3.2.7.2.20001212111604.00bb8100@pilgrim.cisco.com>
References: <4102273CEB77D211869200805FE6F593018C5BED@xch-phl-01.he.boe ing.com>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Subject: [Diffserv] EFRESOLVE S and number of inputs
Sender: diffserv-admin@ietf.org
Errors-To: diffserv-admin@ietf.org
X-Mailman-Version: 1.0
Precedence: bulk
List-Id: Diffserv Discussion List 
X-BeenThere: diffserv@ietf.org

At 11:52 AM 12/12/2000 -0500, Anna Charny wrote:
>... If we say that all EF traffic MUST get a deterministic worst 
>case jitter guarantee of a small number of packet intervals at its rate, we 
>need to make sure that 1) it is actually possible to achieve end-to-end 
>(which we do not know at the moment), and b) that the working group accepts 
>that you can only support an onerously small amount of  EF VoIP traffic in 
>large devices.

The basic idea of EF is that delay at a hop is bounded.
Other PHBs might be defined that have attractive properties for
voice.

The observation that a larger number of inputs for EF leads to
a larger S is accurate. Since S is not intended as a comparison
measure between devices with different numbers of inputs or
different burst capabilities, this is not a problem.

It should also be noted that devices with on the order of 1000
inputs ususally have smaller rates on those inputs than on the
(trunk) output.

The WG need not say how onerously small the EF rates are for 
a device, the conformance claim just states what S for what
rate and burst capacity the device supports. 

John

_______________________________________________
diffserv mailing list
diffserv@ietf.org
http://www1.ietf.org/mailman/listinfo/diffserv
Archive: http://www2.ietf.org/mail-archive/working-groups/diffserv/current/maillist.html



From diffserv-admin@ietf.org  Tue Dec 12 16:37: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 SMTP id QAA14646
	for ; Tue, 12 Dec 2000 16:37:29 -0500 (EST)
Received: from optimus.ietf.org (localhost [127.0.0.1])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id QAA15758;
	Tue, 12 Dec 2000 16:20:15 -0500 (EST)
Received: from ietf.org (odin [132.151.1.176])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id QAA15648
	for ; Tue, 12 Dec 2000 16:20:07 -0500 (EST)
Received: from lisanza.net (ietf.207.137.74.155.tx.verio.net [207.137.74.155])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id QAA11754;
	Tue, 12 Dec 2000 16:20:04 -0500 (EST)
Received: from covalent.net (localhost [127.0.0.1])
	by lisanza.net (8.9.3/8.9.3) with ESMTP id FAA00692;
	Tue, 12 Dec 2000 05:18:48 -0800 (PST)
	(envelope-from harrie@covalent.net)
Message-ID: <3A3625B8.CA6F6426@covalent.net>
Date: Tue, 12 Dec 2000 05:18:48 -0800
From: Harrie Hazewinkel 
Organization: Covalent Technologies
X-Mailer: Mozilla 4.73 [en] (X11; I; FreeBSD 4.1-RELEASE i386)
X-Accept-Language: en
MIME-Version: 1.0
To: Andy Bierman 
CC: rmonmib@ietf.org, diffserv@ietf.org
Subject: Re: [RMONMIB] Re: [Diffserv] The DsCodePoint definition
References: <3A3547FC.8E393EBD@covalent.net> <3A368594.A68F9240@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

Andy Bierman wrote:
> 
> Harrie Hazewinkel wrote:
> >
> > HI,
> >
> > I was wondering why there is a difference between
> > 2 definitions of the DiffServ CodePoint in different
> > MIB modules. The two different MIMB modules are
> > the DIFFSERV-MIB (of diffserv) and the DSMON-MIB (of RMON).
> >
> > I beleive these 2 TCs should be the same and taken from the
> > DIFFSERV-MIB, because that is from the diffserv WG.
> >
> > ----------- From the DIFFSERV-MIB (draft 05) -----------------
> > Dscp ::= TEXTUAL-CONVENTION
> >     DISPLAY-HINT "d"
> >     STATUS   current
> >     DESCRIPTION
> >        "The IP header Diffserv Code-Point that may  be  used
> >        for  discriminating or marking a traffic stream.  The
> >        value  -1  ( 4294967295 for Integer32 )  is  used  to
> >        indicate a wildcard i.e. any value."
> >     SYNTAX   Integer32 (4294967295 | 0..63)
> 
> just noticed how broken this TC is...
>  1) an Integer32 object cannot contain the value 4294967295
>  2) missing REFERENCE clause
>     (where exactly in 2474 is the 'wildcard' DSCP value discussed?)

Correct, it is broken and already mentioned on the diffserv mailinglist.
That is also why I added the folling below (I quote here);
"OK, I will admit the definition of the DiffServ-MIB is currently
 broken, but that will be fixed (this week at the IETF, I hope)."

Harrie
 
> Andy
> 
> > --------------------------------------------------------------
> >
> > ------------ From the DSMON-MIB (draft 03) -------------------
> > DsmonDSCodePoint ::= TEXTUAL-CONVENTION
> >     STATUS current
> >     DESCRIPTION
> >             "This TC describes an object which identifies the
> >             Differentiated Services Codepoint (DSCP) value found within
> >             the DS field in a network layer packet header (e.g., IPv4
> >             and IPv6)."
> >     REFERENCE
> >             "Definition of the Differentiated Services Field (DS Field)
> >             in the IPv4 and IPv6 Headers [RFC2474]."
> >     SYNTAX Integer32 (0..63)
> > --------------------------------------------------------------
> >
> > OK, I will admit the definition of the DiffServ-MIB is currently
> > broken, but that will be fixed (this week at the IETF, I hope).
> >
> > Harrie
> >
> > _______________________________________________
> > diffserv mailing list
> > diffserv@ietf.org
> > http://www1.ietf.org/mailman/listinfo/diffserv
> > Archive: http://www2.ietf.org/mail-archive/working-groups/diffserv/current/maillist.html
> 
> _______________________________________________
> RMONMIB mailing list
> RMONMIB@ietf.org
> http://www.ietf.org/mailman/listinfo/rmonmib

_______________________________________________
diffserv mailing list
diffserv@ietf.org
http://www1.ietf.org/mailman/listinfo/diffserv
Archive: http://www2.ietf.org/mail-archive/working-groups/diffserv/current/maillist.html



From diffserv-admin@ietf.org  Tue Dec 12 16:38: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 SMTP id QAA14743
	for ; Tue, 12 Dec 2000 16:37:58 -0500 (EST)
Received: from optimus.ietf.org (localhost [127.0.0.1])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id QAA15616;
	Tue, 12 Dec 2000 16:18:07 -0500 (EST)
Received: from ietf.org (odin [132.151.1.176])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id QAA15577
	for ; Tue, 12 Dec 2000 16:18:02 -0500 (EST)
Received: from lisanza.net (ietf.207.137.74.155.tx.verio.net [207.137.74.155])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id QAA11512;
	Tue, 12 Dec 2000 16:17:59 -0500 (EST)
Received: from covalent.net (localhost [127.0.0.1])
	by lisanza.net (8.9.3/8.9.3) with ESMTP id FAA00683;
	Tue, 12 Dec 2000 05:16:44 -0800 (PST)
	(envelope-from harrie@covalent.net)
Message-ID: <3A36253C.57E80E04@covalent.net>
Date: Tue, 12 Dec 2000 05:16:44 -0800
From: Harrie Hazewinkel 
Organization: Covalent Technologies
X-Mailer: Mozilla 4.73 [en] (X11; I; FreeBSD 4.1-RELEASE i386)
X-Accept-Language: en
MIME-Version: 1.0
To: Andy Bierman 
CC: rmonmib@ietf.org, diffserv@ietf.org
Subject: Re: [Diffserv] The DsCodePoint definition
References: <3A3547FC.8E393EBD@covalent.net> <3A3681EA.B2C42C8@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

Andy Bierman wrote:
> 
> Harrie Hazewinkel wrote:
> >
> > HI,
> >
> > I was wondering why there is a difference between
> > 2 definitions of the DiffServ CodePoint in different
> > MIB modules. The two different MIMB modules are
> > the DIFFSERV-MIB (of diffserv) and the DSMON-MIB (of RMON).
> >
> > I beleive these 2 TCs should be the same and taken from the
> > DIFFSERV-MIB, because that is from the diffserv WG.
> 
> But the TCs are obviously designed for different purposes.
> The DSMON TC represents the actual values that the DSCP field
> may contain. There is no need for a value of -1, typecast
> as the value 2G-1. The extra semantics would break the DSMON
> MIB aggregation control tables.

I know RMON does not need this -1 value, but it is my understanding
one can still use the TC with the (-1 | 0..63) range of values.
In RMON then you may use the TC and subtype it towards (0..63)
which solves this problem.

> 
> Andy
> 
> >
> > ----------- From the DIFFSERV-MIB (draft 05) -----------------
> > Dscp ::= TEXTUAL-CONVENTION
> >     DISPLAY-HINT "d"
> >     STATUS   current
> >     DESCRIPTION
> >        "The IP header Diffserv Code-Point that may  be  used
> >        for  discriminating or marking a traffic stream.  The
> >        value  -1  ( 4294967295 for Integer32 )  is  used  to
> >        indicate a wildcard i.e. any value."
> >     SYNTAX   Integer32 (4294967295 | 0..63)
> > --------------------------------------------------------------
> >
> > ------------ From the DSMON-MIB (draft 03) -------------------
> > DsmonDSCodePoint ::= TEXTUAL-CONVENTION
> >     STATUS current
> >     DESCRIPTION
> >             "This TC describes an object which identifies the
> >             Differentiated Services Codepoint (DSCP) value found within
> >             the DS field in a network layer packet header (e.g., IPv4
> >             and IPv6)."
> >     REFERENCE
> >             "Definition of the Differentiated Services Field (DS Field)
> >             in the IPv4 and IPv6 Headers [RFC2474]."
> >     SYNTAX Integer32 (0..63)
> > --------------------------------------------------------------
> >
> > OK, I will admit the definition of the DiffServ-MIB is currently
> > broken, but that will be fixed (this week at the IETF, I hope).
> >
> > Harrie
> >
> > _______________________________________________
> > diffserv mailing list
> > diffserv@ietf.org
> > http://www1.ietf.org/mailman/listinfo/diffserv
> > Archive: http://www2.ietf.org/mail-archive/working-groups/diffserv/current/maillist.html
> 
> _______________________________________________
> diffserv mailing list
> diffserv@ietf.org
> http://www1.ietf.org/mailman/listinfo/diffserv
> Archive: http://www2.ietf.org/mail-archive/working-groups/diffserv/current/maillist.html

_______________________________________________
diffserv mailing list
diffserv@ietf.org
http://www1.ietf.org/mailman/listinfo/diffserv
Archive: http://www2.ietf.org/mail-archive/working-groups/diffserv/current/maillist.html



From diffserv-admin@ietf.org  Tue Dec 12 16:39: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 SMTP id QAA15041
	for ; Tue, 12 Dec 2000 16:39:17 -0500 (EST)
Received: from optimus.ietf.org (localhost [127.0.0.1])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id QAB15812;
	Tue, 12 Dec 2000 16:21:43 -0500 (EST)
Received: from ietf.org (odin [132.151.1.176])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id QAA15783
	for ; Tue, 12 Dec 2000 16:21:37 -0500 (EST)
Received: from web4205.mail.yahoo.com (web4205.mail.yahoo.com [216.115.104.138])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id QAA11932
	for ; Tue, 12 Dec 2000 16:21:36 -0500 (EST)
From: g_mercankosk@yahoo.com
Message-ID: <20001212212107.25905.qmail@web4205.mail.yahoo.com>
Received: from [207.137.71.20] by web4205.mail.yahoo.com; Tue, 12 Dec 2000 13:21:07 PST
Date: Tue, 12 Dec 2000 13:21:07 -0800 (PST)
Subject: RE: [Diffserv] Possible compromise between EFRESOLVE and draft-ch   arny
To: ROBERTS James FTRD/DAC/ISS ,
        diffserv@ietf.org
Cc: guven@ee.uwa.edu.au
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


Jim,

> 
> I was referring to the calculation of worst case
> burstiness necessary to
> define deterministic bounds. Rereading your draft
> from July, I imagine you
> are thinking more in terms of probabilistic bounds,
> eg, the probability end
> to end delay is greater some bound D should not
> exceed epsilon. I would
> certainly agree that this is a more satisfactory
> approach.

May be that design team should seriously consider this
approach.

> However, even here, I don't think it is possible to
> characterize burstiness
> at interfaces within the network. At least not in
> terms of maximally sized
> bursts or an envelope arrival function like that
> defined by a token bucket. 
> 
> This was a problem considered in the context of ATM
> where CBR connections
> are characterized in terms of the GCRA (almost a
> token bucket). I am not
> aware of any work successfully explaining how the
> GCRA parameters should
> evolve as the CBR stream acquires burstiness along
> its path through the
> network. This is an unsolved problem.

First consider just one hop. Couldn't we simply set
the GCRA parameters as the reciprocal of  the stream
rate and the D as the tolerance? The probability that 
a given packet not complying be less than epsilon. At
multiple hops, determine the corresponding delay bound
and used that as a tolerance. Is there anything 
wrong with this thinking?
 
> In your draft, if my interpretation is correct, you
> assume the acquired
> burstiness is negligible in the sense that you can
> assume (M+D)/D/1 queuing
> at any node to derive the statistical delay bound.
> In this way you do not
> need to characterize burstiness in a quantifiable
> way. I am inclined to
> agree with you and we have some work which claims
> more or less the same
> thing. 

But when all micro-flows are properly controled at the
ingress, and say that they are spaced, any burstiness
is due to phase coincidences. Under the circumstances
why do we have to need to characterize the burstiness.
I do like calling this burstiness. I rather refer to
it as jitter accumulation. I suppose you refer to it
as negligible. Given my previous argument, we have a
characterization of it anyway.

In the case of the superposition of periodic arrivals
with FIFO queueing, the maximum delay is the number of
sources competing times one packet transmission time.
Irrespective of whether they are homogeneous or
heterogeneous. The former case will always have a
larger bound than the latter. Again this is over one 
hop. Now if we split the aggregate at the next hop in
such a way that a given micro flow now competes with a
new set of micro flows at the next hop, the maximum
delay over two hops can only be increased by the
number of micro flows joining in. Does this not give
us a deterministic characterization of burstiness? I
would like to conjecture that even when multiple micro
flows split together the maximum delay will not be
increased any more than the number of micro flows
joining in. I could see that this could have an impact
on the streams just joining in, in the sense that
their delay could be larger than the case of a single
hop. However, if you look at the example in Appendix F
of my draft, when the test stream takes lesser number
of hops its delay distribution actually gets better.
This may not be the exact answer you are looking for
but it may trigger some thoughts.
 
> To justify your probabilistic arguments you assume
> first that the EF
> aggregates only interfere with each other in FIFO
> queues. You then consider
> the impact of non-EF packets assuming priority
> queuing. It seems to me
> therefore that you should be agreeing with me that
> an EF PHB definition
> allowing a clear expression of these assumptions is
> preferable to one which
> relies on an unspecified characterization of
> burstiness in order to justify
> deterministic bounds.
>

I am all for such clarification. I am really amazed
how we can make things more convoluted than necessary
:-)

Cheers,
Guven.



__________________________________________________
Do You Yahoo!?
Yahoo! Shopping - Thousands of Stores. Millions of Products.
http://shopping.yahoo.com/

_______________________________________________
diffserv mailing list
diffserv@ietf.org
http://www1.ietf.org/mailman/listinfo/diffserv
Archive: http://www2.ietf.org/mail-archive/working-groups/diffserv/current/maillist.html



From diffserv-admin@ietf.org  Tue Dec 12 17:03: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 SMTP id RAA20163
	for ; Tue, 12 Dec 2000 17:03:14 -0500 (EST)
Received: from optimus.ietf.org (localhost [127.0.0.1])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id QAA16330;
	Tue, 12 Dec 2000 16:40:15 -0500 (EST)
Received: from ietf.org (odin [132.151.1.176])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id QAA16297
	for ; Tue, 12 Dec 2000 16:40:11 -0500 (EST)
Received: from pilgrim.cisco.com (pilgrim.cisco.com [171.69.204.12])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id QAA15255
	for ; Tue, 12 Dec 2000 16:40:09 -0500 (EST)
Received: from acharny-nt.cisco.com (sj-dial-3-86.cisco.com [171.68.180.87])
	by pilgrim.cisco.com (8.8.8-Cisco List Logging/8.8.8) with ESMTP id QAA04480;
	Tue, 12 Dec 2000 16:39:03 -0500 (EST)
Message-Id: <4.3.2.7.2.20001212161917.00c8f2e0@pilgrim.cisco.com>
X-Sender: acharny@pilgrim.cisco.com
X-Mailer: QUALCOMM Windows Eudora Version 4.3.2
Date: Tue, 12 Dec 2000 16:44:44 -0500
To: John Schnizlein , Anna Charny ,
        "Manfredi, Albert E" 
From: Anna Charny 
Cc: diffserv@ietf.org
In-Reply-To: <4.1.20001212154727.00a5f1b0@diablo.cisco.com>
References: <4.3.2.7.2.20001212111604.00bb8100@pilgrim.cisco.com>
 <4102273CEB77D211869200805FE6F593018C5BED@xch-phl-01.he.boe ing.com>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"; format=flowed
Subject: [Diffserv] Re: EFRESOLVE S and number of inputs
Sender: diffserv-admin@ietf.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:54 PM 12/12/00 -0500, John Schnizlein wrote:
>At 11:52 AM 12/12/2000 -0500, Anna Charny wrote:
> >... If we say that all EF traffic MUST get a deterministic worst
> >case jitter guarantee of a small number of packet intervals at its rate, we
> >need to make sure that 1) it is actually possible to achieve end-to-end
> >(which we do not know at the moment), and b) that the working group accepts
> >that you can only support an onerously small amount of  EF VoIP traffic in
> >large devices.
>
>The basic idea of EF is that delay at a hop is bounded.
>Other PHBs might be defined that have attractive properties for
>voice.
>
>The observation that a larger number of inputs for EF leads to
>a larger S is accurate. Since S is not intended as a comparison
>measure between devices with different numbers of inputs or
>different burst capabilities, this is not a problem.

I heard Joel say on the list that S is a comparative measure at some point.
Has this changed? Is there any consensus on this within EFRESOLVE now?

>It should also be noted that devices with on the order of 1000
>inputs ususally have smaller rates on those inputs than on the
>(trunk) output.

But there is hardly a requirement that no EF traffic can go between lo 
speed interfaces, is there?  There is also no requirement that such a box 
cannot be used as a high speed interconnect of identical links.

>The WG need not say how onerously small the EF rates are for
>a device, the conformance claim just states what S for what
>rate and burst capacity the device supports.

The WG may not need to say in the PHB definition how much EF traffic can be 
supported, but it most certainly should be aware of the consequences of 
what a particular definition has.  The fact that you can support only a 
tiny fraction of your capacity dedicated to EF to get a small S in a large 
device seems to be one of those consequences that need to be spelled out.

Also,  if having a small or large S does not tell you anything useful, then 
I am not sure what you can usefully say about such a device.  Sure, I can 
do conformance testing on it, but why would I care if S tells me 
nothing?  I would assume one would only want to test conformance of 
something that actually is important?

Anna

>John


---------------------------------------
Anna Charny
Cisco Systems, Inc
300 Apollo Drive
Chelmsford, MA  01824
Tel. (978)-244-8172
Fax (978)-244-8126


_______________________________________________
diffserv mailing list
diffserv@ietf.org
http://www1.ietf.org/mailman/listinfo/diffserv
Archive: http://www2.ietf.org/mail-archive/working-groups/diffserv/current/maillist.html



From diffserv-admin@ietf.org  Tue Dec 12 17:19: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 SMTP id RAA23552
	for ; Tue, 12 Dec 2000 17:19:01 -0500 (EST)
Received: from optimus.ietf.org (localhost [127.0.0.1])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id QAA16646;
	Tue, 12 Dec 2000 16:54:39 -0500 (EST)
Received: from ietf.org (odin [132.151.1.176])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id QAA16620
	for ; Tue, 12 Dec 2000 16:54:35 -0500 (EST)
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 SMTP id QAA18310
	for ; Tue, 12 Dec 2000 16:54:33 -0500 (EST)
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 PAA08460
	for ; Tue, 12 Dec 2000 15:54:32 -0600 (CST)
Received: from stl-hub-01.boeing.com (localhost [127.0.0.1])
	by stl-av-01.boeing.com (8.9.3/8.9.2) with ESMTP id PAA04685
	for ; Tue, 12 Dec 2000 15:54:24 -0600 (CST)
Received: from xch-phlbh-01.he.boeing.com by stl-hub-01.boeing.com with ESMTP; Tue, 12 Dec 2000 15:54:19 -0600
Received: by xch-phlbh-01.he.boeing.com with Internet Mail Service (5.5.2650.21)
	id ; Tue, 12 Dec 2000 16:54:18 -0500
Message-Id: <4102273CEB77D211869200805FE6F593018C5BF4@xch-phl-01.he.boeing.com>
From: "Manfredi, Albert E" 
To: "'demir'" 
Cc: diffserv@ietf.org
Subject: RE: [Diffserv] need for clear definition of "assurance" in EF
Date: Tue, 12 Dec 2000 16:54:17 -0500
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2650.21)
Content-Type: text/plain;
	charset="iso-8859-1"
Sender: diffserv-admin@ietf.org
Errors-To: diffserv-admin@ietf.org
X-Mailman-Version: 1.0
Precedence: bulk
List-Id: Diffserv Discussion List 
X-BeenThere: diffserv@ietf.org

Alper Demir wrote:

> Grenville Armitage wrote concisely:
>
> > the key behavior
> > provided by AF is three levels of drop precedence (quite useful
> > to TCP or TCP-like congestion control algorithms) while the behavior
> > desired of EF is predictably bounded delay variance (useful for
> > loss-intolerant or non-reactive apps).
>
> Grenville,
> I don't have any problem accepting the fact that what apps is more
> suitable for what PHBs. My point was that it doesn't seem 
> reasonable to
> relate "transport" protocols to them. I agree, there is a trend on
> that. It is a matter of choice that should be left to apps. I 
> understand
> your points.

I'm not so sure, Demir. It's virtually impossible for me to justify the
existence of EF separately from AF unless we have this Transport difference
as motivation. But with that motivation, the features required from EF, and
its purpose in life, become self evident. Not sure why you resist this?

In fact, EF also provides the protection to the rest of network traffic from
non-responsive traffic that Yoram Bernet was talking about in his recent
post.

And I would again suggest that a possible addition to EF, as in a second EF
class, would be to allow for some additional deterministic delay to the d(j)
- e(j) value.

So one class would offer the bounded delay variance with only propagation
delay and minimal, non-queue-related node delay as deterministic (minimum)
delay values, while the second class might add some deterministic queue
times to this.

Bert

_______________________________________________
diffserv mailing list
diffserv@ietf.org
http://www1.ietf.org/mailman/listinfo/diffserv
Archive: http://www2.ietf.org/mail-archive/working-groups/diffserv/current/maillist.html



From diffserv-admin@ietf.org  Tue Dec 12 17:40:44 2000
Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged))
	by ietf.org (8.9.1a/8.9.1a) with SMTP id RAA27838
	for ; Tue, 12 Dec 2000 17:40:39 -0500 (EST)
Received: from optimus.ietf.org (localhost [127.0.0.1])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id RAA17442;
	Tue, 12 Dec 2000 17:18:26 -0500 (EST)
Received: from ietf.org (odin [132.151.1.176])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id RAA17411
	for ; Tue, 12 Dec 2000 17:18:21 -0500 (EST)
Received: from procyon.pmc-sierra.bc.ca (procyon.pmc-sierra.bc.ca [134.87.115.1])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id RAA23410
	for ; Tue, 12 Dec 2000 17:18:19 -0500 (EST)
Received: from bby1exi01.pmc-sierra.bc.ca (bby1exi01.pmc-sierra.bc.ca [216.241.231.251])
	by procyon.pmc-sierra.bc.ca (6.6.6/6.6.6) with ESMTP id OAA02102;
	Tue, 12 Dec 2000 14:16:01 -0800 (PST)
Received: by bby1exi01.pmc-sierra.bc.ca with Internet Mail Service (5.5.2650.21)
	id ; Tue, 12 Dec 2000 14:16:38 -0800
Message-ID: <9DC5E2ABE65BD54CA9088DA3194461D6010C9AF2@BBY1EXM01>
From: Shahram Davari 
To: "'Andrew Smith'" ,
        Brian E Carpenter
	 
Cc: "'diffserv@ietf.org'" 
Subject: RE: [Diffserv] Token bucket suggestion in Diffserv Model draft
Date: Tue, 12 Dec 2000 14:16:25 -0800
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2650.21)
Content-Type: text/plain
Sender: diffserv-admin@ietf.org
Errors-To: diffserv-admin@ietf.org
X-Mailman-Version: 1.0
Precedence: bulk
List-Id: Diffserv Discussion List 
X-BeenThere: diffserv@ietf.org

Hi Andrew,

Please let me know which specific parts are confusing so that I could clear them up.

Yours,
_Shahram 

> -----Original Message-----
> From: Andrew Smith [mailto:andrew@allegronetworks.com]
> Sent: Tuesday, December 12, 2000 12:26 PM
> To: Brian E Carpenter
> Cc: 'diffserv@ietf.org'
> Subject: Re: [Diffserv] Token bucket suggestion in Diffserv 
> Model draft
> 
> 
> I prefer strict/loose (but I'll go with the flow if the WG 
> wants to change it).
> 
> Regarding Shahram's proposed re-wording: I need to parse it 
> further but on first 
> read, parts of it seem more confused than before (in 
> particular, confusion 
> whether some "either/or" pairs refer to (a) implementation 
> options or (b) to 
> choices made in the behaviour of a given implementation). 
> Detailed comments to 
> follow.
> 
> Can someone please summarise what the WG meeting agreed to 
> w.r.t. this document? 
> My apologies for not having been there ...
> 
> 
> Andrew
> (Model draft editor - still)
> 
> 
> Brian E Carpenter wrote:
> 
> > Shahram,
> > 
> > Thanks for all the suggested text. I will leave the 
> document editor to
> > decide how much of it he adopts - I hadn't expected so much 
> change from today's
> > discussion. 
> > 
> > As for the terminology change from "strict/loose" to 
> > "positive-count/negative-count", we would need a consensus 
> for that. 
> > WG comments are welcome.
> > 
> > Thanks
> >   Brian
> 
> 
> _______________________________________________
> diffserv mailing list
> diffserv@ietf.org
> http://www1.ietf.org/mailman/listinfo/diffserv
> Archive: 
> http://www2.ietf.org/mail-archive/working-groups/diffserv/curr
ent/maillist.html

_______________________________________________
diffserv mailing list
diffserv@ietf.org
http://www1.ietf.org/mailman/listinfo/diffserv
Archive: http://www2.ietf.org/mail-archive/working-groups/diffserv/current/maillist.html



From diffserv-admin@ietf.org  Tue Dec 12 17:48: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 SMTP id RAA28720
	for ; Tue, 12 Dec 2000 17:48:07 -0500 (EST)
Received: from optimus.ietf.org (localhost [127.0.0.1])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id RAA17400;
	Tue, 12 Dec 2000 17:17:48 -0500 (EST)
Received: from ietf.org (odin [132.151.1.176])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id RAA17367
	for ; Tue, 12 Dec 2000 17:17:43 -0500 (EST)
Received: from procyon.pmc-sierra.bc.ca (procyon.pmc-sierra.bc.ca [134.87.115.1])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id RAA23275
	for ; Tue, 12 Dec 2000 17:17:41 -0500 (EST)
Received: from bby1exi01.pmc-sierra.bc.ca (bby1exi01.pmc-sierra.bc.ca [216.241.231.251])
	by procyon.pmc-sierra.bc.ca (6.6.6/6.6.6) with ESMTP id OAA01649;
	Tue, 12 Dec 2000 14:14:23 -0800 (PST)
Received: by bby1exi01.pmc-sierra.bc.ca with Internet Mail Service (5.5.2650.21)
	id ; Tue, 12 Dec 2000 14:15:00 -0800
Message-ID: <9DC5E2ABE65BD54CA9088DA3194461D6010C9AF1@BBY1EXM01>
From: Shahram Davari 
To: "'Brian E Carpenter'" ,
        "'diffserv@ietf.org'"
	 
Subject: RE: [Diffserv] Token bucket suggestion in Diffserv Model draft
Date: Tue, 12 Dec 2000 14:15:00 -0800
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2650.21)
Content-Type: text/plain
Sender: diffserv-admin@ietf.org
Errors-To: diffserv-admin@ietf.org
X-Mailman-Version: 1.0
Precedence: bulk
List-Id: Diffserv Discussion List 
X-BeenThere: diffserv@ietf.org

Hi Brian,

In my proposed text I actually did 3 things:

1)little editorial change of relevant sections to remove any bias toward any type of TB.

2) Combined bullet 1,2 of the characteristics of strict TB, because they were talking about the same limitation.

3) Added 3 bullets about the characteristics of loose TB.


Yours,
-Shahram

> -----Original Message-----
> From: Brian E Carpenter [mailto:brian@hursley.ibm.com]
> Sent: Monday, December 11, 2000 11:01 PM
> To: 'diffserv@ietf.org'
> Subject: Re: [Diffserv] Token bucket suggestion in Diffserv 
> Model draft
> 
> 
> Shahram,
> 
> Thanks for all the suggested text. I will leave the document editor to
> decide how much of it he adopts - I hadn't expected so much 
> change from today's
> discussion. 
> 
> As for the terminology change from "strict/loose" to 
> "positive-count/negative-count", we would need a consensus for that. 
> WG comments are welcome.
> 
> Thanks
>   Brian
> 
> _______________________________________________
> diffserv mailing list
> diffserv@ietf.org
> http://www1.ietf.org/mailman/listinfo/diffserv
> Archive: 
> http://www2.ietf.org/mail-archive/working-groups/diffserv/curr
ent/maillist.html
> 

_______________________________________________
diffserv mailing list
diffserv@ietf.org
http://www1.ietf.org/mailman/listinfo/diffserv
Archive: http://www2.ietf.org/mail-archive/working-groups/diffserv/current/maillist.html



From diffserv-admin@ietf.org  Tue Dec 12 17:55:54 2000
Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged))
	by ietf.org (8.9.1a/8.9.1a) with SMTP id RAA29618
	for ; Tue, 12 Dec 2000 17:55:53 -0500 (EST)
Received: from optimus.ietf.org (localhost [127.0.0.1])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id RAA18085;
	Tue, 12 Dec 2000 17:36:06 -0500 (EST)
Received: from ietf.org (odin [132.151.1.176])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id RAA18054
	for ; Tue, 12 Dec 2000 17:36:01 -0500 (EST)
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 RAA27100
	for ; Tue, 12 Dec 2000 17:35:59 -0500 (EST)
Received: from scummy.research.bell-labs.com ([135.104.2.10]) by dirty; Tue Dec 12 17:34:17 EST 2000
Received: from mail1.pa.bell-labs.com ([135.250.8.11]) by scummy; Tue Dec 12 17:34:16 EST 2000
Received: from research.bell-labs.com (ex-vpn68.pa.bell-labs.com [135.250.1.68])
	by mail1.pa.bell-labs.com (Mirapoint)
	with ESMTP id AAW17720 (AUTH gja);
	Tue, 12 Dec 2000 14:34:13 -0800 (PST)
Message-ID: <3A36A831.9C16790D@research.bell-labs.com>
Date: Tue, 12 Dec 2000 14:35:29 -0800
From: Grenville Armitage 
Organization: Bell Labs Research Silicon Valley
X-Mailer: Mozilla 4.61 [en] (WinNT; U)
X-Accept-Language: en
MIME-Version: 1.0
To: diffserv@ietf.org
Subject: Re: [Diffserv] Re: EFRESOLVE S and number of inputs
References: <4.3.2.7.2.20001212111604.00bb8100@pilgrim.cisco.com>
	 <4102273CEB77D211869200805FE6F593018C5BED@xch-phl-01.he.boe ing.com> <4.3.2.7.2.20001212161917.00c8f2e0@pilgrim.cisco.com>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Content-Transfer-Encoding: 7bit
Sender: diffserv-admin@ietf.org
Errors-To: diffserv-admin@ietf.org
X-Mailman-Version: 1.0
Precedence: bulk
List-Id: Diffserv Discussion List 
X-BeenThere: diffserv@ietf.org
Content-Transfer-Encoding: 7bit



Anna Charny wrote:
> 
> At 03:54 PM 12/12/00 -0500, John Schnizlein wrote:
	[..]
> >The observation that a larger number of inputs for EF leads to
> >a larger S is accurate. Since S is not intended as a comparison
> >measure between devices with different numbers of inputs or
> >different burst capabilities, this is not a problem.
> 
> I heard Joel say on the list that S is a comparative measure at some point.
> Has this changed? Is there any consensus on this within EFRESOLVE now?

Nothing has changed, and John's complete sentence is consistent
with Joel's observation. 'S' can be a comparative measure within a
specified context - a context that includes the number of inputs
under discussion.

cheers,
gja

_______________________________________________
diffserv mailing list
diffserv@ietf.org
http://www1.ietf.org/mailman/listinfo/diffserv
Archive: http://www2.ietf.org/mail-archive/working-groups/diffserv/current/maillist.html



From diffserv-admin@ietf.org  Tue Dec 12 18:08: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 SMTP id SAA01332
	for ; Tue, 12 Dec 2000 18:08:59 -0500 (EST)
Received: from optimus.ietf.org (localhost [127.0.0.1])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id RAA18006;
	Tue, 12 Dec 2000 17:33:59 -0500 (EST)
Received: from ietf.org (odin [132.151.1.176])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id RAA17977
	for ; Tue, 12 Dec 2000 17:33:55 -0500 (EST)
Received: from longsys.com (dmz.longsys.com [63.111.150.5])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id RAA26675
	for ; Tue, 12 Dec 2000 17:33:53 -0500 (EST)
Received: from joel (discordian.longsys.com [63.111.150.74])
	by longsys.com (8.10.0/8.10.0) with ESMTP id eBCMXpQ22106;
	Tue, 12 Dec 2000 22:33:51 GMT
Message-Id: <4.2.2.20001212173017.00b55380@localhost>
X-Sender: joel@localhost
X-Mailer: QUALCOMM Windows Eudora Pro Version 4.2.2 
Date: Tue, 12 Dec 2000 17:31:31 -0500
To: Anna Charny 
From: "Joel M. Halpern" 
Subject: Re: [Diffserv] Re: EFRESOLVE S and number of inputs
Cc: diffserv@ietf.org
In-Reply-To: <4.3.2.7.2.20001212161917.00c8f2e0@pilgrim.cisco.com>
References: <4.1.20001212154727.00a5f1b0@diablo.cisco.com>
 <4.3.2.7.2.20001212111604.00bb8100@pilgrim.cisco.com>
 <4102273CEB77D211869200805FE6F593018C5BED@xch-phl-01.he.boe ing.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

What I said is that for a given topology, S can be used to compare 
devices.  Even then, depending upon the usage one is making, it may be 
sufficient that S is less than some limit, or it may be that lower S is better.
The fact that this depends upon usage is why I have trouble with the 
argument about whether S is or is not a figure of merit.

Yours,
Joel M. Halpern

At 04:44 PM 12/12/00 -0500, Anna Charny wrote:
>I heard Joel say on the list that S is a comparative measure at some point.
>Has this changed? Is there any consensus on this within EFRESOLVE now?


_______________________________________________
diffserv mailing list
diffserv@ietf.org
http://www1.ietf.org/mailman/listinfo/diffserv
Archive: http://www2.ietf.org/mail-archive/working-groups/diffserv/current/maillist.html



From diffserv-admin@ietf.org  Tue Dec 12 18:12: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 SMTP id SAA01807
	for ; Tue, 12 Dec 2000 18:12:33 -0500 (EST)
Received: from optimus.ietf.org (localhost [127.0.0.1])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id RAA18223;
	Tue, 12 Dec 2000 17:40:10 -0500 (EST)
Received: from ietf.org (odin [132.151.1.176])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id RAA18186
	for ; Tue, 12 Dec 2000 17:40:05 -0500 (EST)
Received: from mailhub1.almaden.ibm.com (mailhub1.almaden.ibm.com [198.4.83.44])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id RAA27765;
	Tue, 12 Dec 2000 17:40:03 -0500 (EST)
Received: from maui.almaden.ibm.com (maui.almaden.ibm.com [9.1.24.92])
	by mailhub1.almaden.ibm.com (8.8.8/8.8.8) with ESMTP id OAA35738;
	Tue, 12 Dec 2000 14:36:57 -0800
Received: from hursley.ibm.com (gsine01.us.sine.ibm.com [9.14.6.41]) by maui.almaden.ibm.com (AIX4.3/8.9.3/8.7) with ESMTP id OAA20524; Tue, 12 Dec 2000 14:39:32 -0800
Message-ID: <3A36A6CE.2A280514@hursley.ibm.com>
Date: Tue, 12 Dec 2000 16:29:34 -0600
From: Brian E Carpenter 
Organization: IBM
X-Mailer: Mozilla 4.61 [en] (Win98; I)
X-Accept-Language: en,fr
MIME-Version: 1.0
To: Harrie Hazewinkel 
CC: Andy Bierman , rmonmib@ietf.org, diffserv@ietf.org
Subject: Re: [RMONMIB] Re: [Diffserv] The DsCodePoint definition
References: <3A3547FC.8E393EBD@covalent.net> <3A368594.A68F9240@cisco.com> <3A3625B8.CA6F6426@covalent.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

Harrie Hazewinkel wrote:
> 
> Andy Bierman wrote:
...
> >     (where exactly in 2474 is the 'wildcard' DSCP value discussed?)

It isn't and I can't see any reason why it would need to be. It's something
needed in the management of diffserv, so it is nothing to do with the
basic model.

  Brian


_______________________________________________
diffserv mailing list
diffserv@ietf.org
http://www1.ietf.org/mailman/listinfo/diffserv
Archive: http://www2.ietf.org/mail-archive/working-groups/diffserv/current/maillist.html



From diffserv-admin@ietf.org  Tue Dec 12 20:17: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 SMTP id UAA23671
	for ; Tue, 12 Dec 2000 20:17:24 -0500 (EST)
Received: from optimus.ietf.org (localhost [127.0.0.1])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id TAA20262;
	Tue, 12 Dec 2000 19:35:57 -0500 (EST)
Received: from ietf.org (odin [132.151.1.176])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id TAA20240
	for ; Tue, 12 Dec 2000 19:35:53 -0500 (EST)
Received: from rautu.eng.telia.fi (root@ietf.207.137.74.94.tx.verio.net [207.137.74.94])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id TAA14986
	for ; Tue, 12 Dec 2000 19:35:52 -0500 (EST)
Received: (from jh@localhost)
	by rautu.eng.telia.fi (8.9.3/8.9.3/Debian 8.9.3-21) id CAA00734;
	Wed, 13 Dec 2000 02:34:48 +0200
From: Juha Heinanen 
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Message-ID: <14902.50216.261048.783354@rautu.eng.telia.fi>
Date: Wed, 13 Dec 2000 02:34:48 +0200 (EET)
To: Shahram Davari 
Cc: "'diffserv@ietf.org'" 
Subject: [Diffserv] Token bucket suggestion in Diffserv Model draft
In-Reply-To: <9DC5E2ABE65BD54CA9088DA3194461D6010C9AEA@BBY1EXM01>
References: <9DC5E2ABE65BD54CA9088DA3194461D6010C9AEA@BBY1EXM01>
X-Mailer: VM 6.75 under Emacs 19.34.1
Content-Transfer-Encoding: 7bit
Sender: diffserv-admin@ietf.org
Errors-To: diffserv-admin@ietf.org
X-Mailman-Version: 1.0
Precedence: bulk
List-Id: Diffserv Discussion List 
X-BeenThere: diffserv@ietf.org
Content-Transfer-Encoding: 7bit

shahram,

in order to simplify the document, i would leave out the negative-count
tb case,

-- juha

_______________________________________________
diffserv mailing list
diffserv@ietf.org
http://www1.ietf.org/mailman/listinfo/diffserv
Archive: http://www2.ietf.org/mail-archive/working-groups/diffserv/current/maillist.html



From diffserv-admin@ietf.org  Tue Dec 12 20:46: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 SMTP id UAA01593
	for ; Tue, 12 Dec 2000 20:46:07 -0500 (EST)
Received: from optimus.ietf.org (localhost [127.0.0.1])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id UAA20808;
	Tue, 12 Dec 2000 20:19:38 -0500 (EST)
Received: from ietf.org (odin [132.151.1.176])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id UAA20778
	for ; Tue, 12 Dec 2000 20:19:34 -0500 (EST)
Received: from hbhs.buaa.edu.cn (hbhs.buaa.edu.cn [202.112.131.60])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id UAA24104
	for ; Tue, 12 Dec 2000 20:19:30 -0500 (EST)
Received: from kanzhigang ([202.112.131.35]) by hbhs.buaa.edu.cn
          (Netscape Messaging Server 3.62)  with SMTP id 1075
          for ; Wed, 13 Dec 2000 09:26:56 +0800
Message-ID: <020301c064a3$9da161e0$238370ca@buaa.edu.cn>
From: "kan zhi" 
To: "diffserv" 
Date: Wed, 13 Dec 2000 09:25:45 +0800
MIME-Version: 1.0
Content-Type: text/plain;
	charset="gb2312"
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: 8bit
X-MIME-Autoconverted: from base64 to 8bit by optimus.ietf.org id UAA20779
Subject: [Diffserv] Nice to meet you!
Sender: diffserv-admin@ietf.org
Errors-To: diffserv-admin@ietf.org
X-Mailman-Version: 1.0
Precedence: bulk
List-Id: Diffserv Discussion List 
X-BeenThere: diffserv@ietf.org
Content-Transfer-Encoding: 8bit

Hi, all,

Nice to meet you. I am a newer of this list.

BR,
KanZhigang


_______________________________________________
diffserv mailing list
diffserv@ietf.org
http://www1.ietf.org/mailman/listinfo/diffserv
Archive: http://www2.ietf.org/mail-archive/working-groups/diffserv/current/maillist.html



From diffserv-admin@ietf.org  Tue Dec 12 21:57: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 SMTP id VAA17992
	for ; Tue, 12 Dec 2000 21:57:17 -0500 (EST)
Received: from optimus.ietf.org (localhost [127.0.0.1])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id VAA21828;
	Tue, 12 Dec 2000 21:31:38 -0500 (EST)
Received: from ietf.org (odin [132.151.1.176])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id VAA21765
	for ; Tue, 12 Dec 2000 21:31:32 -0500 (EST)
Received: from ihemail1.firewall.lucent.com (ihemail1.lucent.com [192.11.222.161])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id VAA12475;
	Tue, 12 Dec 2000 21:31:30 -0500 (EST)
Received: from ihemail1.firewall.lucent.com (localhost [127.0.0.1])
	by ihemail1.firewall.lucent.com (Pro-8.9.3/8.9.3) with ESMTP id VAA04793;
	Tue, 12 Dec 2000 21:31:31 -0500 (EST)
Received: from nl0006exch001h.wins.lucent.com (h135-85-76-62.lucent.com [135.85.76.62])
	by ihemail1.firewall.lucent.com (Pro-8.9.3/8.9.3) with ESMTP id VAA04780;
	Tue, 12 Dec 2000 21:31:31 -0500 (EST)
Received: by nl0006exch001h.nl.lucent.com with Internet Mail Service (5.5.2650.21)
	id ; Wed, 13 Dec 2000 03:31:23 +0100
Message-ID: <2413FED0DFE6D111B3F90008C7FA61FB0A6E0DFC@nl0006exch002u.nl.lucent.com>
From: "Wijnen, Bert (Bert)" 
To: Harrie Hazewinkel ,
        Andy Bierman
	 
Cc: rmonmib@ietf.org, diffserv@ietf.org
Subject: RE: [Diffserv] The DsCodePoint definition
Date: Wed, 13 Dec 2000 03:31:22 +0100
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2650.21)
Content-Type: text/plain
Sender: diffserv-admin@ietf.org
Errors-To: diffserv-admin@ietf.org
X-Mailman-Version: 1.0
Precedence: bulk
List-Id: Diffserv Discussion List 
X-BeenThere: diffserv@ietf.org

Comments inline

> ----------
> From: 	Andy Bierman[SMTP:abierman@cisco.com]
> Sent: 	Tuesday, December 12, 2000 9:07 PM
> To: 	Harrie Hazewinkel
> Cc: 	rmonmib@ietf.org; diffserv@ietf.org
> Subject: 	Re: [Diffserv] The DsCodePoint definition
> 
> Harrie Hazewinkel wrote:
> > 
> > HI,
> > 
> > I was wondering why there is a difference between
> > 2 definitions of the DiffServ CodePoint in different
> > MIB modules. The two different MIMB modules are
> > the DIFFSERV-MIB (of diffserv) and the DSMON-MIB (of RMON).
> > 
> > I beleive these 2 TCs should be the same and taken from the
> > DIFFSERV-MIB, because that is from the diffserv WG.
> > 
> > ----------- From the DIFFSERV-MIB (draft 05) -----------------
> > Dscp ::= TEXTUAL-CONVENTION
> >     DISPLAY-HINT "d"
> >     STATUS   current
> >     DESCRIPTION
> >        "The IP header Diffserv Code-Point that may  be  used
> >        for  discriminating or marking a traffic stream.  The
> >        value  -1  ( 4294967295 for Integer32 )  is  used  to
> >        indicate a wildcard i.e. any value."
> >     SYNTAX   Integer32 (4294967295 | 0..63)
> 
> just noticed how broken this TC is...
>  1) an Integer32 object cannot contain the value 4294967295
I have made that comments to the Diffserv list already, and they
will need to fix it with using -1
>  2) missing REFERENCE clause
>     (where exactly in 2474 is the 'wildcard' DSCP value discussed?)
Yep, this one was raised by someone else (was it Andrew?)

But the important thing, we need a fixed TC that is usable by both
MIBs I think. Or maybe 2 TCs as I also suggested on the diffserv
list.

Bert

> Andy
> 
> > --------------------------------------------------------------
> > 
> > ------------ From the DSMON-MIB (draft 03) -------------------
> > DsmonDSCodePoint ::= TEXTUAL-CONVENTION
> >     STATUS current
> >     DESCRIPTION
> >             "This TC describes an object which identifies the
> >             Differentiated Services Codepoint (DSCP) value found within
> >             the DS field in a network layer packet header (e.g., IPv4
> >             and IPv6)."
> >     REFERENCE
> >             "Definition of the Differentiated Services Field (DS Field)
> >             in the IPv4 and IPv6 Headers [RFC2474]."
> >     SYNTAX Integer32 (0..63)
> > --------------------------------------------------------------
> > 
> > OK, I will admit the definition of the DiffServ-MIB is currently
> > broken, but that will be fixed (this week at the IETF, I hope).
> > 
> > Harrie
> > 
> > _______________________________________________
> > diffserv mailing list
> > diffserv@ietf.org
> > http://www1.ietf.org/mailman/listinfo/diffserv
> > Archive:
> http://www2.ietf.org/mail-archive/working-groups/diffserv/current/maillist
> .html
> 
> _______________________________________________
> diffserv mailing list
> diffserv@ietf.org
> http://www1.ietf.org/mailman/listinfo/diffserv
> Archive:
> http://www2.ietf.org/mail-archive/working-groups/diffserv/current/maillist
> .html
> 

_______________________________________________
diffserv mailing list
diffserv@ietf.org
http://www1.ietf.org/mailman/listinfo/diffserv
Archive: http://www2.ietf.org/mail-archive/working-groups/diffserv/current/maillist.html



From diffserv-admin@ietf.org  Tue Dec 12 22:16:44 2000
Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged))
	by ietf.org (8.9.1a/8.9.1a) with SMTP id WAA20465
	for ; Tue, 12 Dec 2000 22:16:43 -0500 (EST)
Received: from optimus.ietf.org (localhost [127.0.0.1])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id VAA22016;
	Tue, 12 Dec 2000 21:52:16 -0500 (EST)
Received: from ietf.org (odin [132.151.1.176])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id VAA21987
	for ; Tue, 12 Dec 2000 21:52:12 -0500 (EST)
Received: from mailhub1.almaden.ibm.com (mailhub1.almaden.ibm.com [198.4.83.44])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id VAA16959
	for ; Tue, 12 Dec 2000 21:52:09 -0500 (EST)
Received: from maui.almaden.ibm.com (maui.almaden.ibm.com [9.1.24.92])
	by mailhub1.almaden.ibm.com (8.8.8/8.8.8) with ESMTP id SAA19824;
	Tue, 12 Dec 2000 18:49:00 -0800
Received: from hursley.ibm.com (gsine04.us.sine.ibm.com [9.14.6.44]) by maui.almaden.ibm.com (AIX4.3/8.9.3/8.7) with ESMTP id SAA20816; Tue, 12 Dec 2000 18:51:39 -0800
Message-ID: <3A36E3F7.E5EA01B8@hursley.ibm.com>
Date: Tue, 12 Dec 2000 20:50:31 -0600
From: Brian E Carpenter 
Organization: IBM
X-Mailer: Mozilla 4.61 [en] (Win98; I)
X-Accept-Language: en,fr
MIME-Version: 1.0
To: Juha Heinanen 
CC: Shahram Davari ,
        "'diffserv@ietf.org'" 
Subject: Re: [Diffserv] Token bucket suggestion in Diffserv Model draft
References: <9DC5E2ABE65BD54CA9088DA3194461D6010C9AEA@BBY1EXM01> <14902.50216.261048.783354@rautu.eng.telia.fi>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Content-Transfer-Encoding: 7bit
Sender: diffserv-admin@ietf.org
Errors-To: diffserv-admin@ietf.org
X-Mailman-Version: 1.0
Precedence: bulk
List-Id: Diffserv Discussion List 
X-BeenThere: diffserv@ietf.org
Content-Transfer-Encoding: 7bit

Juha,

That would reverse the previous consensus, which was to include both.

  Brian

Juha Heinanen wrote:
> 
> shahram,
> 
> in order to simplify the document, i would leave out the negative-count
> tb case,
> 
> -- juha
> 
> _______________________________________________
> diffserv mailing list
> diffserv@ietf.org
> http://www1.ietf.org/mailman/listinfo/diffserv
> Archive: http://www2.ietf.org/mail-archive/working-groups/diffserv/current/maillist.html

_______________________________________________
diffserv mailing list
diffserv@ietf.org
http://www1.ietf.org/mailman/listinfo/diffserv
Archive: http://www2.ietf.org/mail-archive/working-groups/diffserv/current/maillist.html



From diffserv-admin@ietf.org  Wed Dec 13 01:41: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 SMTP id BAA14457
	for ; Wed, 13 Dec 2000 01:41:20 -0500 (EST)
Received: from optimus.ietf.org (localhost [127.0.0.1])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id BAA00032;
	Wed, 13 Dec 2000 01:15:50 -0500 (EST)
Received: from ietf.org (odin [132.151.1.176])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id BAA29984
	for ; Wed, 13 Dec 2000 01:15:45 -0500 (EST)
Received: from mta6.snfc21.pbi.net (mta6.snfc21.pbi.net [206.13.28.240])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id BAA03436;
	Wed, 13 Dec 2000 01:15:45 -0500 (EST)
Received: from allegronetworks.com ([207.105.89.18])
 by mta6.snfc21.pbi.net (Sun Internet Mail Server sims.3.5.2000.01.05.12.18.p9)
 with ESMTP id <0G5H00JCGSIVLY@mta6.snfc21.pbi.net>; Tue,
 12 Dec 2000 21:56:58 -0800 (PST)
Date: Tue, 12 Dec 2000 22:05:21 -0800
From: Andrew Smith 
Subject: Re: [Diffserv] The DsCodePoint definition
To: "Wijnen, Bert (Bert)" 
Cc: Harrie Hazewinkel , Andy Bierman ,
        rmonmib@ietf.org, diffserv@ietf.org
Message-id: <3A3711A1.7060202@allegronetworks.com>
Organization: Allegro Networks
MIME-version: 1.0
Content-type: text/plain; charset=us-ascii; format=flowed
Content-transfer-encoding: 7bit
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; m18) Gecko/20001108
 Netscape6/6.0
X-Accept-Language: en
References: 
 <2413FED0DFE6D111B3F90008C7FA61FB0A6E0DFC@nl0006exch002u.nl.lucent.com>
Content-Transfer-Encoding: 7bit
Sender: diffserv-admin@ietf.org
Errors-To: diffserv-admin@ietf.org
X-Mailman-Version: 1.0
Precedence: bulk
List-Id: Diffserv Discussion List 
X-BeenThere: diffserv@ietf.org
Content-Transfer-Encoding: 7bit

2 TCs defined in the same MIB module, to be precise.

Andrew


Wijnen, Bert (Bert) wrote:

> Comments inline
> 
> 
>> ----------
>> From: 	Andy Bierman[SMTP:abierman@cisco.com]
>> Sent: 	Tuesday, December 12, 2000 9:07 PM
>> To: 	Harrie Hazewinkel
>> Cc: 	rmonmib@ietf.org; diffserv@ietf.org
>> Subject: 	Re: [Diffserv] The DsCodePoint definition
>> 
>> Harrie Hazewinkel wrote:
>> 
>>> HI,
>>> 
>>> I was wondering why there is a difference between
>>> 2 definitions of the DiffServ CodePoint in different
>>> MIB modules. The two different MIMB modules are
>>> the DIFFSERV-MIB (of diffserv) and the DSMON-MIB (of RMON).
>>> 
>>> I beleive these 2 TCs should be the same and taken from the
>>> DIFFSERV-MIB, because that is from the diffserv WG.
>>> 
>>> ----------- From the DIFFSERV-MIB (draft 05) -----------------
>>> Dscp ::= TEXTUAL-CONVENTION
>>>     DISPLAY-HINT "d"
>>>     STATUS   current
>>>     DESCRIPTION
>>>        "The IP header Diffserv Code-Point that may  be  used
>>>        for  discriminating or marking a traffic stream.  The
>>>        value  -1  ( 4294967295 for Integer32 )  is  used  to
>>>        indicate a wildcard i.e. any value."
>>>     SYNTAX   Integer32 (4294967295 | 0..63)
>> 
>> just noticed how broken this TC is...
>>  1) an Integer32 object cannot contain the value 4294967295
> 
> I have made that comments to the Diffserv list already, and they
> will need to fix it with using -1
> 
>>  2) missing REFERENCE clause
>>     (where exactly in 2474 is the 'wildcard' DSCP value discussed?)
> 
> Yep, this one was raised by someone else (was it Andrew?)
> 
> But the important thing, we need a fixed TC that is usable by both
> MIBs I think. Or maybe 2 TCs as I also suggested on the diffserv
> list.
> 
> Bert
> 
> 
>> Andy
>> 
>> 
>>> --------------------------------------------------------------
>>> 
>>> ------------ From the DSMON-MIB (draft 03) -------------------
>>> DsmonDSCodePoint ::= TEXTUAL-CONVENTION
>>>     STATUS current
>>>     DESCRIPTION
>>>             "This TC describes an object which identifies the
>>>             Differentiated Services Codepoint (DSCP) value found within
>>>             the DS field in a network layer packet header (e.g., IPv4
>>>             and IPv6)."
>>>     REFERENCE
>>>             "Definition of the Differentiated Services Field (DS Field)
>>>             in the IPv4 and IPv6 Headers [RFC2474]."
>>>     SYNTAX Integer32 (0..63)
>>> --------------------------------------------------------------
>>> 
>>> OK, I will admit the definition of the DiffServ-MIB is currently
>>> broken, but that will be fixed (this week at the IETF, I hope).
>>> 
>>> Harrie
>>> 
>>> _______________________________________________
>>> diffserv mailing list
>>> diffserv@ietf.org
>>> http://www1.ietf.org/mailman/listinfo/diffserv
>>> Archive:
>> 
>> http://www2.ietf.org/mail-archive/working-groups/diffserv/current/maillist
>> .html
>> 
>> _______________________________________________
>> diffserv mailing list
>> diffserv@ietf.org
>> http://www1.ietf.org/mailman/listinfo/diffserv
>> Archive:
>> http://www2.ietf.org/mail-archive/working-groups/diffserv/current/maillist
>> .html
>> 
> 
> 
> _______________________________________________
> diffserv mailing list
> diffserv@ietf.org
> http://www1.ietf.org/mailman/listinfo/diffserv
> Archive: http://www2.ietf.org/mail-archive/working-groups/diffserv/current/maillist.html


_______________________________________________
diffserv mailing list
diffserv@ietf.org
http://www1.ietf.org/mailman/listinfo/diffserv
Archive: http://www2.ietf.org/mail-archive/working-groups/diffserv/current/maillist.html



From diffserv-admin@ietf.org  Wed Dec 13 01:58: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 SMTP id BAA22696
	for ; Wed, 13 Dec 2000 01:58:13 -0500 (EST)
Received: from optimus.ietf.org (localhost [127.0.0.1])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id BAA00333;
	Wed, 13 Dec 2000 01:37:26 -0500 (EST)
Received: from ietf.org (odin [132.151.1.176])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id BAA00296
	for ; Wed, 13 Dec 2000 01:36:52 -0500 (EST)
Received: from lohi.eng.telia.fi (lohi.eng.telia.fi [195.10.149.18])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id BAA11924
	for ; Wed, 13 Dec 2000 01:36:51 -0500 (EST)
Received: (from jh@localhost)
	by lohi.eng.telia.fi (8.11.1/8.11.1/Debian 8.11.0-6) id eBD6amw18250;
	Wed, 13 Dec 2000 08:36:48 +0200
From: Juha Heinanen 
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Message-ID: <14903.6400.563451.547857@lohi.eng.telia.fi>
Date: Wed, 13 Dec 2000 08:36:48 +0200 (EET)
To: Brian E Carpenter 
Cc: Shahram Davari ,
        "'diffserv@ietf.org'" 
Subject: Re: [Diffserv] Token bucket suggestion in Diffserv Model draft
In-Reply-To: <3A36E3F7.E5EA01B8@hursley.ibm.com>
References: <9DC5E2ABE65BD54CA9088DA3194461D6010C9AEA@BBY1EXM01>
	<14902.50216.261048.783354@rautu.eng.telia.fi>
	<3A36E3F7.E5EA01B8@hursley.ibm.com>
X-Mailer: VM 6.75 under Emacs 19.34.1
Content-Transfer-Encoding: 7bit
Sender: diffserv-admin@ietf.org
Errors-To: diffserv-admin@ietf.org
X-Mailman-Version: 1.0
Precedence: bulk
List-Id: Diffserv Discussion List 
X-BeenThere: diffserv@ietf.org
Content-Transfer-Encoding: 7bit

Brian E Carpenter writes:

 > That would reverse the previous consensus, which was to include both.

i had big backlog of diffserv mail caused by the ef war and didn't know
if there was a consensus.  i still see no point in introducing just like
that in a diffserv document a totally new concept of negative leaky
bucket that ietf, itu, or nobody else that i know of has so far had
anywhere.

-- juha


_______________________________________________
diffserv mailing list
diffserv@ietf.org
http://www1.ietf.org/mailman/listinfo/diffserv
Archive: http://www2.ietf.org/mail-archive/working-groups/diffserv/current/maillist.html



From diffserv-admin@ietf.org  Wed Dec 13 02:32:49 2000
Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged))
	by ietf.org (8.9.1a/8.9.1a) with SMTP id CAA10144
	for ; Wed, 13 Dec 2000 02:32:49 -0500 (EST)
Received: from optimus.ietf.org (localhost [127.0.0.1])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id CAA00730;
	Wed, 13 Dec 2000 02:06:49 -0500 (EST)
Received: from ietf.org (odin [132.151.1.176])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id CAA00699
	for ; Wed, 13 Dec 2000 02:06:45 -0500 (EST)
Received: from motgate2.mot.com (motgate2.mot.com [136.182.1.10])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id CAA02007
	for ; Wed, 13 Dec 2000 02:06:45 -0500 (EST)
Received: [from pobox.mot.com (pobox.mot.com [129.188.137.100]) by motgate2.mot.com (motgate2 2.1) with ESMTP id AAA16553; Wed, 13 Dec 2000 00:04:03 -0700 (MST)]
Received: [from noah.dma.isg.mot.com (noah.dma.isg.mot.com [150.21.2.29]) by pobox.mot.com (MOT-pobox 2.0) with ESMTP id AAA00686; Wed, 13 Dec 2000 00:04:03 -0700 (MST)]
Received: from dma.isg.mot.com (t-il01-aa-port19.corp.mot.com [199.5.169.149])
	by noah.dma.isg.mot.com (8.8.8+Sun/8.8.8) with ESMTP id CAA12653;
	Wed, 13 Dec 2000 02:03:59 -0500 (EST)
Message-ID: <3A371EBD.ED8E972B@dma.isg.mot.com>
Date: Wed, 13 Dec 2000 02:01:21 -0500
From: Dan Grossman 
X-Mailer: Mozilla 4.51 (Macintosh; I; PPC)
X-Accept-Language: en
MIME-Version: 1.0
To: Brian E Carpenter 
CC: "'diffserv@ietf.org'" 
Subject: Re: [Diffserv] Token bucket suggestion in Diffserv Model draft
References: <9DC5E2ABE65BD54CA9088DA3194461D6010C9AEA@BBY1EXM01> <3A35A2E1.7497AD08@hursley.ibm.com>
Content-Type: text/plain; charset=us-ascii; x-mac-type="54455854"; x-mac-creator="4D4F5353"
Content-Transfer-Encoding: 7bit
Content-Transfer-Encoding: 7bit
Sender: diffserv-admin@ietf.org
Errors-To: diffserv-admin@ietf.org
X-Mailman-Version: 1.0
Precedence: bulk
List-Id: Diffserv Discussion List 
X-BeenThere: diffserv@ietf.org
Content-Transfer-Encoding: 7bit

I consider Shahram's text to be a great improvement.  The positive count/negative count
wording is technically more precise, but a bit less intuitive.  Perhaps we can use the
positive/negative terminology, but put in a note to the effect that the terms strict/loose
have also been used (or something like that).

Dan

Brian E Carpenter wrote:

> Shahram,
>
> Thanks for all the suggested text. I will leave the document editor to
> decide how much of it he adopts - I hadn't expected so much change from today's
> discussion.
>
> As for the terminology change from "strict/loose" to
> "positive-count/negative-count", we would need a consensus for that.
> WG comments are welcome.
>
> Thanks
>   Brian
>
> _______________________________________________
> diffserv mailing list
> diffserv@ietf.org
> http://www1.ietf.org/mailman/listinfo/diffserv
> Archive: http://www2.ietf.org/mail-archive/working-groups/diffserv/current/maillist.html



_______________________________________________
diffserv mailing list
diffserv@ietf.org
http://www1.ietf.org/mailman/listinfo/diffserv
Archive: http://www2.ietf.org/mail-archive/working-groups/diffserv/current/maillist.html



From diffserv-admin@ietf.org  Wed Dec 13 08: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 SMTP id IAA10415
	for ; Wed, 13 Dec 2000 08:47:41 -0500 (EST)
Received: from optimus.ietf.org (localhost [127.0.0.1])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id IAA04340;
	Wed, 13 Dec 2000 08:23:50 -0500 (EST)
Received: from ietf.org (odin [132.151.1.176])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id IAA04309
	for ; Wed, 13 Dec 2000 08:23:46 -0500 (EST)
Received: from uniwest1.redstonecom.com ([199.105.223.130])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id IAA05240
	for ; Wed, 13 Dec 2000 08:23:44 -0500 (EST)
Received: by uniwest1.redstonecom.com with Internet Mail Service (5.5.2650.21)
	id ; Wed, 13 Dec 2000 08:23:14 -0500
Message-ID: <49FF5C6DDBD8D311BBBD009027DE980C010C43AE@uniwest1.redstonecom.com>
From: "Lemaire, Tom" 
To: "'diffserv@ietf.org'" 
Subject: RE: [Diffserv] Token bucket suggestion in Diffserv Model draft
Date: Wed, 13 Dec 2000 08:23:14 -0500
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2650.21)
Content-Type: text/plain;
	charset="iso-8859-1"
Sender: diffserv-admin@ietf.org
Errors-To: diffserv-admin@ietf.org
X-Mailman-Version: 1.0
Precedence: bulk
List-Id: Diffserv Discussion List 
X-BeenThere: diffserv@ietf.org


I'd like it if the draft authors could clarify
the problems that negative count token buckets
are trying to solve.

A reader of the draft might infer they are
more TCP friendly, since the existing positive
count token buckets are not particularly
TCP friendly, and maybe someone wanted to address
that.  But in fact their perceived leniency does
not help TCP, since they still drop multiple
back-to-back packets in a TCP burst.  And as Shahram's
revised text of Monday points out, they are biased
against small packets, e.g. TCP ACKs, and that seems
TCP unfriendly.

But perhaps they are good for TCP in some ways, or
good for some other application.  It would be helpful
if the authors could give examples of where negative
count token buckets are an improvement over the positive
count.

Tom Lemaire
Unisphere Networks






_______________________________________________
diffserv mailing list
diffserv@ietf.org
http://www1.ietf.org/mailman/listinfo/diffserv
Archive: http://www2.ietf.org/mail-archive/working-groups/diffserv/current/maillist.html



From diffserv-admin@ietf.org  Wed Dec 13 11:19:46 2000
Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged))
	by ietf.org (8.9.1a/8.9.1a) with SMTP id LAA08962
	for ; Wed, 13 Dec 2000 11:19:46 -0500 (EST)
Received: from optimus.ietf.org (localhost [127.0.0.1])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id KAA06216;
	Wed, 13 Dec 2000 10:59:24 -0500 (EST)
Received: from ietf.org (odin [132.151.1.176])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id KAA06119
	for ; Wed, 13 Dec 2000 10:59:17 -0500 (EST)
Received: from hoemail2.firewall.lucent.com (hoemail2.lucent.com [192.11.226.163])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id KAA06533
	for ; Wed, 13 Dec 2000 10:59:15 -0500 (EST)
Received: from hoemail2.firewall.lucent.com (localhost [127.0.0.1])
	by hoemail2.firewall.lucent.com (Pro-8.9.3/8.9.3) with ESMTP id KAA26410
	for ; Wed, 13 Dec 2000 10:59:16 -0500 (EST)
Received: from uk0006exch001h.wins.lucent.com (h135-86-160-150.lucent.com [135.86.160.150])
	by hoemail2.firewall.lucent.com (Pro-8.9.3/8.9.3) with ESMTP id KAA26379
	for ; Wed, 13 Dec 2000 10:59:16 -0500 (EST)
Received: by uk0006exch001h.uk.lucent.com with Internet Mail Service (5.5.2650.21)
	id ; Wed, 13 Dec 2000 15:59:15 -0000
Message-ID: <976F7C55E3B2D111A0720008C728549C04877626@en0060exch001u.uk.lucent.com>
From: "Casati, Alessio (Alessio)" 
To: diffserv@ietf.org
Subject: RE: [Diffserv] Possible compromise between EFRESOLVE anddraft-ch 
	 arny
Date: Wed, 13 Dec 2000 15:59:13 -0000
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2650.21)
Content-Type: text/plain
Sender: diffserv-admin@ietf.org
Errors-To: diffserv-admin@ietf.org
X-Mailman-Version: 1.0
Precedence: bulk
List-Id: Diffserv Discussion List 
X-BeenThere: diffserv@ietf.org

> From the piece of text you have taken out from the example (which I think 
> may be Dimitri's?) I cannot tell whether what you are saying is correct or
> 
> not. But your message above does not seem to make sense to me in general.
>  I 
> want to remind you the context of the example I  gave to show large S for 
> which no reasonable scaling would help. You have am ideal output buffered 
> router with no internal delay,  N identical speed C interfaces, and a PQ
> at 
> each interface. You have  C/2 -worth of total EF traffic going from each 
> input interfaces to all other outputs, which means that the configured 
> input rate is R=C/2. From the total EF traffic at every input only 
> C/2N  goes to each individual output.    Therefore, each output has R=C/2 
> EF traffic as well.  Consider any single output.  It can experience a 
> simultaneous arrival of N packets of MTU size, one from each input 
> interface (even for the case wen there is no input burstiness at all).
> This 
> means that there could be an instantaneous queue of N packets, which can
> be 
> drained at most at the speed of the interface C=2R.  Therefore, a delay 
> experienced by the last packet in this queue will be N*MTU/2R. That means 
> in this case D=N*MTU/2R for this packet.  In the absence of competing 
> traffic this packet would have left at time E=MTU/C=MTU/2R. This means
> that 
> D-E = (N-1)/2 * MTU/R.
> 
> So for a N=1000 port device S must be at least 999/2=499.5 for ideally 
> shaped inputs.  If you allow a burst B at each input, you would need to 
> have S=499.5*B, and
> NOT S=1.
> 
> 
In fact my answer was not related to this example, but just stating once
again
the fact that S can be any values that make S*MTU/R OK according to the
service
goals. if no satisfactory S*MTU/R can be found for a GIven R according to
a router config, one should go back to the drawing board and
change the acceptable R, or the configuration. I'm not comfortable with
the assertion big S = Bad thing. Again, if instead of S*MTU/R
we would have written Tmax or E, probably we would have saved much
folder / archive space, and time.

regards

alessio


_______________________________________________
diffserv mailing list
diffserv@ietf.org
http://www1.ietf.org/mailman/listinfo/diffserv
Archive: http://www2.ietf.org/mail-archive/working-groups/diffserv/current/maillist.html



From diffserv-admin@ietf.org  Wed Dec 13 12:18:16 2000
Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged))
	by ietf.org (8.9.1a/8.9.1a) with SMTP id MAA15787
	for ; Wed, 13 Dec 2000 12:18:16 -0500 (EST)
Received: from optimus.ietf.org (localhost [127.0.0.1])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id LAA07023;
	Wed, 13 Dec 2000 11:48:05 -0500 (EST)
Received: from ietf.org (odin [132.151.1.176])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id LAA06992
	for ; Wed, 13 Dec 2000 11:48:01 -0500 (EST)
Received: from mailhub1.almaden.ibm.com (mailhub1.almaden.ibm.com [198.4.83.44])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id LAA12246
	for ; Wed, 13 Dec 2000 11:47:59 -0500 (EST)
Received: from maui.almaden.ibm.com (maui.almaden.ibm.com [9.1.24.92])
	by mailhub1.almaden.ibm.com (8.8.8/8.8.8) with ESMTP id IAA59650;
	Wed, 13 Dec 2000 08:44:39 -0800
Received: from hursley.ibm.com (gsine02.us.sine.ibm.com [9.14.6.42]) by maui.almaden.ibm.com (AIX4.3/8.9.3/8.7) with ESMTP id IAA20782; Wed, 13 Dec 2000 08:47:29 -0800
Message-ID: <3A37A7DB.C2C37564@hursley.ibm.com>
Date: Wed, 13 Dec 2000 10:46:19 -0600
From: Brian E Carpenter 
Organization: IBM
X-Mailer: Mozilla 4.61 [en] (Win98; I)
X-Accept-Language: en,fr
MIME-Version: 1.0
To: "Lemaire, Tom" 
CC: "'diffserv@ietf.org'" 
Subject: Re: [Diffserv] Token bucket suggestion in Diffserv Model draft
References: <49FF5C6DDBD8D311BBBD009027DE980C010C43AE@uniwest1.redstonecom.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

Tom,

We've been round and round on this many times.
Experienced implementors of IP routers tell us that
the loose model is in widespread use (i.e. it is
running code). That is enough to include it in the model
and that's what the WG settled on a while back. We also agreed
to include the strict model because other implementors
want it. Since we are *months* late with this document,
I think we should just go with what we have now.

  Brian

"Lemaire, Tom" wrote:
> 
> I'd like it if the draft authors could clarify
> the problems that negative count token buckets
> are trying to solve.
> 
> A reader of the draft might infer they are
> more TCP friendly, since the existing positive
> count token buckets are not particularly
> TCP friendly, and maybe someone wanted to address
> that.  But in fact their perceived leniency does
> not help TCP, since they still drop multiple
> back-to-back packets in a TCP burst.  And as Shahram's
> revised text of Monday points out, they are biased
> against small packets, e.g. TCP ACKs, and that seems
> TCP unfriendly.
> 
> But perhaps they are good for TCP in some ways, or
> good for some other application.  It would be helpful
> if the authors could give examples of where negative
> count token buckets are an improvement over the positive
> count.
> 
> Tom Lemaire
> Unisphere Networks
> 
> _______________________________________________
> diffserv mailing list
> diffserv@ietf.org
> http://www1.ietf.org/mailman/listinfo/diffserv
> Archive: http://www2.ietf.org/mail-archive/working-groups/diffserv/current/maillist.html

_______________________________________________
diffserv mailing list
diffserv@ietf.org
http://www1.ietf.org/mailman/listinfo/diffserv
Archive: http://www2.ietf.org/mail-archive/working-groups/diffserv/current/maillist.html



From diffserv-admin@ietf.org  Wed Dec 13 13:21: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 SMTP id NAA24967
	for ; Wed, 13 Dec 2000 13:21:07 -0500 (EST)
Received: from optimus.ietf.org (localhost [127.0.0.1])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id MAA08054;
	Wed, 13 Dec 2000 12:38:59 -0500 (EST)
Received: from ietf.org (odin [132.151.1.176])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id MAA08020
	for ; Wed, 13 Dec 2000 12:38:54 -0500 (EST)
Received: from lohi.eng.telia.fi (lohi.eng.telia.fi [195.10.149.18])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id MAA18224
	for ; Wed, 13 Dec 2000 12:38:54 -0500 (EST)
Received: (from jh@localhost)
	by lohi.eng.telia.fi (8.11.1/8.11.1/Debian 8.11.0-6) id eBDHcf818647;
	Wed, 13 Dec 2000 19:38:41 +0200
From: Juha Heinanen 
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Message-ID: <14903.46113.248346.818561@lohi.eng.telia.fi>
Date: Wed, 13 Dec 2000 19:38:41 +0200 (EET)
To: Brian E Carpenter 
Cc: "Lemaire, Tom" ,
        "'diffserv@ietf.org'" 
Subject: Re: [Diffserv] Token bucket suggestion in Diffserv Model draft
In-Reply-To: <3A37A7DB.C2C37564@hursley.ibm.com>
References: <49FF5C6DDBD8D311BBBD009027DE980C010C43AE@uniwest1.redstonecom.com>
	<3A37A7DB.C2C37564@hursley.ibm.com>
X-Mailer: VM 6.75 under Emacs 19.34.1
Content-Transfer-Encoding: 7bit
Sender: diffserv-admin@ietf.org
Errors-To: diffserv-admin@ietf.org
X-Mailman-Version: 1.0
Precedence: bulk
List-Id: Diffserv Discussion List 
X-BeenThere: diffserv@ietf.org
Content-Transfer-Encoding: 7bit

Brian E Carpenter writes:

 > We've been round and round on this many times.
 > Experienced implementors of IP routers tell us that
 > the loose model is in widespread use (i.e. it is
 > running code).

brian, could you tell me me whose router allows me to choose between
positive and negative leaky buckets?  so far i haven't seen any.  i
don't think that it a service to the router vendors or those who need to
configure the boxes to introduce yet another option.

-- juha

_______________________________________________
diffserv mailing list
diffserv@ietf.org
http://www1.ietf.org/mailman/listinfo/diffserv
Archive: http://www2.ietf.org/mail-archive/working-groups/diffserv/current/maillist.html



From diffserv-admin@ietf.org  Wed Dec 13 13:22:39 2000
Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged))
	by ietf.org (8.9.1a/8.9.1a) with SMTP id NAA25174
	for ; Wed, 13 Dec 2000 13:22:39 -0500 (EST)
Received: from optimus.ietf.org (localhost [127.0.0.1])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id MAA08301;
	Wed, 13 Dec 2000 12:52:43 -0500 (EST)
Received: from ietf.org (odin [132.151.1.176])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id MAA08274
	for ; Wed, 13 Dec 2000 12:52:39 -0500 (EST)
Received: from uniwest1.redstonecom.com ([199.105.223.130])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id MAA20110
	for ; Wed, 13 Dec 2000 12:52:37 -0500 (EST)
Received: by uniwest1.redstonecom.com with Internet Mail Service (5.5.2650.21)
	id ; Wed, 13 Dec 2000 12:52:06 -0500
Message-ID: <49FF5C6DDBD8D311BBBD009027DE980C010C43B2@uniwest1.redstonecom.com>
From: "Lemaire, Tom" 
To: "'Brian E Carpenter'" 
Cc: "'diffserv@ietf.org'" 
Subject: RE: [Diffserv] Token bucket suggestion in Diffserv Model draft
Date: Wed, 13 Dec 2000 12:52:06 -0500
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2650.21)
Content-Type: text/plain;
	charset="iso-8859-1"
Sender: diffserv-admin@ietf.org
Errors-To: diffserv-admin@ietf.org
X-Mailman-Version: 1.0
Precedence: bulk
List-Id: Diffserv Discussion List 
X-BeenThere: diffserv@ietf.org

hi Brian,

It's OK if the loose model is in the draft and
also in widespread use.  I think it's great it's
in the draft, it makes you think about it.
But I am asking the authors to clarify the
problem domain that loose buckets address, at least
to the list.  If that text was included in the draft,
that would seemingly only enhance the understanding
of the reader of the draft.

As it stands, the draft does not explicitly say
whether loose buckets are TCP friendly or not,
though it touches on the subject of TCP.  If this
is not yet known, that would also be a reasonable
statement, that loose buckets interaction with TCP
are a subject for further research.

There is a risk that the reader will infer that loose
buckets are a specification for what underlies the
TCP friendly mechanisms that are deployed in existing
products.  I believe those implementations are more
sophisticated than the negative count token bucket
described in the draft.

Tom L


-----Original Message-----
From: Brian E Carpenter [mailto:brian@hursley.ibm.com]
Sent: Wednesday, December 13, 2000 11:46 AM
To: Lemaire, Tom
Cc: 'diffserv@ietf.org'
Subject: Re: [Diffserv] Token bucket suggestion in Diffserv Model draft


Tom,

We've been round and round on this many times.
Experienced implementors of IP routers tell us that
the loose model is in widespread use (i.e. it is
running code). That is enough to include it in the model
and that's what the WG settled on a while back. We also agreed
to include the strict model because other implementors
want it. Since we are *months* late with this document,
I think we should just go with what we have now.

  Brian

"Lemaire, Tom" wrote:
> 
> I'd like it if the draft authors could clarify
> the problems that negative count token buckets
> are trying to solve.
> 
> A reader of the draft might infer they are
> more TCP friendly, since the existing positive
> count token buckets are not particularly
> TCP friendly, and maybe someone wanted to address
> that.  But in fact their perceived leniency does
> not help TCP, since they still drop multiple
> back-to-back packets in a TCP burst.  And as Shahram's
> revised text of Monday points out, they are biased
> against small packets, e.g. TCP ACKs, and that seems
> TCP unfriendly.
> 
> But perhaps they are good for TCP in some ways, or
> good for some other application.  It would be helpful
> if the authors could give examples of where negative
> count token buckets are an improvement over the positive
> count.
> 
> Tom Lemaire
> Unisphere Networks
> 
> _______________________________________________
> diffserv mailing list
> diffserv@ietf.org
> http://www1.ietf.org/mailman/listinfo/diffserv
> Archive:
http://www2.ietf.org/mail-archive/working-groups/diffserv/current/maillist.h
tml

_______________________________________________
diffserv mailing list
diffserv@ietf.org
http://www1.ietf.org/mailman/listinfo/diffserv
Archive: http://www2.ietf.org/mail-archive/working-groups/diffserv/current/maillist.html



From diffserv-admin@ietf.org  Wed Dec 13 13:26:54 2000
Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged))
	by ietf.org (8.9.1a/8.9.1a) with SMTP id NAA25689
	for ; Wed, 13 Dec 2000 13:26:54 -0500 (EST)
Received: from optimus.ietf.org (localhost [127.0.0.1])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id NAA08615;
	Wed, 13 Dec 2000 13:01:25 -0500 (EST)
Received: from ietf.org (odin [132.151.1.176])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id NAA08572
	for ; Wed, 13 Dec 2000 13:01:20 -0500 (EST)
Received: from web4201.mail.yahoo.com (web4201.mail.yahoo.com [216.115.104.134])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id NAA22026
	for ; Wed, 13 Dec 2000 13:01:19 -0500 (EST)
From: g_mercankosk@yahoo.com
Message-ID: <20001213180049.27756.qmail@web4201.mail.yahoo.com>
Received: from [207.137.71.20] by web4201.mail.yahoo.com; Wed, 13 Dec 2000 10:00:49 PST
Date: Wed, 13 Dec 2000 10:00:49 -0800 (PST)
Subject: Re: [Diffserv] Token bucket suggestion in Diffserv Model draft
To: jh@lohi.eng.telia.fi, brian@hursley.ibm.com, Shahram_Davari@pmc-sierra.com,
        diffserv@ietf.org
Cc: guven@ee.uwa.edu.au
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Sender: diffserv-admin@ietf.org
Errors-To: diffserv-admin@ietf.org
X-Mailman-Version: 1.0
Precedence: bulk
List-Id: Diffserv Discussion List 
X-BeenThere: diffserv@ietf.org


Brian,

I would like to second Juha's point.

It should be noted that the bucket depth in the case
of positive-count has one-to-one correspondence as to
how early a packet can arrive. Whereas in the case of
negative count one losses that property. I appreciate
the possibility of using negative-count. But I believe
that it is not inline with the intent of leaky-bucket.


Guven.

Juha Heinanen wrote:

  Brian E Carpenter writes:

   > That would reverse the previous consensus, which
was to include both.

  i had big backlog of diffserv mail caused by the ef
war and didn't know if there was a consensus.  i still
see no point in introducing just like that in a
diffserv document a totally new concept of negative
leaky bucket that ietf, itu, or nobody else that i
know of has so far had anywhere.

  -- juha

__________________________________________________
Do You Yahoo!?
Yahoo! Shopping - Thousands of Stores. Millions of Products.
http://shopping.yahoo.com/

_______________________________________________
diffserv mailing list
diffserv@ietf.org
http://www1.ietf.org/mailman/listinfo/diffserv
Archive: http://www2.ietf.org/mail-archive/working-groups/diffserv/current/maillist.html



From diffserv-admin@ietf.org  Wed Dec 13 13:45: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 SMTP id NAA29612
	for ; Wed, 13 Dec 2000 13:45:41 -0500 (EST)
Received: from optimus.ietf.org (localhost [127.0.0.1])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id NAA08876;
	Wed, 13 Dec 2000 13:16:00 -0500 (EST)
Received: from ietf.org (odin [132.151.1.176])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id NAA08812
	for ; Wed, 13 Dec 2000 13:15:55 -0500 (EST)
Received: from sj-msg-core-2.cisco.com (sj-msg-core-2.cisco.com [171.69.43.88])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id NAA24323;
	Wed, 13 Dec 2000 13:15:54 -0500 (EST)
Received: from sj-msg-av-1.cisco.com (sj-msg-av-1.cisco.com [171.69.11.130])
	by sj-msg-core-2.cisco.com (8.9.3/8.9.1) with ESMTP id KAA19029;
	Wed, 13 Dec 2000 10:14:46 -0800 (PST)
Received: from mailman.cisco.com (localhost [127.0.0.1])
	by sj-msg-av-1.cisco.com (8.10.1/8.10.1) with ESMTP id eBDIEtr23274;
	Wed, 13 Dec 2000 10:14:55 -0800 (PST)
Received: from cisco.com (ssh-sj1.cisco.com [171.68.225.134])
	by mailman.cisco.com (8.9.3/8.9.1) with ESMTP id KAA07896;
	Wed, 13 Dec 2000 10:14:40 -0800 (PST)
Message-ID: <3A37BCCA.7901C1F@cisco.com>
Date: Wed, 13 Dec 2000 10:15:38 -0800
From: Andy Bierman 
Organization: Cisco Systems, Inc.
X-Mailer: Mozilla 4.73 [en] (Win98; U)
X-Accept-Language: en
MIME-Version: 1.0
To: Andrew Smith 
CC: "Wijnen, Bert (Bert)" ,
        Harrie Hazewinkel , rmonmib@ietf.org,
        diffserv@ietf.org
Subject: Re: [Diffserv] The DsCodePoint definition
References: <2413FED0DFE6D111B3F90008C7FA61FB0A6E0DFC@nl0006exch002u.nl.lucent.com> <3A3711A1.7060202@allegronetworks.com>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Content-Transfer-Encoding: 7bit
Sender: diffserv-admin@ietf.org
Errors-To: diffserv-admin@ietf.org
X-Mailman-Version: 1.0
Precedence: bulk
List-Id: Diffserv Discussion List 
X-BeenThere: diffserv@ietf.org
Content-Transfer-Encoding: 7bit

Andrew Smith wrote:
> 
> 2 TCs defined in the same MIB module, to be precise.
> 

I disagree.
There is no need for the DSMON MIB to have a normative
reference to the DIFFSERV MIB. 

The primary focus of RMON is collect statistics based on
observable characteristics of network traffic. RFC 2474 
specifies the observable attributes of a packet containing
a DSCP field. The REFERENCE clause in the DsCodePoint TC
properly identifies RFC 2474, and no additional coupling to
any other documents is required.

BTW, SMIv2 does not allow a TC to be defined as a variant of
another TC, so Harrie's suggestion won't work.

> Andrew

Andy

> 
> Wijnen, Bert (Bert) wrote:
> 
> > Comments inline
> >
> >
> >> ----------
> >> From:        Andy Bierman[SMTP:abierman@cisco.com]
> >> Sent:        Tuesday, December 12, 2000 9:07 PM
> >> To:  Harrie Hazewinkel
> >> Cc:  rmonmib@ietf.org; diffserv@ietf.org
> >> Subject:     Re: [Diffserv] The DsCodePoint definition
> >>
> >> Harrie Hazewinkel wrote:
> >>
> >>> HI,
> >>>
> >>> I was wondering why there is a difference between
> >>> 2 definitions of the DiffServ CodePoint in different
> >>> MIB modules. The two different MIMB modules are
> >>> the DIFFSERV-MIB (of diffserv) and the DSMON-MIB (of RMON).
> >>>
> >>> I beleive these 2 TCs should be the same and taken from the
> >>> DIFFSERV-MIB, because that is from the diffserv WG.
> >>>
> >>> ----------- From the DIFFSERV-MIB (draft 05) -----------------
> >>> Dscp ::= TEXTUAL-CONVENTION
> >>>     DISPLAY-HINT "d"
> >>>     STATUS   current
> >>>     DESCRIPTION
> >>>        "The IP header Diffserv Code-Point that may  be  used
> >>>        for  discriminating or marking a traffic stream.  The
> >>>        value  -1  ( 4294967295 for Integer32 )  is  used  to
> >>>        indicate a wildcard i.e. any value."
> >>>     SYNTAX   Integer32 (4294967295 | 0..63)
> >>
> >> just noticed how broken this TC is...
> >>  1) an Integer32 object cannot contain the value 4294967295
> >
> > I have made that comments to the Diffserv list already, and they
> > will need to fix it with using -1
> >
> >>  2) missing REFERENCE clause
> >>     (where exactly in 2474 is the 'wildcard' DSCP value discussed?)
> >
> > Yep, this one was raised by someone else (was it Andrew?)
> >
> > But the important thing, we need a fixed TC that is usable by both
> > MIBs I think. Or maybe 2 TCs as I also suggested on the diffserv
> > list.
> >
> > Bert
> >
> >
> >> Andy
> >>
> >>
> >>> --------------------------------------------------------------
> >>>
> >>> ------------ From the DSMON-MIB (draft 03) -------------------
> >>> DsmonDSCodePoint ::= TEXTUAL-CONVENTION
> >>>     STATUS current
> >>>     DESCRIPTION
> >>>             "This TC describes an object which identifies the
> >>>             Differentiated Services Codepoint (DSCP) value found within
> >>>             the DS field in a network layer packet header (e.g., IPv4
> >>>             and IPv6)."
> >>>     REFERENCE
> >>>             "Definition of the Differentiated Services Field (DS Field)
> >>>             in the IPv4 and IPv6 Headers [RFC2474]."
> >>>     SYNTAX Integer32 (0..63)
> >>> --------------------------------------------------------------
> >>>
> >>> OK, I will admit the definition of the DiffServ-MIB is currently
> >>> broken, but that will be fixed (this week at the IETF, I hope).
> >>>
> >>> Harrie

_______________________________________________
diffserv mailing list
diffserv@ietf.org
http://www1.ietf.org/mailman/listinfo/diffserv
Archive: http://www2.ietf.org/mail-archive/working-groups/diffserv/current/maillist.html



From diffserv-admin@ietf.org  Wed Dec 13 13:45: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 SMTP id NAA29682
	for ; Wed, 13 Dec 2000 13:45:55 -0500 (EST)
Received: from optimus.ietf.org (localhost [127.0.0.1])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id NAA09004;
	Wed, 13 Dec 2000 13:20:23 -0500 (EST)
Received: from ietf.org (odin [132.151.1.176])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id NAA08973
	for ; Wed, 13 Dec 2000 13:20:18 -0500 (EST)
Received: from mailman.packetdesign.com (dns.PACKETDESIGN.NET [216.15.46.10])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id NAA24864
	for ; Wed, 13 Dec 2000 13:20:16 -0500 (EST)
Received: from packetdesign.com (main-fw-eth1.packetdesign.com [192.168.0.254])
	by mailman.packetdesign.com (8.11.0/8.11.0) with ESMTP id eBDIJ6Q67468;
	Wed, 13 Dec 2000 10:19:06 -0800 (PST)
	(envelope-from nichols@packetdesign.com)
Message-ID: <3A37BDC5.8F517EB2@packetdesign.com>
Date: Wed, 13 Dec 2000 10:19:49 -0800
From: Kathleen Nichols 
X-Mailer: Mozilla 4.61 [en] (Win98; U)
X-Accept-Language: en
MIME-Version: 1.0
To: GARBISU Jean-Pierre FTRD/DMI/CAE 
 
CC: "'Brian E Carpenter'" ,
        Simon Leinen ,
        Yoram Bernet , diffserv@ietf.org
Subject: Re: LBE PHB [was: [Diffserv] comments on the bulk handling draft]
References: <91A311FF6A85D3118DDF0060080C3D82B7DAAE@lat3721.lannion.cnet.fr>
Content-Type: text/plain; charset=iso-8859-1
X-MIME-Autoconverted: from 8bit to quoted-printable by mailman.packetdesign.com id eBDIJ6Q67468
X-MIME-Autoconverted: from quoted-printable to 8bit by optimus.ietf.org id NAA08974
Sender: diffserv-admin@ietf.org
Errors-To: diffserv-admin@ietf.org
X-Mailman-Version: 1.0
Precedence: bulk
List-Id: Diffserv Discussion List 
X-BeenThere: diffserv@ietf.org
X-MIME-Autoconverted: from 8bit to quoted-printable by optimus.ietf.org id NAA09004
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by ietf.org id NAA29682


I think, as Brian said, it's necessary to make a distinction 
between talking about a per-hop forwarding behavior and a
per-domain behavior. I'm not sure which you mean below.

	Kathie

GARBISU Jean-Pierre FTRD/DMI/CAE wrote:
> 
> "in the litterature" critical traffic is very often referring to ERP and
> transactional oriented application
> non-critical is very often referring to best effort or any kind of AF-like
> gradation between best effort and critical (e.g non critical enterprise
> trafic somewhere between main public best effort and enterprise critical)
> 
> so I wouldn't support this NCT (many possible confusions)
> 
> imho LBE was very explicit (and has already been quite often adopted,
> without dilemma : see e.g. QBone)
> perhaps even more explicit than LE, as newly suggested by R.Bless
> 
> what will be the recommended precedence : 1 ?
> 
> jeanpierre.garbisu@francetelecom.fr
> 
> -----Message d'origine-----
> De : Brian E Carpenter [mailto:brian@hursley.ibm.com]
> Envoyé : mardi 12 décembre 2000 00:56
> À : Simon Leinen
> Cc : Yoram Bernet; diffserv@ietf.org
> Objet : Re: LBE PHB [was: [Diffserv] comments on the bulk handling
> draft]
> 
> I agree that the draft deserves recognition. The reason Kathie and I
> wrote our draft was because we don't believe there is any reason
> to define a new PHB to support this type of PDB.
> 
> As Kathie said today, the LBE name is no better chosen than
> BH. Maybe we should call the new PDB "NCT" for Non-Critical Traffic?
> 
>   Brian
> 
> _______________________________________________
> diffserv mailing list
> diffserv@ietf.org
> http://www1.ietf.org/mailman/listinfo/diffserv
> Archive: http://www2.ietf.org/mail-archive/working-groups/diffserv/current/maillist.html

_______________________________________________
diffserv mailing list
diffserv@ietf.org
http://www1.ietf.org/mailman/listinfo/diffserv
Archive: http://www2.ietf.org/mail-archive/working-groups/diffserv/current/maillist.html



From diffserv-admin@ietf.org  Wed Dec 13 13:51: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 SMTP id NAA00923
	for ; Wed, 13 Dec 2000 13:51:29 -0500 (EST)
Received: from optimus.ietf.org (localhost [127.0.0.1])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id NAA09308;
	Wed, 13 Dec 2000 13:29:31 -0500 (EST)
Received: from ietf.org (odin [132.151.1.176])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id NAA09275
	for ; Wed, 13 Dec 2000 13:29:25 -0500 (EST)
Received: from mailhub1.almaden.ibm.com (mailhub1.almaden.ibm.com [198.4.83.44])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id NAA26007
	for ; Wed, 13 Dec 2000 13:29:24 -0500 (EST)
Received: from maui.almaden.ibm.com (maui.almaden.ibm.com [9.1.24.92])
	by mailhub1.almaden.ibm.com (8.8.8/8.8.8) with ESMTP id KAA47534;
	Wed, 13 Dec 2000 10:26:02 -0800
Received: from hursley.ibm.com (gsine02.us.sine.ibm.com [9.14.6.42]) by maui.almaden.ibm.com (AIX4.3/8.9.3/8.7) with ESMTP id KAA27214; Wed, 13 Dec 2000 10:28:53 -0800
Message-ID: <3A37BF8E.45D9F69A@hursley.ibm.com>
Date: Wed, 13 Dec 2000 12:27:26 -0600
From: Brian E Carpenter 
Organization: IBM
X-Mailer: Mozilla 4.61 [en] (Win98; I)
X-Accept-Language: en,fr
MIME-Version: 1.0
To: Juha Heinanen 
CC: "Lemaire, Tom" ,
        "'diffserv@ietf.org'" 
Subject: Re: [Diffserv] Token bucket suggestion in Diffserv Model draft
References: <49FF5C6DDBD8D311BBBD009027DE980C010C43AE@uniwest1.redstonecom.com>
		<3A37A7DB.C2C37564@hursley.ibm.com> <14903.46113.248346.818561@lohi.eng.telia.fi>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Content-Transfer-Encoding: 7bit
Sender: diffserv-admin@ietf.org
Errors-To: diffserv-admin@ietf.org
X-Mailman-Version: 1.0
Precedence: bulk
List-Id: Diffserv Discussion List 
X-BeenThere: diffserv@ietf.org
Content-Transfer-Encoding: 7bit

That's not what I said. Some claim to do it one way and
some claim to do it the other way. In an informal model
why can't we simply recognise this fact of life?

  Brian

Juha Heinanen wrote:
> 
> Brian E Carpenter writes:
> 
>  > We've been round and round on this many times.
>  > Experienced implementors of IP routers tell us that
>  > the loose model is in widespread use (i.e. it is
>  > running code).
> 
> brian, could you tell me me whose router allows me to choose between
> positive and negative leaky buckets?  so far i haven't seen any.  i
> don't think that it a service to the router vendors or those who need to
> configure the boxes to introduce yet another option.
> 
> -- juha

_______________________________________________
diffserv mailing list
diffserv@ietf.org
http://www1.ietf.org/mailman/listinfo/diffserv
Archive: http://www2.ietf.org/mail-archive/working-groups/diffserv/current/maillist.html



From diffserv-admin@ietf.org  Wed Dec 13 13:51:54 2000
Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged))
	by ietf.org (8.9.1a/8.9.1a) with SMTP id NAA00991
	for ; Wed, 13 Dec 2000 13:51:49 -0500 (EST)
Received: from optimus.ietf.org (localhost [127.0.0.1])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id NAA09218;
	Wed, 13 Dec 2000 13:27:46 -0500 (EST)
Received: from ietf.org (odin [132.151.1.176])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id NAA09191
	for ; Wed, 13 Dec 2000 13:27:42 -0500 (EST)
Received: from mailhub1.almaden.ibm.com (mailhub1.almaden.ibm.com [198.4.83.44])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id NAA25787
	for ; Wed, 13 Dec 2000 13:27:41 -0500 (EST)
Received: from maui.almaden.ibm.com (maui.almaden.ibm.com [9.1.24.92])
	by mailhub1.almaden.ibm.com (8.8.8/8.8.8) with ESMTP id KAA33374
	for ; Wed, 13 Dec 2000 10:24:19 -0800
Received: from hursley.ibm.com (gsine02.us.sine.ibm.com [9.14.6.42]) by maui.almaden.ibm.com (AIX4.3/8.9.3/8.7) with ESMTP id KAA20696 for ; Wed, 13 Dec 2000 10:27:11 -0800
Message-ID: <3A37BF28.219E231C@hursley.ibm.com>
Date: Wed, 13 Dec 2000 12:25:44 -0600
From: Brian E Carpenter 
Organization: IBM
X-Mailer: Mozilla 4.61 [en] (Win98; I)
X-Accept-Language: en,fr
MIME-Version: 1.0
To: Diff Serv 
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Content-Transfer-Encoding: 7bit
Subject: [Diffserv] Yesterday's EF discussion
Sender: diffserv-admin@ietf.org
Errors-To: diffserv-admin@ietf.org
X-Mailman-Version: 1.0
Precedence: bulk
List-Id: Diffserv Discussion List 
X-BeenThere: diffserv@ietf.org
Content-Transfer-Encoding: 7bit

Summary of conclusions from EF discussion on 12/12/2000
-------------------------------------------------------

1. After discussion, the 5 possible directions for the EF PHB were
reduced to 4:

0/ Do nothing. The WG agrees that we are not yet ready to replace RFC 2598 
due to lack of consensus. Publish the Charny et al and EFRESOLVE drafts as 
Informational RFCs, and revisit the question in late 2001.

This option was rapidly eliminated by straw poll.

1/ The WG agrees that the work of the EFRESOLVE design team is the basis of the 
revised EF RFC, and that Charny et al should be progressed for the record as an
Informational RFC.

2/  The WG agrees that the  work of Anna Charny's group, modified as in the 
"possible compromise" message sent to the WG by Bruce Davie on Decemebr 7 
is the basis of the revised EF RFC and that the EFRESOLVE draft should be 
published for the record as an Informational RFC.

3/ The WG agrees that the two groups are talking about two different PHBs 
and that they both should be worked on independentlly, as two separate 
standards track documents.

A first straw poll showed that a small majority of those voting would be
prepared to accept two PHBs (option 3).

A second straw poll showed that if only one PHB was to be standardised
to update RFC 2598, a large majority would prefer option 2.

A third straw poll showed that a large majority would prefer only one
PHB (this is not inconsistent with the first straw poll, but it
eliminates option 3).

It was however observed that anyone can submit a PHB to the WG, although
the WG charter currently excludes defining more standard PHBs.

There was insufficient time to discuss the issues of naming and
code points.

----------------------

Proposed expression of WG consensus:
  
   A replacement for RFC 2598 should be drafted, in the strict format
   of a PHB definition as specified in RFC 2474, based on the 
   "possible compromise" revision to the model described in
   draft-charny-ef-definition-01.txt. This is to be progressed as 
   a WG draft intended to be submitted as a Proposed Standard.

Open issues:

   Authorship of the new document.
     Chair's proposal: all contributors to RFC 2598, 
     to draft-charny-ef-definition-01.txt, and to 
     draft-ietf-diffserv-efresolve-00.txt should be recognized as authors.

   Should the recommended code point be 101110?
     Chair's proposal: yes

   What should the name of the PHB be?
     Chair's proposal: Defined Rate (DR). I believe that after this long
     and confusing discussion, it would be wise to retire the previous name.

       Brian Carpenter
       diffserv co-chair

_______________________________________________
diffserv mailing list
diffserv@ietf.org
http://www1.ietf.org/mailman/listinfo/diffserv
Archive: http://www2.ietf.org/mail-archive/working-groups/diffserv/current/maillist.html



From diffserv-admin@ietf.org  Wed Dec 13 13:53: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 SMTP id NAA01251
	for ; Wed, 13 Dec 2000 13:52:59 -0500 (EST)
Received: from optimus.ietf.org (localhost [127.0.0.1])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id NAA08931;
	Wed, 13 Dec 2000 13:17:06 -0500 (EST)
Received: from ietf.org (odin [132.151.1.176])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id NAA08900
	for ; Wed, 13 Dec 2000 13:17:01 -0500 (EST)
Received: from p-mail1.cnet.fr (p-mail1.rd.francetelecom.fr [193.49.124.31])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id NAA24442
	for ; Wed, 13 Dec 2000 13:17:00 -0500 (EST)
Received: by p-biset.issy.cnet.fr with Internet Mail Service (5.5.2650.21)
	id ; Wed, 13 Dec 2000 18:34:50 +0100
Message-ID: <98388C05D464D111B61800805F15041601418A6F@p-ibis.issy.cnet.fr>
From: ROBERTS James FTRD/DAC/ISS 
To: "'g_mercankosk@yahoo.com'" , diffserv@ietf.org
Cc: guven@ee.uwa.edu.au
Subject: RE: [Diffserv] Possible compromise between EFRESOLVE and draft-ch
	   arny
Date: Wed, 13 Dec 2000 18:34:49 +0100
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2650.21)
Content-Type: text/plain;
	charset="ISO-8859-1"
Sender: diffserv-admin@ietf.org
Errors-To: diffserv-admin@ietf.org
X-Mailman-Version: 1.0
Precedence: bulk
List-Id: Diffserv Discussion List 
X-BeenThere: diffserv@ietf.org

Guven,
> > 
> > I was referring to the calculation of worst case
> > burstiness necessary to
> > define deterministic bounds. Rereading your draft
> > from July, I imagine you
> > are thinking more in terms of probabilistic bounds,
> > eg, the probability end
> > to end delay is greater some bound D should not
> > exceed epsilon. I would
> > certainly agree that this is a more satisfactory
> > approach.
> 
> May be that design team should seriously consider this
> approach.
> 

I just think the EF definition should allow provision of services with
statistical guarantees (as well as other services with deterministic
guarantees, if possible). However, it is probably not be useful to define
such services in standards and it is certainly outside the WG charter. 

Regarding your other comments, I think we should take up a discussion on
statistical performance off list. As to bounding the maximum
(deterministic)delay, the difficulty in coming up with effective engineering
procedures is amply illustrated in the Charny, Le Boudec paper. Have you
looked at this? 

Regards,
Jim
>
> > However, even here, I don't think it is possible to
> > characterize burstiness
> > at interfaces within the network. At least not in
> > terms of maximally sized
> > bursts or an envelope arrival function like that
> > defined by a token bucket. 
> > 
> > This was a problem considered in the context of ATM
> > where CBR connections
> > are characterized in terms of the GCRA (almost a
> > token bucket). I am not
> > aware of any work successfully explaining how the
> > GCRA parameters should
> > evolve as the CBR stream acquires burstiness along
> > its path through the
> > network. This is an unsolved problem.
> 
> First consider just one hop. Couldn't we simply set
> the GCRA parameters as the reciprocal of  the stream
> rate and the D as the tolerance? The probability that 
> a given packet not complying be less than epsilon. At
> multiple hops, determine the corresponding delay bound
> and used that as a tolerance. Is there anything 
> wrong with this thinking?
>  
> > In your draft, if my interpretation is correct, you
> > assume the acquired
> > burstiness is negligible in the sense that you can
> > assume (M+D)/D/1 queuing
> > at any node to derive the statistical delay bound.
> > In this way you do not
> > need to characterize burstiness in a quantifiable
> > way. I am inclined to
> > agree with you and we have some work which claims
> > more or less the same
> > thing. 
> 
> But when all micro-flows are properly controled at the
> ingress, and say that they are spaced, any burstiness
> is due to phase coincidences. Under the circumstances
> why do we have to need to characterize the burstiness.
> I do like calling this burstiness. I rather refer to
> it as jitter accumulation. I suppose you refer to it
> as negligible. Given my previous argument, we have a
> characterization of it anyway.
> 
> In the case of the superposition of periodic arrivals
> with FIFO queueing, the maximum delay is the number of
> sources competing times one packet transmission time.
> Irrespective of whether they are homogeneous or
> heterogeneous. The former case will always have a
> larger bound than the latter. Again this is over one 
> hop. Now if we split the aggregate at the next hop in
> such a way that a given micro flow now competes with a
> new set of micro flows at the next hop, the maximum
> delay over two hops can only be increased by the
> number of micro flows joining in. Does this not give
> us a deterministic characterization of burstiness? I
> would like to conjecture that even when multiple micro
> flows split together the maximum delay will not be
> increased any more than the number of micro flows
> joining in. I could see that this could have an impact
> on the streams just joining in, in the sense that
> their delay could be larger than the case of a single
> hop. However, if you look at the example in Appendix F
> of my draft, when the test stream takes lesser number
> of hops its delay distribution actually gets better.
> This may not be the exact answer you are looking for
> but it may trigger some thoughts.
>  
> > To justify your probabilistic arguments you assume
> > first that the EF
> > aggregates only interfere with each other in FIFO
> > queues. You then consider
> > the impact of non-EF packets assuming priority
> > queuing. It seems to me
> > therefore that you should be agreeing with me that
> > an EF PHB definition
> > allowing a clear expression of these assumptions is
> > preferable to one which
> > relies on an unspecified characterization of
> > burstiness in order to justify
> > deterministic bounds.
> >
> 
> I am all for such clarification. I am really amazed
> how we can make things more convoluted than necessary
> :-)
> 
> Cheers,
> Guven.
> 
> 
> 
> __________________________________________________
> Do You Yahoo!?
> Yahoo! Shopping - Thousands of Stores. Millions of Products.
> http://shopping.yahoo.com/
> 

_______________________________________________
diffserv mailing list
diffserv@ietf.org
http://www1.ietf.org/mailman/listinfo/diffserv
Archive: http://www2.ietf.org/mail-archive/working-groups/diffserv/current/maillist.html



From diffserv-admin@ietf.org  Wed Dec 13 13:56:28 2000
Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged))
	by ietf.org (8.9.1a/8.9.1a) with SMTP id NAA02094
	for ; Wed, 13 Dec 2000 13:56:27 -0500 (EST)
Received: from optimus.ietf.org (localhost [127.0.0.1])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id NAA09493;
	Wed, 13 Dec 2000 13:31:24 -0500 (EST)
Received: from ietf.org (odin [132.151.1.176])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id NAA09462
	for ; Wed, 13 Dec 2000 13:31:20 -0500 (EST)
Received: from mailhub1.almaden.ibm.com (mailhub1.almaden.ibm.com [198.4.83.44])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id NAA26334
	for ; Wed, 13 Dec 2000 13:31:19 -0500 (EST)
Received: from maui.almaden.ibm.com (maui.almaden.ibm.com [9.1.24.92])
	by mailhub1.almaden.ibm.com (8.8.8/8.8.8) with ESMTP id KAA42798;
	Wed, 13 Dec 2000 10:27:56 -0800
Received: from hursley.ibm.com (gsine02.us.sine.ibm.com [9.14.6.42]) by maui.almaden.ibm.com (AIX4.3/8.9.3/8.7) with ESMTP id KAA20804; Wed, 13 Dec 2000 10:30:48 -0800
Message-ID: <3A37BFFE.CF247C86@hursley.ibm.com>
Date: Wed, 13 Dec 2000 12:29:18 -0600
From: Brian E Carpenter 
Organization: IBM
X-Mailer: Mozilla 4.61 [en] (Win98; I)
X-Accept-Language: en,fr
MIME-Version: 1.0
To: "Lemaire, Tom" 
CC: "'diffserv@ietf.org'" 
Subject: Re: [Diffserv] Token bucket suggestion in Diffserv Model draft
References: <49FF5C6DDBD8D311BBBD009027DE980C010C43B2@uniwest1.redstonecom.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 my experience when we try to include this sort of rationale
in documents, we never reach consensus.

  Brian

"Lemaire, Tom" wrote:
> 
> hi Brian,
> 
> It's OK if the loose model is in the draft and
> also in widespread use.  I think it's great it's
> in the draft, it makes you think about it.
> But I am asking the authors to clarify the
> problem domain that loose buckets address, at least
> to the list.  If that text was included in the draft,
> that would seemingly only enhance the understanding
> of the reader of the draft.
> 
> As it stands, the draft does not explicitly say
> whether loose buckets are TCP friendly or not,
> though it touches on the subject of TCP.  If this
> is not yet known, that would also be a reasonable
> statement, that loose buckets interaction with TCP
> are a subject for further research.
> 
> There is a risk that the reader will infer that loose
> buckets are a specification for what underlies the
> TCP friendly mechanisms that are deployed in existing
> products.  I believe those implementations are more
> sophisticated than the negative count token bucket
> described in the draft.
> 
> Tom L
> 
> -----Original Message-----
> From: Brian E Carpenter [mailto:brian@hursley.ibm.com]
> Sent: Wednesday, December 13, 2000 11:46 AM
> To: Lemaire, Tom
> Cc: 'diffserv@ietf.org'
> Subject: Re: [Diffserv] Token bucket suggestion in Diffserv Model draft
> 
> Tom,
> 
> We've been round and round on this many times.
> Experienced implementors of IP routers tell us that
> the loose model is in widespread use (i.e. it is
> running code). That is enough to include it in the model
> and that's what the WG settled on a while back. We also agreed
> to include the strict model because other implementors
> want it. Since we are *months* late with this document,
> I think we should just go with what we have now.
> 
>   Brian
> 
> "Lemaire, Tom" wrote:
> >
> > I'd like it if the draft authors could clarify
> > the problems that negative count token buckets
> > are trying to solve.
> >
> > A reader of the draft might infer they are
> > more TCP friendly, since the existing positive
> > count token buckets are not particularly
> > TCP friendly, and maybe someone wanted to address
> > that.  But in fact their perceived leniency does
> > not help TCP, since they still drop multiple
> > back-to-back packets in a TCP burst.  And as Shahram's
> > revised text of Monday points out, they are biased
> > against small packets, e.g. TCP ACKs, and that seems
> > TCP unfriendly.
> >
> > But perhaps they are good for TCP in some ways, or
> > good for some other application.  It would be helpful
> > if the authors could give examples of where negative
> > count token buckets are an improvement over the positive
> > count.
> >
> > Tom Lemaire
> > Unisphere Networks
> >
> > _______________________________________________
> > diffserv mailing list
> > diffserv@ietf.org
> > http://www1.ietf.org/mailman/listinfo/diffserv
> > Archive:
> http://www2.ietf.org/mail-archive/working-groups/diffserv/current/maillist.h
> tml
> 
> _______________________________________________
> diffserv mailing list
> diffserv@ietf.org
> http://www1.ietf.org/mailman/listinfo/diffserv
> Archive: http://www2.ietf.org/mail-archive/working-groups/diffserv/current/maillist.html

_______________________________________________
diffserv mailing list
diffserv@ietf.org
http://www1.ietf.org/mailman/listinfo/diffserv
Archive: http://www2.ietf.org/mail-archive/working-groups/diffserv/current/maillist.html



From diffserv-admin@ietf.org  Wed Dec 13 13:59: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 SMTP id NAA02731
	for ; Wed, 13 Dec 2000 13:59:22 -0500 (EST)
Received: from optimus.ietf.org (localhost [127.0.0.1])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id NAA09614;
	Wed, 13 Dec 2000 13:34:48 -0500 (EST)
Received: from ietf.org (odin [132.151.1.176])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id NAA09583
	for ; Wed, 13 Dec 2000 13:34:44 -0500 (EST)
Received: from mailhub1.almaden.ibm.com (mailhub1.almaden.ibm.com [198.4.83.44])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id NAA27113
	for ; Wed, 13 Dec 2000 13:34:43 -0500 (EST)
Received: from maui.almaden.ibm.com (maui.almaden.ibm.com [9.1.24.92])
	by mailhub1.almaden.ibm.com (8.8.8/8.8.8) with ESMTP id KAA47830;
	Wed, 13 Dec 2000 10:31:09 -0800
Received: from hursley.ibm.com (gsine02.us.sine.ibm.com [9.14.6.42]) by maui.almaden.ibm.com (AIX4.3/8.9.3/8.7) with ESMTP id KAA09540; Wed, 13 Dec 2000 10:34:00 -0800
Message-ID: <3A37C0BE.676CB884@hursley.ibm.com>
Date: Wed, 13 Dec 2000 12:32:30 -0600
From: Brian E Carpenter 
Organization: IBM
X-Mailer: Mozilla 4.61 [en] (Win98; I)
X-Accept-Language: en,fr
MIME-Version: 1.0
To: g_mercankosk@yahoo.com
CC: jh@lohi.eng.telia.fi, Shahram_Davari@pmc-sierra.com, diffserv@ietf.org,
        guven@ee.uwa.edu.au
Subject: Re: [Diffserv] Token bucket suggestion in Diffserv Model draft
References: <20001213180049.27756.qmail@web4201.mail.yahoo.com>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Content-Transfer-Encoding: 7bit
Sender: diffserv-admin@ietf.org
Errors-To: diffserv-admin@ietf.org
X-Mailman-Version: 1.0
Precedence: bulk
List-Id: Diffserv Discussion List 
X-BeenThere: diffserv@ietf.org
Content-Transfer-Encoding: 7bit

As I said, we've had this discussion, reached a consensus, and
now people want to reopen it. I don't think that's reasonable,
especially since this is an informational description of an
informal model.

  Brian

g_mercankosk@yahoo.com wrote:
> 
> Brian,
> 
> I would like to second Juha's point.
> 
> It should be noted that the bucket depth in the case
> of positive-count has one-to-one correspondence as to
> how early a packet can arrive. Whereas in the case of
> negative count one losses that property. I appreciate
> the possibility of using negative-count. But I believe
> that it is not inline with the intent of leaky-bucket.
> 
> Guven.
> 
> Juha Heinanen wrote:
> 
>   Brian E Carpenter writes:
> 
>    > That would reverse the previous consensus, which
> was to include both.
> 
>   i had big backlog of diffserv mail caused by the ef
> war and didn't know if there was a consensus.  i still
> see no point in introducing just like that in a
> diffserv document a totally new concept of negative
> leaky bucket that ietf, itu, or nobody else that i
> know of has so far had anywhere.
> 
>   -- juha
> 
> __________________________________________________
> Do You Yahoo!?
> Yahoo! Shopping - Thousands of Stores. Millions of Products.
> http://shopping.yahoo.com/

_______________________________________________
diffserv mailing list
diffserv@ietf.org
http://www1.ietf.org/mailman/listinfo/diffserv
Archive: http://www2.ietf.org/mail-archive/working-groups/diffserv/current/maillist.html



From diffserv-admin@ietf.org  Wed Dec 13 14:46:44 2000
Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged))
	by ietf.org (8.9.1a/8.9.1a) with SMTP id OAA10077
	for ; Wed, 13 Dec 2000 14:46:44 -0500 (EST)
Received: from optimus.ietf.org (localhost [127.0.0.1])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id OAA11043;
	Wed, 13 Dec 2000 14:24:03 -0500 (EST)
Received: from ietf.org (odin [132.151.1.176])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id OAA11013
	for ; Wed, 13 Dec 2000 14:23:50 -0500 (EST)
Received: from lohi.eng.telia.fi (lohi.eng.telia.fi [195.10.149.18])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id OAA07434
	for ; Wed, 13 Dec 2000 14:23:48 -0500 (EST)
Received: (from jh@localhost)
	by lohi.eng.telia.fi (8.11.1/8.11.1/Debian 8.11.0-6) id eBDJNki18763;
	Wed, 13 Dec 2000 21:23:46 +0200
From: Juha Heinanen 
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Message-ID: <14903.52418.774173.805712@lohi.eng.telia.fi>
Date: Wed, 13 Dec 2000 21:23:46 +0200 (EET)
To: Brian E Carpenter 
Cc: "Lemaire, Tom" ,
        "'diffserv@ietf.org'" 
Subject: Re: [Diffserv] Token bucket suggestion in Diffserv Model draft
In-Reply-To: <3A37BF8E.45D9F69A@hursley.ibm.com>
References: <49FF5C6DDBD8D311BBBD009027DE980C010C43AE@uniwest1.redstonecom.com>
	<3A37A7DB.C2C37564@hursley.ibm.com>
	<14903.46113.248346.818561@lohi.eng.telia.fi>
	<3A37BF8E.45D9F69A@hursley.ibm.com>
X-Mailer: VM 6.75 under Emacs 19.34.1
Content-Transfer-Encoding: 7bit
Sender: diffserv-admin@ietf.org
Errors-To: diffserv-admin@ietf.org
X-Mailman-Version: 1.0
Precedence: bulk
List-Id: Diffserv Discussion List 
X-BeenThere: diffserv@ietf.org
Content-Transfer-Encoding: 7bit

Brian E Carpenter writes:

 > That's not what I said. Some claim to do it one way and
 > some claim to do it the other way. In an informal model
 > why can't we simply recognise this fact of life?

tell me then which vendor implement token bucket using the negative
definition?

-- juha

_______________________________________________
diffserv mailing list
diffserv@ietf.org
http://www1.ietf.org/mailman/listinfo/diffserv
Archive: http://www2.ietf.org/mail-archive/working-groups/diffserv/current/maillist.html



From diffserv-admin@ietf.org  Wed Dec 13 15:12:06 2000
Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged))
	by ietf.org (8.9.1a/8.9.1a) with SMTP id PAA13270
	for ; Wed, 13 Dec 2000 15:12:05 -0500 (EST)
Received: from optimus.ietf.org (localhost [127.0.0.1])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id OAA11639;
	Wed, 13 Dec 2000 14:48:35 -0500 (EST)
Received: from ietf.org (odin [132.151.1.176])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id OAA11610
	for ; Wed, 13 Dec 2000 14:48:26 -0500 (EST)
Received: from lohi.eng.telia.fi (lohi.eng.telia.fi [195.10.149.18])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id OAA10258
	for ; Wed, 13 Dec 2000 14:48:24 -0500 (EST)
Received: (from jh@localhost)
	by lohi.eng.telia.fi (8.11.1/8.11.1/Debian 8.11.0-6) id eBDJmHt18784;
	Wed, 13 Dec 2000 21:48:17 +0200
From: Juha Heinanen 
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Message-ID: <14903.53889.373999.616332@lohi.eng.telia.fi>
Date: Wed, 13 Dec 2000 21:48:17 +0200 (EET)
To: Brian E Carpenter 
Cc: Diff Serv 
Subject: [Diffserv] Yesterday's EF discussion
In-Reply-To: <3A37BF28.219E231C@hursley.ibm.com>
References: <3A37BF28.219E231C@hursley.ibm.com>
X-Mailer: VM 6.75 under Emacs 19.34.1
Content-Transfer-Encoding: 7bit
Sender: diffserv-admin@ietf.org
Errors-To: diffserv-admin@ietf.org
X-Mailman-Version: 1.0
Precedence: bulk
List-Id: Diffserv Discussion List 
X-BeenThere: diffserv@ietf.org
Content-Transfer-Encoding: 7bit

Brian E Carpenter writes:

 >    What should the name of the PHB be?
 >      Chair's proposal: Defined Rate (DR). I believe that after this long
 >      and confusing discussion, it would be wise to retire the previous name.

if i implement an af class by assigning it to a wfq of a certain weight,
it defines a rate for that class.  does this mean that by proper
admission control to that class, i can in fact implement using an af
class a service that is equivalent to a service that would result if i
would be using the dr phb instead?  if so, do we really need (for other
than political reasons) ef or this new thing?

this brings me back to a point that i have made before, i.e., i feel
that the whole phb concept is not that useful.  what is useful is the
description of the actual (queuing, droping, policing, etc.) mechanisms
that the routers may implement and a way to validate them.  a well
documented list of such mechanisms including their parametrization would
be to the buyer of a router a much more useful thing than a claim that
the router implements a certain list of phbs.

-- juha

_______________________________________________
diffserv mailing list
diffserv@ietf.org
http://www1.ietf.org/mailman/listinfo/diffserv
Archive: http://www2.ietf.org/mail-archive/working-groups/diffserv/current/maillist.html



From diffserv-admin@ietf.org  Wed Dec 13 15:53: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 SMTP id PAA20422
	for ; Wed, 13 Dec 2000 15:53:11 -0500 (EST)
Received: from optimus.ietf.org (localhost [127.0.0.1])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id PAA12555;
	Wed, 13 Dec 2000 15:31:51 -0500 (EST)
Received: from ietf.org (odin [132.151.1.176])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id PAA12443
	for ; Wed, 13 Dec 2000 15:31:43 -0500 (EST)
Received: from usc.edu (root@usc.edu [128.125.253.136])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id PAA17370
	for ; Wed, 13 Dec 2000 15:31:41 -0500 (EST)
Received: from koh-sun018.usc.edu (demir@koh-sun018.usc.edu [128.125.5.126])
	by usc.edu (8.9.3.1/8.9.3/usc) with ESMTP
	id MAA19178; Wed, 13 Dec 2000 12:31:39 -0800 (PST)
Received: from localhost (demir@localhost)
	by koh-sun018.usc.edu (8.9.3.1/8.9.3/usc) with ESMTP
	id MAA11720; Wed, 13 Dec 2000 12:31:39 -0800 (PST)
Date: Wed, 13 Dec 2000 12:31:39 -0800 (PST)
From: demir 
To: Juha Heinanen 
cc: Brian E Carpenter , Diff Serv 
Subject: Re: [Diffserv] Yesterday's EF discussion
In-Reply-To: <14903.53889.373999.616332@lohi.eng.telia.fi>
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

Very nice points. That's how I feel, too.

Alper K. Demir

> if i implement an af class by assigning it to a wfq of a certain weight,
> it defines a rate for that class.  does this mean that by proper
> admission control to that class, i can in fact implement using an af
> class a service that is equivalent to a service that would result if i
> would be using the dr phb instead?  if so, do we really need (for other
> than political reasons) ef or this new thing?

> 
> this brings me back to a point that i have made before, i.e., i feel
> that the whole phb concept is not that useful.  what is useful is the
> description of the actual (queuing, droping, policing, etc.) mechanisms
> that the routers may implement and a way to validate them.  a well
> documented list of such mechanisms including their parametrization would
> be to the buyer of a router a much more useful thing than a claim that
> the router implements a certain list of phbs.
> 
> -- juha
> 
> _______________________________________________
> diffserv mailing list
> diffserv@ietf.org
> http://www1.ietf.org/mailman/listinfo/diffserv
> Archive: http://www2.ietf.org/mail-archive/working-groups/diffserv/current/maillist.html
> 


_______________________________________________
diffserv mailing list
diffserv@ietf.org
http://www1.ietf.org/mailman/listinfo/diffserv
Archive: http://www2.ietf.org/mail-archive/working-groups/diffserv/current/maillist.html



From diffserv-admin@ietf.org  Wed Dec 13 15:57: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 SMTP id PAA20878
	for ; Wed, 13 Dec 2000 15:57:15 -0500 (EST)
Received: from optimus.ietf.org (localhost [127.0.0.1])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id PAA12580;
	Wed, 13 Dec 2000 15:31:53 -0500 (EST)
Received: from ietf.org (odin [132.151.1.176])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id PAA12515
	for ; Wed, 13 Dec 2000 15:31:47 -0500 (EST)
Received: from exchsrv1.cosinecom.com (mail.cosinecom.com [63.88.104.16])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id PAA17386
	for ; Wed, 13 Dec 2000 15:31:45 -0500 (EST)
Received: by exchsrv1.cosinecom.com with Internet Mail Service (5.5.2650.21)
	id ; Wed, 13 Dec 2000 12:29:27 -0800
Message-ID: <7EB7C6B62C4FD41196A80090279A2911D8AB1D@exchsrv1.cosinecom.com>
From: Jay Wang 
To: "'Juha Heinanen'" ,
        Brian E Carpenter
	 
Cc: Diff Serv 
Subject: RE: [Diffserv] Yesterday's EF discussion
Date: Wed, 13 Dec 2000 12:29:18 -0800
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2650.21)
Content-Type: multipart/alternative;
	boundary="----_=_NextPart_001_01C06543.5E06C4D0"
Sender: diffserv-admin@ietf.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_01C06543.5E06C4D0
Content-Type: text/plain;
	charset="iso-8859-1"

Juha,

I respectfully disagree with your proposition. Regardless of how 
we define these PHBs, I am sure that every box vender would have 
a description of their underneath mechanisms (such as classifier, 
meter, shaper, scheduler, etc) that support Diffserv available to 
its customers.  By tuning all the knobs, the customers can surely 
create different services within the capacity allowed by the system.  
However, this does not necessarily imply that well defined PHBs are 
useless. For Diffserv (and more generally QoS as a whole) to be 
accepted by the service provider community and the general public, 
complexity in deploying, engineering, and using QoS-enabled services 
has to be minimized. I thing some well known and well defined PHBs that 
"wrap" around the underneath mechanisms in the routers/switches provide 
the first step toward that objective. The question is how do we do it 
right and I think this is what the WG has been trying hard to achieve.

Regards, 

- Jay

----------------------------------
Jay Wang,	Cosine Communications
Voice: (650) 628-4296	Fax: (509) 694-6065


> -----Original Message-----
> From: Juha Heinanen [mailto:jh@lohi.eng.telia.fi]
> Sent: Wednesday, December 13, 2000 11:48 AM
> To: Brian E Carpenter
> Cc: Diff Serv
> Subject: [Diffserv] Yesterday's EF discussion
> 
> 
> Brian E Carpenter writes:
> 
>  >    What should the name of the PHB be?
>  >      Chair's proposal: Defined Rate (DR). I believe that 
> after this long
>  >      and confusing discussion, it would be wise to retire 
> the previous name.
> 
> if i implement an af class by assigning it to a wfq of a 
> certain weight,
> it defines a rate for that class.  does this mean that by proper
> admission control to that class, i can in fact implement using an af
> class a service that is equivalent to a service that would result if i
> would be using the dr phb instead?  if so, do we really need 
> (for other
> than political reasons) ef or this new thing?
> 
> this brings me back to a point that i have made before, i.e., i feel
> that the whole phb concept is not that useful.  what is useful is the
> description of the actual (queuing, droping, policing, etc.) 
> mechanisms
> that the routers may implement and a way to validate them.  a well
> documented list of such mechanisms including their 
> parametrization would
> be to the buyer of a router a much more useful thing than a claim that
> the router implements a certain list of phbs.
> 
> -- juha
> 
> _______________________________________________
> diffserv mailing list
> diffserv@ietf.org
> http://www1.ietf.org/mailman/listinfo/diffserv
> Archive: 
> http://www2.ietf.org/mail-archive/working-groups/diffserv/curr
ent/maillist.html

------_=_NextPart_001_01C06543.5E06C4D0
Content-Type: text/html;
	charset="iso-8859-1"






RE: [Diffserv] Yesterday's EF discussion




Juha,




I respectfully disagree with your proposition. Regardless of how 

we define these PHBs, I am sure that every box vender would have 

a description of their underneath mechanisms (such as classifier, 

meter, shaper, scheduler, etc) that support Diffserv available to 

its customers.  By tuning all the knobs, the customers can surely 

create different services within the capacity allowed by the system.  

However, this does not necessarily imply that well defined PHBs are 

useless. For Diffserv (and more generally QoS as a whole) to be 

accepted by the service provider community and the general public, 

complexity in deploying, engineering, and using QoS-enabled services 

has to be minimized. I thing some well known and well defined PHBs that 

"wrap" around the underneath mechanisms in the routers/switches provide 

the first step toward that objective. The question is how do we do it 

right and I think this is what the WG has been trying hard to achieve.




Regards, 




- Jay




----------------------------------

Jay Wang,       Cosine Communications

Voice: (650) 628-4296   Fax: (509) 694-6065






> -----Original Message-----

> From: Juha Heinanen [mailto:jh@lohi.eng.telia.fi]

> Sent: Wednesday, December 13, 2000 11:48 AM

> To: Brian E Carpenter

> Cc: Diff Serv

> Subject: [Diffserv] Yesterday's EF discussion

> 

> 

> Brian E Carpenter writes:

> 

>  >    What should the name of the PHB be?

>  >      Chair's proposal: Defined Rate (DR). I believe that 

> after this long

>  >      and confusing discussion, it would be wise to retire 

> the previous name.

> 

> if i implement an af class by assigning it to a wfq of a 

> certain weight,

> it defines a rate for that class.  does this mean that by proper

> admission control to that class, i can in fact implement using an af

> class a service that is equivalent to a service that would result if i

> would be using the dr phb instead?  if so, do we really need 

> (for other

> than political reasons) ef or this new thing?

> 

> this brings me back to a point that i have made before, i.e., i feel

> that the whole phb concept is not that useful.  what is useful is the

> description of the actual (queuing, droping, policing, etc.) 

> mechanisms

> that the routers may implement and a way to validate them.  a well

> documented list of such mechanisms including their 

> parametrization would

> be to the buyer of a router a much more useful thing than a claim that

> the router implements a certain list of phbs.

> 

> -- juha

> 

> _______________________________________________

> diffserv mailing list

> diffserv@ietf.org

> http://www1.ietf.org/mailman/listinfo/diffserv

> Archive: 

> http://www2.ietf.org/mail-archive/working-groups/diffserv/curr

ent/maillist.html





------_=_NextPart_001_01C06543.5E06C4D0--

_______________________________________________
diffserv mailing list
diffserv@ietf.org
http://www1.ietf.org/mailman/listinfo/diffserv
Archive: http://www2.ietf.org/mail-archive/working-groups/diffserv/current/maillist.html



From diffserv-admin@ietf.org  Wed Dec 13 16:21:40 2000
Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged))
	by ietf.org (8.9.1a/8.9.1a) with SMTP id QAA23845
	for ; Wed, 13 Dec 2000 16:21:40 -0500 (EST)
Received: from optimus.ietf.org (localhost [127.0.0.1])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id PAA12876;
	Wed, 13 Dec 2000 15:54:15 -0500 (EST)
Received: from ietf.org (odin [132.151.1.176])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id PAA12847
	for ; Wed, 13 Dec 2000 15:54:10 -0500 (EST)
Received: from sj-msg-core-2.cisco.com (sj-msg-core-2.cisco.com [171.69.43.88])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id PAA20536
	for ; Wed, 13 Dec 2000 15:54:08 -0500 (EST)
Received: from p7020-img-nt.cisco.com (sj-dial-3-173.cisco.com [171.68.180.174])
	by sj-msg-core-2.cisco.com (8.9.3/8.9.1) with ESMTP id MAA23261
	for ; Wed, 13 Dec 2000 12:53:40 -0800 (PST)
Message-Id: <5.0.2.1.2.20001213100135.0308d050@flipper.cisco.com>
X-Sender: fred@flipper.cisco.com
X-Mailer: QUALCOMM Windows Eudora Version 5.0.2
Date: Wed, 13 Dec 2000 10:19:46 -0800
To: diffserv@ietf.org
From: Fred Baker 
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"; format=flowed
Subject: [Diffserv] Counters in the classifier
Sender: diffserv-admin@ietf.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 need to discuss with the working group the outcome of the discussion of 
Bob Moore's counter in the classifier. I believe that the working group 
came to an inappropriate decision, and I want to present my case. Yes, this 
should have happened in the working group meeting; I wound up wrapped 
around a Secretariat-shaped axle a good part of Monday, and made only a few 
minutes of that meeting.

First, IMHO, any discussion, anywhere, of a programmable counter is 
nonsense. In software, the difference between

	pointer = table->pointer_to_chounter;
	if (NULL != pointer) {
		pointer->packets ++;
		pointer->octets += packet->length;
	}

and

	table->counter.packets++;
	table->counter.octets += packet->length;

is three things: the indirection of the counter, and the pipeline stall in 
the branch, and several extra instructions. When you are trying to go 
quickly (say "OC-n"), each of these is important.

The corollary in hardware is that one rarely builds indirections and such 
there; you can define memory for a register set, link them together, and 
provide optional adders, but reality is that it is less silicon, and 
therefore cheaper and less complex, to simply implement the register.

As a result, any discussion of an optional counter is not an option as to 
whether it will be counted - it is cheaper, simpler, and faster to 
implement the counter. This is an option of whether to display it.


There is an additional cost, also - a round trip. I can't tell to read 
counter foo about classifier bar unless I know that counter foo and 
classifier bar are related. If I can read the classifier and get the 
counter with it, that is one SNMP GET. If I read a rowpointer and then have 
to again read to get the counters, that's two round trips. That may not be 
important conceptually, but operationally, when debugging a device across 
the network and knowing that my classifier is potentially not doing the 
right thing and trying to figure out what it is doing, this is a lot more 
than "so turn on classifiers for the various options and see which one 
counts". It is "turn on classifiers for the various options, attach 
counters to them, and then to see which one counts go read the individual 
counters back." It may mean nothing to a vendor, but to an operator whose 
primary job is making the PCs (which outnumber routers 40:1) work, and is 
now doing his secondary job of making the router work, and by the way has 
other pressing demands, it is unnecessary complexity, time, and so on. Go 
buy Randy Bush a drink some time and get him to explain what his problem 
with diff-serv, SNMP, policy, MPLS, and a list of others things is: the 
discussion will revolve around "simpleness is next to godliness" with a 
liberal dose of "this is just plain not simple."


I'll go further. Every counter costs something, and what is above is two 
counters. We have had a rule in MIB design for at least the past 15 years 
(RFC 1493 includes a short discussion of this) that we try to avoid having 
more than one counter in any data path, and we make an exception for normal 
data throughput because there is a strong need to know both octets and 
packets arriving and departing on an interface. Any extra counter gets a 
strong push back from network managers, because they want to know what they 
are supposed to do when it counts. What this counter is for is debugging 
classifiers; you want to know whether something is arriving, and then see 
what happens to it later. I understand packet counters here, but I don't 
understand an octet counter. If you argue it based on rates, that's what 
the meter is for later in the TCB, and the rate through one classification 
doesn't necessarily correlate with the aggregate being handed to that meter.

What I see here is a pretty expensive piece of technology with no obvious 
benefit. I see extra complexity (in the indirections) that costs more than 
it produces in benefit. I predict partial implementations or failure to 
implement. Both are bad. You just want a packet counter in the classifier 
and be done with it. Going with an indirect dual counter to determine 
whether a classifier is finding anything to classify is creeping elegance 
at its worst.

I can make the same argument for the counter action itself; there is no 
general need for the octet counter, and it is something you are always 
going to configure, at least operationally. But I'm not going to push that, 
as we have had that discussion in the past.


The remaining concern is for people with diffserv implementations who don't 
have this counter. For the record, in some of my products, I'm one of them; 
this is not a position where I am driving vendor interest. But in other of 
my products, I have a counter on every access list (a form of classifier), 
which is there to enable the network operator to debug his access lists. It 
is my understanding that this is essentially what this proposed counter is 
for. I can tell you that, to my knowledge, no customer has ever asked for 
rates on the classifiers themselves; they have asked for rates in other 
contexts, but not bit or byte rates on access-list hits. "matching packet" 
counters seem to be quite adequate for this job. In the diffserv 
architecture, if we *do* need a meter for an SLA, it is not the classifier 
we will do that on, but on a meter or an action.


So this is my proposal. Kwok and I are editing the MIB this morning, with a 
view to this outcome, Andrew's comments, and some comments from Bert 
relating to TCs (want to pull them together into a separate module and do 
some minor tweaks). We will put in a packet counter in the classifier, and 
the chairs can tell us we did it wrong.

Your comments, please.


_______________________________________________
diffserv mailing list
diffserv@ietf.org
http://www1.ietf.org/mailman/listinfo/diffserv
Archive: http://www2.ietf.org/mail-archive/working-groups/diffserv/current/maillist.html



From diffserv-admin@ietf.org  Wed Dec 13 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 SMTP id QAA24262
	for ; Wed, 13 Dec 2000 16:25:10 -0500 (EST)
Received: from optimus.ietf.org (localhost [127.0.0.1])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id PAA12907;
	Wed, 13 Dec 2000 15:54:22 -0500 (EST)
Received: from ietf.org (odin [132.151.1.176])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id PAA12880
	for ; Wed, 13 Dec 2000 15:54:15 -0500 (EST)
Received: from sj-msg-core-2.cisco.com (sj-msg-core-2.cisco.com [171.69.43.88])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id PAA20538
	for ; Wed, 13 Dec 2000 15:54:12 -0500 (EST)
Received: from p7020-img-nt.cisco.com (sj-dial-3-173.cisco.com [171.68.180.174])
	by sj-msg-core-2.cisco.com (8.9.3/8.9.1) with ESMTP id MAA23315;
	Wed, 13 Dec 2000 12:53:44 -0800 (PST)
Message-Id: <5.0.2.1.2.20001213102137.03890ad0@flipper.cisco.com>
X-Sender: fred@flipper.cisco.com
X-Mailer: QUALCOMM Windows Eudora Version 5.0.2
Date: Wed, 13 Dec 2000 11:29:57 -0800
To: Andrew Smith 
From: Fred Baker 
Subject: Re: [Diffserv] Diffserv MIB - editorial comments (part 1)
Cc: diffserv , khchan@nortelnetworks.com
In-Reply-To: <3A349D3C.1090803@allegronetworks.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

Kwok and I are having an editing-fest.


At 01:24 AM 12/11/00 -0800, Andrew Smith wrote:
>1. General: make consistent Diffserv and DiffServ. Other documents have 
>generally chosen "Diffserv".

We did so throughout the text. We did not, however, change the names of 
objects, as the capital letter separates words, and this in context seems 
like a separate word.

>2. General: several places where it says "Notice that ..." - these should 
>be replaced by "NOTE: ...": this is standards-speak for indicating that 
>the following is just explanation and is not making any normative rules.

Done

>3. Abstract: "Differentiated Services Router Informal Management Model" -> 
>"Informal Management Model for Diffserv Routers"

We replaced those usages with "[MODEL]"

>4. 2.1 instructmentation -> instrumentation

Done

>5. 2.1 functionalities  -> functionality

Done

>3. 2.1 "and only mentioned" -> and is only mentioned"

Done

>4. 2.1 "By not including TCB notion in its parameters, this
>MIB allow any grouping of elements to construct TCBs, using rules
>indicated by the [MODEL].  This will minimize changes to this MIB if
>rules in [MODEL] changes."
>Grammar, confusing. How about: "By not using the TCB concept, this MIB 
>allows any grouping of elements to construct TCBs using the rules defined 
>by [MODEL]: that document should be consulted for the allowed combinations 
>of elements that make up a TCB."

OK

>5. 2.2: "thru" -> "through"

Done

>6. 2.3 "full-filled" -> "fulfilled"
>        "thru out" -> "throughout"

Done

>7. 3. "reuse" -> "reused"

Done

>8. 3. "intented" -> intended"

Done

>9. 3.1. "provide" -> "provides"

Done

>10. 3.1. "Functional Elements" -> "Functional Datapath Elements" multiple 
>times, also in 3.1.1.

OK

>11. 3.1.1. "of none existence of DiffServ Treatments" -> "of non-existence 
>of DiffServ functional datapath elements" (multiple times).

done

>12. 3.1.1. "entries can be created" -> "entries can be configured" (they 
>can be modified as well as created).

OK

>13. 3.2.1. "With each" -> "Each"

OK

>14. 3.2.1. "A data path
>may consist of more than one Classifier, the order the classification
>processes aplies to the traffic is the same as the order the classifier
>table entries are linked in the data path." change to
>"A datapath
>may contain more than one Classifier: the order in which the classification
>process applies them to the traffic is the same as the order in which the 
>classifier table entries are linked in the datapath."

I think we came up with slightly better text; this has the effect of 
specifying the implementation, and we want to specify the effect of the 
thing implemented. So we wrote

"A datapath may contain more than one classifier. The ordr in which the 
classification processes apply to the traffic is conceptually the same as 
the order in which the classifier table entries are linked in the data path.

>15. 3.2.2. "handles" -> "handle"

Done

>16. 3.5.2. "multiple drop processes ... be" -> "multiple drop processes 
>... to be"

Done

>17. 3.5.2. "parameters may include the sampling rate" -> "parameters may 
>include the sampling interval or rate"

Done

>18. 3.5.3. "parameterized" -> "parameterize"

Done

>19. 3.5.3. Suggest reword:
>"When
>new scheduling methods need to be defined, and no new scheduling
>parameters are needed, just need to add a new OBJECT-IDENTITY definition
>in some other MIB, with description of how the existing scheduling
>parameters will be used by the new scheduling method." ->
>"If an additional scheduling method needs to be defined and no new scheduling
>parameters are needed, a new OBJECT-IDENTITY definition can be made
>in some other MIB module, with a description of how the existing scheduling
>parameters will be used by the new scheduling method."

Done

>20. 4.1. Suggest delete:
>"This example has been explained in sufficient detail in [MODEL] section 8.1,
>please use that as a reference."

OK

>21. 4.2.1 "DataPathTable" -> "diffServDataPathTable"
>           "ClfrElement" -> "Classifier Element"
>           "seperations" -> "separations"
>           "Minimumly" -> "Minimally"

OK

>22. 4.2.2 "mutliple" -> "multiple"

OK

>23. 5.2 "indicate" -> "indicates that". Other grammar also - but see tech 
>comment on this paragraph.

OK


_______________________________________________
diffserv mailing list
diffserv@ietf.org
http://www1.ietf.org/mailman/listinfo/diffserv
Archive: http://www2.ietf.org/mail-archive/working-groups/diffserv/current/maillist.html



From diffserv-admin@ietf.org  Wed Dec 13 16:26: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 SMTP id QAA24435
	for ; Wed, 13 Dec 2000 16:26:39 -0500 (EST)
Received: from optimus.ietf.org (localhost [127.0.0.1])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id PAA13023;
	Wed, 13 Dec 2000 15:59:08 -0500 (EST)
Received: from ietf.org (odin [132.151.1.176])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id PAA12992
	for ; Wed, 13 Dec 2000 15:59:03 -0500 (EST)
Received: from sj-msg-core-2.cisco.com (sj-msg-core-2.cisco.com [171.69.43.88])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id PAA21095
	for ; Wed, 13 Dec 2000 15:59:01 -0500 (EST)
Received: from p7020-img-nt.cisco.com (sj-dial-3-173.cisco.com [171.68.180.174])
	by sj-msg-core-2.cisco.com (8.9.3/8.9.1) with ESMTP id MAA26570;
	Wed, 13 Dec 2000 12:58:28 -0800 (PST)
Message-Id: <5.0.2.1.2.20001213102207.03897d30@flipper.cisco.com>
X-Sender: fred@flipper.cisco.com
X-Mailer: QUALCOMM Windows Eudora Version 5.0.2
Date: Wed, 13 Dec 2000 12:58:20 -0800
To: Andrew Smith 
From: Fred Baker 
Subject: Re: [Diffserv] Token bucket suggestion in Diffserv Model draft
Cc: Brian E Carpenter ,
        "'diffserv@ietf.org'" 
In-Reply-To: <3A365FB5.9040604@allegronetworks.com>
References: <9DC5E2ABE65BD54CA9088DA3194461D6010C9AEA@BBY1EXM01>
 <3A35A2E1.7497AD08@hursley.ibm.com>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"; format=flowed
Sender: diffserv-admin@ietf.org
Errors-To: diffserv-admin@ietf.org
X-Mailman-Version: 1.0
Precedence: bulk
List-Id: Diffserv Discussion List 
X-BeenThere: diffserv@ietf.org

At 09:26 AM 12/12/00 -0800, Andrew Smith wrote:
>Can someone please summarise what the WG meeting agreed to w.r.t. this 
>document? My apologies for not having been there ...

I believe that we large passed it on. The one issue is that for all the 
edits and rewrites we have done to make Sharam happy, he remains unhappy.

Brian suggested that there is one sentence in the draft which reads 
pejoratively, and owuld do well to be replaced with a sentence that lists 
Sharam's issues with the loose model, as a balance to the succeeding 
sentence, which points out that TCP sends pairs of packets frequently and a 
model that makes believe that it is non-bursty is out of touch with 
reality. Sharam was detailed to come up with the sentence.

If you can think of workable a sentence comparable to the "issues with 
strict meters" sentence, it probably meets the need.


_______________________________________________
diffserv mailing list
diffserv@ietf.org
http://www1.ietf.org/mailman/listinfo/diffserv
Archive: http://www2.ietf.org/mail-archive/working-groups/diffserv/current/maillist.html



From diffserv-admin@ietf.org  Wed Dec 13 16:41:01 2000
Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged))
	by ietf.org (8.9.1a/8.9.1a) with SMTP id QAA26724
	for ; Wed, 13 Dec 2000 16:40:57 -0500 (EST)
Received: from optimus.ietf.org (localhost [127.0.0.1])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id QAA13547;
	Wed, 13 Dec 2000 16:19:14 -0500 (EST)
Received: from ietf.org (odin [132.151.1.176])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id QAA13519
	for ; Wed, 13 Dec 2000 16:19:10 -0500 (EST)
Received: from mailhub1.almaden.ibm.com (mailhub1.almaden.ibm.com [198.4.83.44])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id QAA23513
	for ; Wed, 13 Dec 2000 16:19:06 -0500 (EST)
Received: from maui.almaden.ibm.com (maui.almaden.ibm.com [9.1.24.92])
	by mailhub1.almaden.ibm.com (8.8.8/8.8.8) with ESMTP id NAA48998;
	Wed, 13 Dec 2000 13:15:42 -0800
Received: from hursley.ibm.com (gsine02.us.sine.ibm.com [9.14.6.42]) by maui.almaden.ibm.com (AIX4.3/8.9.3/8.7) with ESMTP id NAA27274; Wed, 13 Dec 2000 13:18:35 -0800
Message-ID: <3A37E766.D4E52A3F@hursley.ibm.com>
Date: Wed, 13 Dec 2000 15:17:26 -0600
From: Brian E Carpenter 
Organization: IBM
X-Mailer: Mozilla 4.61 [en] (Win98; I)
X-Accept-Language: en,fr
MIME-Version: 1.0
To: Juha Heinanen 
CC: "Lemaire, Tom" ,
        "'diffserv@ietf.org'" 
Subject: Re: [Diffserv] Token bucket suggestion in Diffserv Model draft
References: <49FF5C6DDBD8D311BBBD009027DE980C010C43AE@uniwest1.redstonecom.com>
		<3A37A7DB.C2C37564@hursley.ibm.com>
		<14903.46113.248346.818561@lohi.eng.telia.fi>
		<3A37BF8E.45D9F69A@hursley.ibm.com> <14903.52418.774173.805712@lohi.eng.telia.fi>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Content-Transfer-Encoding: 7bit
Sender: diffserv-admin@ietf.org
Errors-To: diffserv-admin@ietf.org
X-Mailman-Version: 1.0
Precedence: bulk
List-Id: Diffserv Discussion List 
X-BeenThere: diffserv@ietf.org
Content-Transfer-Encoding: 7bit

I'm not going to speak for any vendor. But at least one person you
know has said "we have been using the loose model for years"
in the WG.

  Brian

Juha Heinanen wrote:
> 
> Brian E Carpenter writes:
> 
>  > That's not what I said. Some claim to do it one way and
>  > some claim to do it the other way. In an informal model
>  > why can't we simply recognise this fact of life?
> 
> tell me then which vendor implement token bucket using the negative
> definition?
> 
> -- juha

_______________________________________________
diffserv mailing list
diffserv@ietf.org
http://www1.ietf.org/mailman/listinfo/diffserv
Archive: http://www2.ietf.org/mail-archive/working-groups/diffserv/current/maillist.html



From diffserv-admin@ietf.org  Wed Dec 13 16: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 SMTP id QAA28129
	for ; Wed, 13 Dec 2000 16:51:00 -0500 (EST)
Received: from optimus.ietf.org (localhost [127.0.0.1])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id QAA13738;
	Wed, 13 Dec 2000 16:27:18 -0500 (EST)
Received: from ietf.org (odin [132.151.1.176])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id QAA13704
	for ; Wed, 13 Dec 2000 16:27:14 -0500 (EST)
Received: from mailhub1.almaden.ibm.com (mailhub1.almaden.ibm.com [198.4.83.44])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id QAA24521
	for ; Wed, 13 Dec 2000 16:27:13 -0500 (EST)
Received: from maui.almaden.ibm.com (maui.almaden.ibm.com [9.1.24.92])
	by mailhub1.almaden.ibm.com (8.8.8/8.8.8) with ESMTP id NAA42602;
	Wed, 13 Dec 2000 13:23:49 -0800
Received: from hursley.ibm.com (gsine02.us.sine.ibm.com [9.14.6.42]) by maui.almaden.ibm.com (AIX4.3/8.9.3/8.7) with ESMTP id NAA20844; Wed, 13 Dec 2000 13:26:43 -0800
Message-ID: <3A37E94D.87C0C0CF@hursley.ibm.com>
Date: Wed, 13 Dec 2000 15:25:33 -0600
From: Brian E Carpenter 
Organization: IBM
X-Mailer: Mozilla 4.61 [en] (Win98; I)
X-Accept-Language: en,fr
MIME-Version: 1.0
To: demir 
CC: Juha Heinanen , Diff Serv 
Subject: Re: [Diffserv] Yesterday's EF discussion
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

Juha, Demir,

This may be what you feel, but the WG and the whole diffserv model
are based on the concept of PHB. So this discussion is really out of scope
within the WG.

As has been observed recently, the concrete realisation of a PHB may well
be a specific configuration of the lower level mechanisms that you mention.
That's not news.

  Brian

demir wrote:
> 
> Very nice points. That's how I feel, too.
> 
> Alper K. Demir
> 
> > if i implement an af class by assigning it to a wfq of a certain weight,
> > it defines a rate for that class.  does this mean that by proper
> > admission control to that class, i can in fact implement using an af
> > class a service that is equivalent to a service that would result if i
> > would be using the dr phb instead?  if so, do we really need (for other
> > than political reasons) ef or this new thing?
> 
> >
> > this brings me back to a point that i have made before, i.e., i feel
> > that the whole phb concept is not that useful.  what is useful is the
> > description of the actual (queuing, droping, policing, etc.) mechanisms
> > that the routers may implement and a way to validate them.  a well
> > documented list of such mechanisms including their parametrization would
> > be to the buyer of a router a much more useful thing than a claim that
> > the router implements a certain list of phbs.
> >
> > -- juha
> >
> > _______________________________________________
> > diffserv mailing list
> > diffserv@ietf.org
> > http://www1.ietf.org/mailman/listinfo/diffserv
> > Archive: http://www2.ietf.org/mail-archive/working-groups/diffserv/current/maillist.html
> >
> 
> _______________________________________________
> diffserv mailing list
> diffserv@ietf.org
> http://www1.ietf.org/mailman/listinfo/diffserv
> Archive: http://www2.ietf.org/mail-archive/working-groups/diffserv/current/maillist.html

_______________________________________________
diffserv mailing list
diffserv@ietf.org
http://www1.ietf.org/mailman/listinfo/diffserv
Archive: http://www2.ietf.org/mail-archive/working-groups/diffserv/current/maillist.html



From diffserv-admin@ietf.org  Wed Dec 13 17:07:16 2000
Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged))
	by ietf.org (8.9.1a/8.9.1a) with SMTP id RAA00117
	for ; Wed, 13 Dec 2000 17:07:16 -0500 (EST)
Received: from optimus.ietf.org (localhost [127.0.0.1])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id QAA14373;
	Wed, 13 Dec 2000 16:45:44 -0500 (EST)
Received: from ietf.org (odin [132.151.1.176])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id QAA14273
	for ; Wed, 13 Dec 2000 16:45:36 -0500 (EST)
Received: from mailman.packetdesign.com (dns.PACKETDESIGN.NET [216.15.46.10])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id QAA27308
	for ; Wed, 13 Dec 2000 16:45:34 -0500 (EST)
Received: from packetdesign.com (main-fw-eth1.packetdesign.com [192.168.0.254])
	by mailman.packetdesign.com (8.11.0/8.11.0) with ESMTP id eBDLj2Q69715;
	Wed, 13 Dec 2000 13:45:02 -0800 (PST)
	(envelope-from nichols@packetdesign.com)
Message-ID: <3A37EE09.6FE3AAA1@packetdesign.com>
Date: Wed, 13 Dec 2000 13:45:45 -0800
From: Kathleen Nichols 
X-Mailer: Mozilla 4.61 [en] (Win98; U)
X-Accept-Language: en
MIME-Version: 1.0
To: Yoram Bernet 
CC: diffserv@ietf.org
Subject: Re: [Diffserv] comments on the bulk handling draft
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


Mostly a recap of my replies in Monday's WG, but here for the
record, plus other stuff:

> Yoram Bernet wrote:
> 
> First of all - i'm glad to see this. I think that it is a useful and
> necessary pdb. 

It appears from the comments on this that it does meet the
requirement of being useful. Looks like there are other details
to hammer out, but your email (and your quick follow-up to
my request to spell out the application) will help with
the next rev.

> 
> One general comment I have relates to the name chosen for the pdb. I
> think that the name 'bulk handling' does a disservice to the pdb. In
> certain cases, there is an overlap between applications that 'bulk
> handle' and the service provided by the pdb. However, there are many
> bulk handling applications that cannot use the pdb and there are
> applications of the pdb that extend beyond bulk handling.

So, my simple response on name is "I'm don't care that much" though
I'm kind of leery of "less than best-effort" and of the names
being floated right now, I like Roland's "limited effort" name
he has for his PHB proposal. I think I have to convince him
that most PHB's can be categorized as "limited effort" before
we can steal that name, though... So ... whatever. I could
collect all the suggested names over the next week or two
and do an email poll. Winner gets to host the diffserv mailing
list archive. (Just kidding).

> 
> For example - 'transfer all accounting records from new york to london
> each night' can be considered a bulk handling task, yet would likely
> not be happy with what is effectively, less than best-effort (LBE)
> service. In addition, I see one of the primary applications of the bh
> pdb in the incremental deployment of aggressive multimedia
> applications (that use non-adaptive UDP). IT managers are reluctant to
> deploy (for example) streaming media over wan links because they
> cannot control the impact of these apps on the wan link resources. One
> way in which we might see these more likely to be deployed is if some
> controlled amount of the multimedia traffic could be given
> priopritized service (appropriate for the media), but any amount
> beyond this would be relegated to the bh pdb (to prevent it from
> seizing network resources required for best-effort. Based on these
> considerations - I would rather  this pdb be called the LBE (less than
> best effort pdb) rather than the bh pdb - I think is is a much more
> descriptive name.
> 

This I tried to answer in the meeting. "bulk handling" name wasn't
meant to say this is a PDB to transfer large files/records. For
one thing, I'm philosophically opposed to saying that a
certain PDB is for only one application (in the sense of layer 7,
not in the broad sense of applicability). For another, I used
the name inspired by the US Postal office's bulk mail handling.
(Yes, this is US-centric of me, but I'm from the US and I'm
happy to use another country's designation for this. Or another
name entirely.) More of the notion that you take this when there's
room on the truck. 

> Another general comment - wasn't just this type of pdb proposed
> previously? I think that it was proposed as draft-mumble-lbe-xx. I
> can't remember the authors, but - one may have been Roland Bless.
> Whoever they were, those authors deserve acknowledgement.

As stated before, yes. I think we saw this as part of a "dialog"
on this topic and had the implicit (wrong) assumption that
everybody "knew this". I think we are/were also hoping that
we might increase the author list as we work on the document
and could try to co-opt those folks to this approach. In any
case, we were remiss.

> 
> As for specific comments:
> 1. Throughout, change 'bulk handling' to 'less-than-best-effort'.
> 2. In the 'Applicability' section - describe the application to new
> applications that use non-adaptive protocols (primarily multimedia).
> From expereince with customers and IT managers - this type of service
> is essential to the deployment of those types of applications.

I plan to insert the part you added. I think there are clearly
both enterprise and ISP applications.

> 
> 3. I think the last sentence in section 2 is too strong. No operator
> intends to operate their network in a manner in which it is always
> congested. Certain applications may be deployable only if they are
> willing to take what is available. This means that on networks that
> are frequently congested, they may not get much - but then - that's
> what this pdb is all about. Basically - I think that this should be a
> warning to this effect, rather than a suggestion that the behaviour
> canot be used on congested networks.
> 

What you say, "a warning to this effect" rather than a "must not
do this" is what we intended. The original words were (typo and all):

"The BH PDB would not be usefully depolyed in a network which is
congested with non-BH traffic as this indicates no link resources
to spare."

Which we could change to:
"The [foo] PDB is not recommended for networks that are completely
congested with non-[foo] traffic as this indicates no spare
capacity for [foo]."

That, I think, represents the original intent. Does it capture
your objection?

> 4. I object to the following rules in section 3.1:
> The network edge must include
> a classifier that selects the appropriate BH target group of packets
> out of all arriving packets and steers them to a marker which sets
> the appropriate DSCP to select a PHB configured as described in
> the next section.
> Why? In many cases, the customer may chose to premark packets for this
> pdb. In that case, why would the ingress need to classify beyond
> recognizing the dscp? No MF classification is required. No marking is
> required. Rather, it is optional. In fact - I think that this rule
> should be clairified for all pdbs, probably in the pdb specification
> draft itself. There are many complexities in requiring the ingress
> node of a diffserv domain to classify or mark (consider the case of
> encrypted packets). Classification and marking (beyond the dscp)
> should be optional for all pdbs..

Yes, you are absolutely right about the "optionality" of this. We
didn't mean to rewrite 2475, I think it was just a mindset
we were in at the time. No suggested words right now, I may
go back to 2475 and steal them from there. Ditto for pdb-def.

	Kathie

_______________________________________________
diffserv mailing list
diffserv@ietf.org
http://www1.ietf.org/mailman/listinfo/diffserv
Archive: http://www2.ietf.org/mail-archive/working-groups/diffserv/current/maillist.html



From diffserv-admin@ietf.org  Wed Dec 13 17:21: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 SMTP id RAA01859
	for ; Wed, 13 Dec 2000 17:21:42 -0500 (EST)
Received: from optimus.ietf.org (localhost [127.0.0.1])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id QAA14602;
	Wed, 13 Dec 2000 16:55:04 -0500 (EST)
Received: from ietf.org (odin [132.151.1.176])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id QAA14573
	for ; Wed, 13 Dec 2000 16:55:00 -0500 (EST)
Received: from crufty.research.bell-labs.com (crufty.research.bell-labs.com [204.178.16.49])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id QAA28692
	for ; Wed, 13 Dec 2000 16:54:59 -0500 (EST)
Received: from scummy.research.bell-labs.com ([135.104.2.10]) by crufty; Wed Dec 13 16:53:40 EST 2000
Received: from mail1.pa.bell-labs.com ([135.250.8.11]) by scummy; Wed Dec 13 16:54:38 EST 2000
Received: from research.bell-labs.com (ex-vpn67.pa.bell-labs.com [135.250.1.67])
	by mail1.pa.bell-labs.com (Mirapoint)
	with ESMTP id AAW19400 (AUTH gja);
	Wed, 13 Dec 2000 13:54:36 -0800 (PST)
Message-ID: <3A37F06B.AC39B71E@research.bell-labs.com>
Date: Wed, 13 Dec 2000 13:55:55 -0800
From: Grenville Armitage 
Organization: Bell Labs Research Silicon Valley
X-Mailer: Mozilla 4.61 [en] (WinNT; U)
X-Accept-Language: en
MIME-Version: 1.0
To: Diff Serv 
Subject: Re: [Diffserv] Yesterday's EF discussion
References: <3A37BF28.219E231C@hursley.ibm.com> <14903.53889.373999.616332@lohi.eng.telia.fi>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Content-Transfer-Encoding: 7bit
Sender: diffserv-admin@ietf.org
Errors-To: diffserv-admin@ietf.org
X-Mailman-Version: 1.0
Precedence: bulk
List-Id: Diffserv Discussion List 
X-BeenThere: diffserv@ietf.org
Content-Transfer-Encoding: 7bit



Juha Heinanen wrote:
	[..]
> if i implement an af class by assigning it to a wfq of a certain weight,
> it defines a rate for that class.

you have established a wfq with certain rate, which might be *used*
to support an AF class.

>  does this mean that by proper
> admission control to that class, i can in fact implement using an af
> class

but you're not implementing it with "an af class". you're implementing
a particular "..wfq of a certain weight..." - not the same thing.

> a service that is equivalent to a service that would result if i
> would be using the dr phb instead?

quite possibly.

>  if so, do we really need (for other
> than political reasons) ef or this new thing?

EF implies requirements on how you configure your schedulers.
you could map some AF class onto a queue served by a scheduler
configure to give EF/DR-type behavior, but that hardly removes
the value of documenting what exactly *is* EF/DR behavior.

> this brings me back to a point that i have made before, i.e., i feel
> that the whole phb concept is not that useful.  what is useful is the
> description of the actual (queuing, droping, policing, etc.) mechanisms
> that the routers may implement and a way to validate them.

ultimately once you generalize the proprietary and/or
algorithm-specific terminology from such descriptions you will
end up with a PHB.

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://www2.ietf.org/mail-archive/working-groups/diffserv/current/maillist.html



From diffserv-admin@ietf.org  Wed Dec 13 17:48:52 2000
Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged))
	by ietf.org (8.9.1a/8.9.1a) with SMTP id RAA06204
	for ; Wed, 13 Dec 2000 17:48:51 -0500 (EST)
Received: from optimus.ietf.org (localhost [127.0.0.1])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id RAA15332;
	Wed, 13 Dec 2000 17:26:24 -0500 (EST)
Received: from ietf.org (odin [132.151.1.176])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id RAA15301
	for ; Wed, 13 Dec 2000 17:26:20 -0500 (EST)
Received: from mailman.packetdesign.com (dns.PACKETDESIGN.NET [216.15.46.10])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id RAA02433
	for ; Wed, 13 Dec 2000 17:26:19 -0500 (EST)
Received: from packetdesign.com (main-fw-eth1.packetdesign.com [192.168.0.254])
	by mailman.packetdesign.com (8.11.0/8.11.0) with ESMTP id eBDMPmQ70205;
	Wed, 13 Dec 2000 14:25:48 -0800 (PST)
	(envelope-from nichols@packetdesign.com)
Message-ID: <3A37F797.F49575E6@packetdesign.com>
Date: Wed, 13 Dec 2000 14:26:31 -0800
From: Kathleen Nichols 
X-Mailer: Mozilla 4.61 [en] (Win98; U)
X-Accept-Language: en
MIME-Version: 1.0
To: Fred Baker 
CC: diffserv@ietf.org
Subject: Re: [Diffserv] Counters in the classifier
References: <5.0.2.1.2.20001213100135.0308d050@flipper.cisco.com>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Content-Transfer-Encoding: 7bit
Sender: diffserv-admin@ietf.org
Errors-To: diffserv-admin@ietf.org
X-Mailman-Version: 1.0
Precedence: bulk
List-Id: Diffserv Discussion List 
X-BeenThere: diffserv@ietf.org
Content-Transfer-Encoding: 7bit



Fred Baker wrote:
...
> 
> So this is my proposal. Kwok and I are editing the MIB this morning, with a
> view to this outcome, Andrew's comments, and some comments from Bert
> relating to TCs (want to pull them together into a separate module and do
> some minor tweaks). We will put in a packet counter in the classifier, and
> the chairs can tell us we did it wrong.
> 
> Your comments, please.
> 

Fred, I think what you are saying reflects what we talked
about before Monday's meeting: you have to set up a classifier
if you want to count (a particular DSCP for example). If
this is so, I certainly support that and thought we emerged
from that meeting with out any real case made for anything
else.

	Kathie

_______________________________________________
diffserv mailing list
diffserv@ietf.org
http://www1.ietf.org/mailman/listinfo/diffserv
Archive: http://www2.ietf.org/mail-archive/working-groups/diffserv/current/maillist.html



From diffserv-admin@ietf.org  Wed Dec 13 17:59:08 2000
Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged))
	by ietf.org (8.9.1a/8.9.1a) with SMTP id RAA07737
	for ; Wed, 13 Dec 2000 17:59:08 -0500 (EST)
Received: from optimus.ietf.org (localhost [127.0.0.1])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id RAA15591;
	Wed, 13 Dec 2000 17:32:18 -0500 (EST)
Received: from ietf.org (odin [132.151.1.176])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id RAA15562
	for ; Wed, 13 Dec 2000 17:32:14 -0500 (EST)
Received: from fep03-svc.tin.it (mta03-acc.tin.it [212.216.176.34])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id RAA03260
	for ; Wed, 13 Dec 2000 17:32:12 -0500 (EST)
Received: from w2kserver ([212.171.133.53]) by fep03-svc.tin.it
          (InterMail vM.4.01.02.27 201-229-119-110) with SMTP
          id <20001213223143.PZMR6245.fep03-svc.tin.it@w2kserver>
          for ; Wed, 13 Dec 2000 23:31:43 +0100
Message-ID: <00e401c06554$df5ce800$73d8fea9@w2kserver>
From: "Matteo Pelati" 
To: 
Date: Wed, 13 Dec 2000 23:34:35 +0100
MIME-Version: 1.0
Content-Type: multipart/alternative;
	boundary="----=_NextPart_000_00E1_01C0655D.40A409B0"
X-Priority: 3
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook Express 5.50.4133.2400
X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4133.2400
Subject: [Diffserv] some info
Sender: diffserv-admin@ietf.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_00E1_01C0655D.40A409B0
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable

Hi everybody,

I'm an undergraduate student interested in QoS, recently learning about =
DiffServ and working on a university project.

I wondered if anybody knows about which support is offered by Windows =
2000 QoS components. Reading RFCs and drafts I felt a bit lost since =
everything seems to be a continuous work-in-progress, and Ms =
documentatuion says Differentiated Services are actually supported by =
W2K. So, I wondered what is exactly supported...

In DiffServ specs, a PHB is allowed to modify data (not headers) =
contained in a packet ?

Thanks

-Matteo
=20

------=_NextPart_000_00E1_01C0655D.40A409B0
Content-Type: text/html;
	charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable









Hi everybody,


 


I'm an undergraduate student interested in QoS, =
recently=20
learning about DiffServ and working on a university =
project.


 


I wondered if anybody knows about which support is =
offered by=20
Windows 2000 QoS components. Reading RFCs and drafts I felt a bit lost =
since=20
everything seems to be a continuous work-in-progress, and Ms =
documentatuion says=20
Differentiated Services are actually supported by W2K. So, I wondered =
what is=20
exactly supported...


 


In DiffServ specs, a PHB is allowed to modify data =
(not=20
headers) contained in a packet ?


 


Thanks


 


-Matteo


 


------=_NextPart_000_00E1_01C0655D.40A409B0--


_______________________________________________
diffserv mailing list
diffserv@ietf.org
http://www1.ietf.org/mailman/listinfo/diffserv
Archive: http://www2.ietf.org/mail-archive/working-groups/diffserv/current/maillist.html



From diffserv-admin@ietf.org  Wed Dec 13 18:01: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 SMTP id SAA08235
	for ; Wed, 13 Dec 2000 18:01:39 -0500 (EST)
Received: from optimus.ietf.org (localhost [127.0.0.1])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id RAA16025;
	Wed, 13 Dec 2000 17:41:52 -0500 (EST)
Received: from ietf.org (odin [132.151.1.176])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id RAA15995
	for ; Wed, 13 Dec 2000 17:41:48 -0500 (EST)
Received: from usc.edu (root@usc.edu [128.125.253.136])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id RAA04710
	for ; Wed, 13 Dec 2000 17:41:46 -0500 (EST)
Received: from koh-sun018.usc.edu (demir@koh-sun018.usc.edu [128.125.5.126])
	by usc.edu (8.9.3.1/8.9.3/usc) with ESMTP
	id OAA17344; Wed, 13 Dec 2000 14:41:47 -0800 (PST)
Received: from localhost (demir@localhost)
	by koh-sun018.usc.edu (8.9.3.1/8.9.3/usc) with ESMTP
	id OAA12106; Wed, 13 Dec 2000 14:41:47 -0800 (PST)
Date: Wed, 13 Dec 2000 14:41:47 -0800 (PST)
From: demir 
To: Grenville Armitage 
cc: Diff Serv 
Subject: Re: [Diffserv] Yesterday's EF discussion
In-Reply-To: <3A37F06B.AC39B71E@research.bell-labs.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

Grenville,

> > if i implement an af class by assigning it to a wfq of a certain weight,
> > it defines a rate for that class.
> 
> you have established a wfq with certain rate, which might be *used*
> to support an AF class.

"Admission control" might change alot more than "a wfq with certain rate".

Alper K. Demir


_______________________________________________
diffserv mailing list
diffserv@ietf.org
http://www1.ietf.org/mailman/listinfo/diffserv
Archive: http://www2.ietf.org/mail-archive/working-groups/diffserv/current/maillist.html



From diffserv-admin@ietf.org  Wed Dec 13 18:15:54 2000
Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged))
	by ietf.org (8.9.1a/8.9.1a) with SMTP id SAA11519
	for ; Wed, 13 Dec 2000 18:15:50 -0500 (EST)
Received: from optimus.ietf.org (localhost [127.0.0.1])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id RAA16372;
	Wed, 13 Dec 2000 17:52:30 -0500 (EST)
Received: from ietf.org (odin [132.151.1.176])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id RAA16339
	for ; Wed, 13 Dec 2000 17:52:25 -0500 (EST)
Received: from dgesmtp01.wcom.com ([199.249.16.16])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id RAA06937
	for ; Wed, 13 Dec 2000 17:52:24 -0500 (EST)
Received: from CONVERSION-DAEMON by firewall.mcit.com (PMDF V5.2-33 #42260)
 id <0G5J00L013IJVE@firewall.mcit.com> for diffserv@ietf.org; Wed,
 13 Dec 2000 22:51:55 +0000 (GMT)
Received: from pmismtp01.wcomnet.com ([166.38.62.36])
 by firewall.mcit.com (PMDF V5.2-33 #42260)
 with ESMTP id <0G5J00GOA3IIBJ@firewall.mcit.com>; Wed,
 13 Dec 2000 22:51:55 +0000 (GMT)
Received: from CONVERSION-DAEMON by pmismtp01.wcomnet.com (PMDF V5.2-33 #42258)
 id <0G5J009013IIRQ@pmismtp01.wcomnet.com>; Wed,
 13 Dec 2000 22:51:54 +0000 (GMT)
Received: from pmismtp01.wcomnet.com by pmismtp01.wcomnet.com
 (PMDF V5.2-33 #42258) with SMTP id <0G5J009013IBQ7@pmismtp01.wcomnet.com>;
 Wed, 13 Dec 2000 22:51:54 +0000 (GMT)
Received: from omzexch006.mcit.com ([166.37.194.37])
 by pmismtp01.wcomnet.com (PMDF V5.2-33 #42258)
 with ESMTP id <0G5J008503I8Z7@pmismtp01.wcomnet.com>; Wed,
 13 Dec 2000 22:51:44 +0000 (GMT)
Received: by omzexch006 with Internet Mail Service (5.5.2651.58)
 id ; Wed, 13 Dec 2000 22:51:44 +0000
Content-return: allowed
Date: Wed, 13 Dec 2000 22:51:43 +0000
From: "Iliff, Tina" 
Subject: RE: [Diffserv] some info
To: "'Matteo Pelati'" , diffserv@ietf.org
Message-id: <492EB4A3F68CD411ABE800508B69362E14B41B@RIPEXCH002.wcomnet.com>
MIME-version: 1.0
X-Mailer: Internet Mail Service (5.5.2651.58)
Content-type: multipart/alternative;
 boundary="Boundary_(ID_ffg3UlCRQ9yfc1qq3DjwNg)"
Sender: diffserv-admin@ietf.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.

--Boundary_(ID_ffg3UlCRQ9yfc1qq3DjwNg)
Content-type: text/plain; charset=iso-8859-1

Matteo,
 
I have attached a URL for a paper on Microsoft and QoS Support.  I hope it
helps!  Also, to try to answer your question..It is my understanding that a
PHB will not modify either data or headers.  It just defines how a router
will treat the packet w.r.t. queueing, dropping, shaping etc.  DiffServ uses
DSCP in IP headers to tell the router which PHB is appropriate for the
packet.
 
http://www.microsoft.com/hwdev/devdes/qos.htm
 
 
Tina
 

 

 

-----Original Message-----
From: Matteo Pelati [mailto:matteo@dolce.it]
Sent: Wednesday, December 13, 2000 4:35 PM
To: diffserv@ietf.org
Subject: [Diffserv] some info


Hi everybody,
 
I'm an undergraduate student interested in QoS, recently learning about
DiffServ and working on a university project.
 
I wondered if anybody knows about which support is offered by Windows 2000
QoS components. Reading RFCs and drafts I felt a bit lost since everything
seems to be a continuous work-in-progress, and Ms documentatuion says
Differentiated Services are actually supported by W2K. So, I wondered what
is exactly supported...
 
In DiffServ specs, a PHB is allowed to modify data (not headers) contained
in a packet ?
 
Thanks
 
-Matteo
 


--Boundary_(ID_ffg3UlCRQ9yfc1qq3DjwNg)
Content-type: text/html; charset=iso-8859-1











Matteo,


 


I have 
attached a URL for a paper on Microsoft and QoS Support.  I hope it 
helps!  Also, to try to answer your question..It is my understanding that a 
PHB will not modify either data or headers.  It just defines how a router 
will treat the packet w.r.t. queueing, dropping, shaping etc.  DiffServ 
uses DSCP in IP headers to tell the router which PHB is appropriate for the 
packet.


 



 


Tina


 


 


 



  
-----Original Message-----
From: Matteo Pelati 
  [mailto:matteo@dolce.it]
Sent: Wednesday, December 13, 2000 4:35 
  PM
To: diffserv@ietf.org
Subject: [Diffserv] some 
  info


  
Hi everybody,

  
 

  
I'm an undergraduate student interested in QoS, recently 
  learning about DiffServ and working on a university project.

  
 

  
I wondered if anybody knows about which support is offered 
  by Windows 2000 QoS components. Reading RFCs and drafts I felt a bit lost 
  since everything seems to be a continuous work-in-progress, and Ms 
  documentatuion says Differentiated Services are actually supported by W2K. So, 
  I wondered what is exactly supported...

  
 

  
In DiffServ specs, a PHB is allowed to modify data (not 
  headers) contained in a packet ?

  
 

  
Thanks

  
 

  
-Matteo

  
 


--Boundary_(ID_ffg3UlCRQ9yfc1qq3DjwNg)--

_______________________________________________
diffserv mailing list
diffserv@ietf.org
http://www1.ietf.org/mailman/listinfo/diffserv
Archive: http://www2.ietf.org/mail-archive/working-groups/diffserv/current/maillist.html



From diffserv-admin@ietf.org  Wed Dec 13 18:19:31 2000
Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged))
	by ietf.org (8.9.1a/8.9.1a) with SMTP id SAA12329
	for ; Wed, 13 Dec 2000 18:19:31 -0500 (EST)
Received: from optimus.ietf.org (localhost [127.0.0.1])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id RAA16467;
	Wed, 13 Dec 2000 17:54:06 -0500 (EST)
Received: from ietf.org (odin [132.151.1.176])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id RAA16438
	for ; Wed, 13 Dec 2000 17:54:01 -0500 (EST)
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 RAA07141
	for ; Wed, 13 Dec 2000 17:54:00 -0500 (EST)
Received: from grubby.research.bell-labs.com ([135.104.2.9]) by dirty; Wed Dec 13 17:52:04 EST 2000
Received: from mail1.pa.bell-labs.com ([135.250.8.11]) by grubby; Wed Dec 13 17:52:03 EST 2000
Received: from research.bell-labs.com (ex-vpn67.pa.bell-labs.com [135.250.1.67])
	by mail1.pa.bell-labs.com (Mirapoint)
	with ESMTP id AAW19501 (AUTH gja);
	Wed, 13 Dec 2000 14:52:01 -0800 (PST)
Message-ID: <3A37FDE0.2ADD7D17@research.bell-labs.com>
Date: Wed, 13 Dec 2000 14:53:20 -0800
From: Grenville Armitage 
Organization: Bell Labs Research Silicon Valley
X-Mailer: Mozilla 4.61 [en] (WinNT; U)
X-Accept-Language: en
MIME-Version: 1.0
To: demir 
CC: Diff Serv 
Subject: Re: [Diffserv] Yesterday's EF discussion
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


> "Admission control" might change alot more than "a wfq with certain rate".

Your point completely eludes me.

gja

_______________________________________________
diffserv mailing list
diffserv@ietf.org
http://www1.ietf.org/mailman/listinfo/diffserv
Archive: http://www2.ietf.org/mail-archive/working-groups/diffserv/current/maillist.html



From diffserv-admin@ietf.org  Wed Dec 13 18:19: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 SMTP id SAA12341
	for ; Wed, 13 Dec 2000 18:19:33 -0500 (EST)
Received: from optimus.ietf.org (localhost [127.0.0.1])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id RAA16401;
	Wed, 13 Dec 2000 17:52:40 -0500 (EST)
Received: from ietf.org (odin [132.151.1.176])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id RAA16371
	for ; Wed, 13 Dec 2000 17:52:30 -0500 (EST)
Received: from packetbdc.packettech.com (packetbdc.riverdelta.com [198.112.190.11])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id RAA06939
	for ; Wed, 13 Dec 2000 17:52:28 -0500 (EST)
Received: by packetbdc.riverdelta.com with Internet Mail Service (5.5.2650.21)
	id ; Wed, 13 Dec 2000 17:53:50 -0500
Message-ID: <7F4AC78738EAD2119D86009027626C6D88901E@packetbdc.riverdelta.com>
From: Jon Bennett 
To: "'Brian E Carpenter'" ,
        Diff Serv
	 
Subject: RE: [Diffserv] Yesterday's EF discussion
Date: Wed, 13 Dec 2000 17:53:48 -0500
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2650.21)
Content-Type: text/plain;
	charset="iso-8859-1"
Sender: diffserv-admin@ietf.org
Errors-To: diffserv-admin@ietf.org
X-Mailman-Version: 1.0
Precedence: bulk
List-Id: Diffserv Discussion List 
X-BeenThere: diffserv@ietf.org

Brian,
 
> Summary of conclusions from EF discussion on 12/12/2000
> -------------------------------------------------------

Much text deleted

>      Brian Carpenter
>       diffserv co-chair


As a place holder till there is time to formulate a response to your
'interesting' view of what took place yesterday..... on behalf of those of
my co-authors I have spoken with.


'We disagree'



Jon C. R. Bennett
Chief Engineer
RiverDelta Networks 
3 Highwood Drive
Tewksbury, MA  01876
978.858.2300/2361 (direct)
978.858.2399 (Fax)



   -export-a-crypto-system-sig -RSA-3-lines-PERL

#!/bin/perl -sp0777i; Wed, 13 Dec 2000 19:44:14 -0500 (EST)
Received: from optimus.ietf.org (localhost [127.0.0.1])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id TAA18200;
	Wed, 13 Dec 2000 19:20:15 -0500 (EST)
Received: from ietf.org (odin [132.151.1.176])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id TAA18169
	for ; Wed, 13 Dec 2000 19:20:10 -0500 (EST)
Received: from zcars04e.ca.nortel.com (h56s242a129n47.user.nortelnetworks.com [47.129.242.56])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id TAA25743
	for ; Wed, 13 Dec 2000 19:20:09 -0500 (EST)
Message-Id: <200012140020.TAA25743@ietf.org>
Received: from zcard00m.ca.nortel.com by zcars04e.ca.nortel.com;
          Wed, 13 Dec 2000 19:18:36 -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.2652.39) 
          id YP119PGX; Wed, 13 Dec 2000 19:18:31 -0500
Received: from zcars02x.ca.nortel.com ([47.23.81.10]) by zcard00f.ca.nortel.com 
          with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2652.39) 
          id Y6C6LXRP; Wed, 13 Dec 2000 19:18:33 -0500
Date: Wed, 13 Dec 2000 19:18:24 -0500 (EST)
X-Sybari-Space: 00000000 00000000 00000000
From: "Nabil Seddigh" 
Reply-To: "Nabil Seddigh" 
Subject: re:[Diffserv] Yesterday's EF discussion
To: Brian E Carpenter 
cc: Diff Serv 
X-Mailer: Rosa 2.1 SunOS5.6
X-Rosa-Trace: nseddigh@zcars02x <47.23.81.10>
MIME-Version: 1.0
Content-Type: text/plain; charset=iso-8859-1
Content-ID: 
X-Orig: 
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by optimus.ietf.org id TAA18170
Sender: diffserv-admin@ietf.org
Errors-To: 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] Yesterday's EF discussion", Brian E Carpenter
writes:

>
>   What should the name of the PHB be?
>     Chair's proposal: Defined Rate (DR). I believe that after this
long
>     and confusing discussion, it would be wise to retire the previous
name.
>

Somehow DR sounds like a better name for a PDB.
If it is decided that the "EF" name be retired, would suggest picking
a name that's reflective of some kind of forwarding treatment.
e.g. XF (Express Forwarding), LDJ (Low Delay Jitter Forwarding)
etc

Controversy aside, there's a lot of paper work out there with the name
EF on it. Is there any way to escape without changing the name?

Best,
Nabil Seddigh


_______________________________________________
diffserv mailing list
diffserv@ietf.org
http://www1.ietf.org/mailman/listinfo/diffserv
Archive: http://www2.ietf.org/mail-archive/working-groups/diffserv/current/maillist.html



From diffserv-admin@ietf.org  Wed Dec 13 19:44:28 2000
Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged))
	by ietf.org (8.9.1a/8.9.1a) with SMTP id TAA02452
	for ; Wed, 13 Dec 2000 19:44:28 -0500 (EST)
Received: from optimus.ietf.org (localhost [127.0.0.1])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id SAA17671;
	Wed, 13 Dec 2000 18:54:25 -0500 (EST)
Received: from ietf.org (odin [132.151.1.176])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id SAA17640
	for ; Wed, 13 Dec 2000 18:54:21 -0500 (EST)
Received: from fep03-svc.tin.it (mta03-acc.tin.it [212.216.176.34])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id SAA19837
	for ; Wed, 13 Dec 2000 18:54:21 -0500 (EST)
Received: from w2kserver ([212.171.133.53]) by fep03-svc.tin.it
          (InterMail vM.4.01.02.27 201-229-119-110) with SMTP
          id <20001213235350.QEXF6245.fep03-svc.tin.it@w2kserver>
          for ; Thu, 14 Dec 2000 00:53:50 +0100
Message-ID: <012801c06560$5809ffd0$73d8fea9@w2kserver>
From: "Matteo Pelati" 
To: 
References: <492EB4A3F68CD411ABE800508B69362E14B41B@RIPEXCH002.wcomnet.com>
Subject: Re: [Diffserv] some info
Date: Thu, 14 Dec 2000 00:56:43 +0100
MIME-Version: 1.0
Content-Type: multipart/alternative;
	boundary="----=_NextPart_000_0125_01C06568.B9944500"
X-Priority: 3
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook Express 5.50.4133.2400
X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4133.2400
Sender: diffserv-admin@ietf.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_0125_01C06568.B9944500
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable

Thanks! I was a bit unclear when asking for actions taken by PHBs. What =
I meant was if a packet (marked with a specific DSCP), can, under =
certain circumstances, be altered by an intermediate router. DSCP is the =
only data a DiffServ router is allowed to modify?

Thanks
-Matteo
  ----- Original Message -----=20
  From: Iliff, Tina=20
  To: 'Matteo Pelati' ; diffserv@ietf.org=20
  Sent: Wednesday, December 13, 2000 11:51 PM
  Subject: RE: [Diffserv] some info


  Matteo,
  =20
  I have attached a URL for a paper on Microsoft and QoS Support.  I =
hope it helps!  Also, to try to answer your question..It is my =
understanding that a PHB will not modify either data or headers.  It =
just defines how a router will treat the packet w.r.t. queueing, =
dropping, shaping etc.  DiffServ uses DSCP in IP headers to tell the =
router which PHB is appropriate for the packet.
  =20
  http://www.microsoft.com/hwdev/devdes/qos.htm
  =20
  Tina

  =20



    -----Original Message-----
    From: Matteo Pelati [mailto:matteo@dolce.it]
    Sent: Wednesday, December 13, 2000 4:35 PM
    To: diffserv@ietf.org
    Subject: [Diffserv] some info


    Hi everybody,

    I'm an undergraduate student interested in QoS, recently learning =
about DiffServ and working on a university project.
    =20
    I wondered if anybody knows about which support is offered by =
Windows 2000 QoS components. Reading RFCs and drafts I felt a bit lost =
since everything seems to be a continuous work-in-progress, and Ms =
documentatuion says Differentiated Services are actually supported by =
W2K. So, I wondered what is exactly supported...

    In DiffServ specs, a PHB is allowed to modify data (not headers) =
contained in a packet ?

    Thanks

    -Matteo


------=_NextPart_000_0125_01C06568.B9944500
Content-Type: text/html;
	charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable











Thanks! I was a bit unclear when asking for actions =
taken by=20
PHBs. What I meant was if a packet (marked with a specific DSCP),=20
can, under certain circumstances, be altered by an =
intermediate=20
router. DSCP is the only data a DiffServ router is allowed to=20
modify?


 


Thanks


-Matteo


  
----- Original Message ----- 

  From:=20
  Iliff, Tina=20
  
  
  
Sent: Wednesday, December 13, =
2000 11:51=20
  PM

  
Subject: RE: [Diffserv] some =
info

  


  
Matteo,

  
 

  
I=20
  have attached a URL for a paper on Microsoft and QoS Support.  I =
hope it=20
  helps!  Also, to try to answer your question..It is my =
understanding that=20
  a PHB will not modify either data or headers.  It just defines =
how a=20
  router will treat the packet w.r.t. queueing, dropping, shaping =
etc. =20
  DiffServ uses DSCP in IP headers to tell the router which PHB is =
appropriate=20
  for the packet.

  
 

  
http://www.microso=
ft.com/hwdev/devdes/qos.htm

  
 

  
Tina

  
 

  
 

  
 

  

    
-----Original Message-----
From: Matteo Pelati=20
    [mailto:matteo@dolce.it]
Sent: Wednesday, December 13, =
2000 4:35=20
    PM
To: diffserv@ietf.org
Subject: [Diffserv] =
some=20
    info


    
Hi everybody,

    
 

    
I'm an undergraduate student interested in QoS, =
recently=20
    learning about DiffServ and working on a university =
project.

    
 

    
I wondered if anybody knows about which support =
is offered=20
    by Windows 2000 QoS components. Reading RFCs and drafts I felt a bit =
lost=20
    since everything seems to be a continuous work-in-progress, and Ms=20
    documentatuion says Differentiated Services are actually supported =
by W2K.=20
    So, I wondered what is exactly supported...

    
 

    
In DiffServ specs, a PHB is allowed to modify =
data (not=20
    headers) contained in a packet ?

    
 

    
Thanks

    
 

    
-Matteo

    
 
------=_NextPart_000_0125_01C06568.B9944500-- _______________________________________________ diffserv mailing list diffserv@ietf.org http://www1.ietf.org/mailman/listinfo/diffserv Archive: http://www2.ietf.org/mail-archive/working-groups/diffserv/current/maillist.html From diffserv-admin@ietf.org Wed Dec 13 19:44: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 SMTP id TAA02466 for ; Wed, 13 Dec 2000 19:44:31 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id SAA17732; Wed, 13 Dec 2000 18:57:22 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id SAA17699 for ; Wed, 13 Dec 2000 18:57:17 -0500 (EST) Received: from mailhub1.almaden.ibm.com (mailhub1.almaden.ibm.com [198.4.83.44]) by ietf.org (8.9.1a/8.9.1a) with SMTP id SAA20450 for ; Wed, 13 Dec 2000 18:57:17 -0500 (EST) Received: from maui.almaden.ibm.com (maui.almaden.ibm.com [9.1.24.92]) by mailhub1.almaden.ibm.com (8.8.8/8.8.8) with ESMTP id PAA52638; Wed, 13 Dec 2000 15:53:46 -0800 Received: from hursley.ibm.com (gsine03.us.sine.ibm.com [9.14.6.43]) by maui.almaden.ibm.com (AIX4.3/8.9.3/8.7) with ESMTP id PAA09632; Wed, 13 Dec 2000 15:56:41 -0800 Message-ID: <3A380C71.237A36B1@hursley.ibm.com> Date: Wed, 13 Dec 2000 17:55:29 -0600 From: Brian E Carpenter Organization: IBM X-Mailer: Mozilla 4.61 [en] (Win98; I) X-Accept-Language: en,fr MIME-Version: 1.0 To: Matteo Pelati CC: diffserv@ietf.org Subject: Re: [Diffserv] some info References: <00e401c06554$df5ce800$73d8fea9@w2kserver> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: diffserv-admin@ietf.org Errors-To: diffserv-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Diffserv Discussion List X-BeenThere: diffserv@ietf.org Content-Transfer-Encoding: 7bit This sort of question belongs elsewhere, for example see http://www.tip.csiro.au/dsimplementation for that list Brian Carpenter diffserv co-chair > Matteo Pelati wrote: > > Hi everybody, > > I'm an undergraduate student interested in QoS, recently learning about DiffServ and working on a university project. > > I wondered if anybody knows about which support is offered by Windows 2000 QoS components. Reading RFCs and drafts I felt a > bit lost since everything seems to be a continuous work-in-progress, and Ms documentatuion says Differentiated Services are > actually supported by W2K. So, I wondered what is exactly supported... > > In DiffServ specs, a PHB is allowed to modify data (not headers) contained in a packet ? > > Thanks > > -Matteo > _______________________________________________ diffserv mailing list diffserv@ietf.org http://www1.ietf.org/mailman/listinfo/diffserv Archive: http://www2.ietf.org/mail-archive/working-groups/diffserv/current/maillist.html From diffserv-admin@ietf.org Wed Dec 13 19:44: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 SMTP id TAA02506 for ; Wed, 13 Dec 2000 19:44:35 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id TAA18161; Wed, 13 Dec 2000 19:19:43 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id TAA18129 for ; Wed, 13 Dec 2000 19:19:38 -0500 (EST) Received: from mta5.snfc21.pbi.net (mta5.snfc21.pbi.net [206.13.28.241]) by ietf.org (8.9.1a/8.9.1a) with SMTP id TAA25633 for ; Wed, 13 Dec 2000 19:19:38 -0500 (EST) Received: from allegronetworks.com ([206.170.1.77]) by mta5.snfc21.pbi.net (Sun Internet Mail Server sims.3.5.2000.01.05.12.18.p9) with ESMTP id <0G5J00KR261WI3@mta5.snfc21.pbi.net> for diffserv@ietf.org; Wed, 13 Dec 2000 15:46:46 -0800 (PST) Date: Wed, 13 Dec 2000 15:54:45 -0800 From: Andrew Smith Subject: Re: [Diffserv] Counters in the classifier To: Fred Baker Cc: Kathleen Nichols , diffserv@ietf.org Message-id: <3A380C45.90105@allegronetworks.com> Organization: Allegro Networks MIME-version: 1.0 Content-type: text/plain; charset=us-ascii; format=flowed Content-transfer-encoding: 7bit User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; m18) Gecko/20001108 Netscape6/6.0 X-Accept-Language: en References: <5.0.2.1.2.20001213100135.0308d050@flipper.cisco.com> <3A37F797.F49575E6@packetdesign.com> Content-Transfer-Encoding: 7bit Sender: diffserv-admin@ietf.org Errors-To: diffserv-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Diffserv Discussion List X-BeenThere: diffserv@ietf.org Content-Transfer-Encoding: 7bit This does, again, beg the question of having even more overlap with what the DSMON MIB (in the RMON WG) does. I'm also a bit confused as to whether Fred's proposal *replaces* the existing "counter action" material in the MIB or is in addition to it. And is this addition/change expected to be rolled back into the Model draft also? Andrew Kathleen Nichols wrote: > > Fred Baker wrote: > .... > >> So this is my proposal. Kwok and I are editing the MIB this morning, with a >> view to this outcome, Andrew's comments, and some comments from Bert >> relating to TCs (want to pull them together into a separate module and do >> some minor tweaks). We will put in a packet counter in the classifier, and >> the chairs can tell us we did it wrong. >> >> Your comments, please. >> > > > Fred, I think what you are saying reflects what we talked > about before Monday's meeting: you have to set up a classifier > if you want to count (a particular DSCP for example). If > this is so, I certainly support that and thought we emerged > from that meeting with out any real case made for anything > else. > > Kathie > > _______________________________________________ > diffserv mailing list > diffserv@ietf.org > http://www1.ietf.org/mailman/listinfo/diffserv > Archive: http://www2.ietf.org/mail-archive/working-groups/diffserv/current/maillist.html _______________________________________________ diffserv mailing list diffserv@ietf.org http://www1.ietf.org/mailman/listinfo/diffserv Archive: http://www2.ietf.org/mail-archive/working-groups/diffserv/current/maillist.html From diffserv-admin@ietf.org Wed Dec 13 19:44: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 SMTP id TAA02563 for ; Wed, 13 Dec 2000 19:44:49 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id TAA17949; Wed, 13 Dec 2000 19:02:00 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id TAA17921 for ; Wed, 13 Dec 2000 19:01:56 -0500 (EST) Received: from mailhub1.almaden.ibm.com (mailhub1.almaden.ibm.com [198.4.83.44]) by ietf.org (8.9.1a/8.9.1a) with SMTP id TAA21642 for ; Wed, 13 Dec 2000 19:01:54 -0500 (EST) Received: from maui.almaden.ibm.com (maui.almaden.ibm.com [9.1.24.92]) by mailhub1.almaden.ibm.com (8.8.8/8.8.8) with ESMTP id PAA54564; Wed, 13 Dec 2000 15:58:27 -0800 Received: from hursley.ibm.com (gsine03.us.sine.ibm.com [9.14.6.43]) by maui.almaden.ibm.com (AIX4.3/8.9.3/8.7) with ESMTP id QAA20518; Wed, 13 Dec 2000 16:01:23 -0800 Message-ID: <3A380D8B.79F4D8B1@hursley.ibm.com> Date: Wed, 13 Dec 2000 18:00:11 -0600 From: Brian E Carpenter Organization: IBM X-Mailer: Mozilla 4.61 [en] (Win98; I) X-Accept-Language: en,fr MIME-Version: 1.0 To: Jon Bennett CC: Diff Serv Subject: Re: [Diffserv] Yesterday's EF discussion References: <7F4AC78738EAD2119D86009027626C6D88901E@packetbdc.riverdelta.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: diffserv-admin@ietf.org Errors-To: diffserv-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Diffserv Discussion List X-BeenThere: diffserv@ietf.org Content-Transfer-Encoding: 7bit Jon, When judging WG consensus, the only responses of interest are individual responses. Please speak for yourself. Brian Jon Bennett wrote: > > Brian, > > > Summary of conclusions from EF discussion on 12/12/2000 > > ------------------------------------------------------- > > Much text deleted > > > Brian Carpenter > > diffserv co-chair > > As a place holder till there is time to formulate a response to your > 'interesting' view of what took place yesterday..... on behalf of those of > my co-authors I have spoken with. > > 'We disagree' > > 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://www2.ietf.org/mail-archive/working-groups/diffserv/current/maillist.html _______________________________________________ diffserv mailing list diffserv@ietf.org http://www1.ietf.org/mailman/listinfo/diffserv Archive: http://www2.ietf.org/mail-archive/working-groups/diffserv/current/maillist.html From diffserv-admin@ietf.org Wed Dec 13 19:48: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 SMTP id TAA03301 for ; Wed, 13 Dec 2000 19:48:24 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id TAA18351; Wed, 13 Dec 2000 19:26:56 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id TAA18320 for ; Wed, 13 Dec 2000 19:26:52 -0500 (EST) Received: from mailhub1.almaden.ibm.com (mailhub1.almaden.ibm.com [198.4.83.44]) by ietf.org (8.9.1a/8.9.1a) with SMTP id TAA28061 for ; Wed, 13 Dec 2000 19:26:51 -0500 (EST) Received: from maui.almaden.ibm.com (maui.almaden.ibm.com [9.1.24.92]) by mailhub1.almaden.ibm.com (8.8.8/8.8.8) with ESMTP id QAA10120; Wed, 13 Dec 2000 16:23:24 -0800 Received: from hursley.ibm.com (gsine03.us.sine.ibm.com [9.14.6.43]) by maui.almaden.ibm.com (AIX4.3/8.9.3/8.7) with ESMTP id QAA20890; Wed, 13 Dec 2000 16:26:19 -0800 Message-ID: <3A38135E.1AD72AFF@hursley.ibm.com> Date: Wed, 13 Dec 2000 18:25:02 -0600 From: Brian E Carpenter Organization: IBM X-Mailer: Mozilla 4.61 [en] (Win98; I) X-Accept-Language: en,fr MIME-Version: 1.0 To: Nabil Seddigh CC: Diff Serv Subject: Re: [Diffserv] Yesterday's EF discussion References: <200012140019.AAA08792@mail-gw1.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 Nabil, The issue is what is least confusing to the user community - a new definition with the old name, or a new name? I'm interested in opinions. Brian Nabil Seddigh wrote: > > In message "[Diffserv] Yesterday's EF discussion", Brian E Carpenter > writes: > > > > > What should the name of the PHB be? > > Chair's proposal: Defined Rate (DR). I believe that after this > long > > and confusing discussion, it would be wise to retire the previous > name. > > > > Somehow DR sounds like a better name for a PDB. > If it is decided that the "EF" name be retired, would suggest picking > a name that's reflective of some kind of forwarding treatment. > e.g. XF (Express Forwarding), LDJ (Low Delay Jitter Forwarding) > etc > > Controversy aside, there's a lot of paper work out there with the name > EF on it. Is there any way to escape without changing the name? > > Best, > Nabil Seddigh _______________________________________________ diffserv mailing list diffserv@ietf.org http://www1.ietf.org/mailman/listinfo/diffserv Archive: http://www2.ietf.org/mail-archive/working-groups/diffserv/current/maillist.html From diffserv-admin@ietf.org Wed Dec 13 20:06: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 SMTP id UAA07492 for ; Wed, 13 Dec 2000 20:06:43 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id TAA18862; Wed, 13 Dec 2000 19:45:00 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id TAA18836 for ; Wed, 13 Dec 2000 19:44:56 -0500 (EST) Received: from mailhub1.almaden.ibm.com (mailhub1.almaden.ibm.com [198.4.83.44]) by ietf.org (8.9.1a/8.9.1a) with SMTP id TAA02591 for ; Wed, 13 Dec 2000 19:44:55 -0500 (EST) Received: from maui.almaden.ibm.com (maui.almaden.ibm.com [9.1.24.92]) by mailhub1.almaden.ibm.com (8.8.8/8.8.8) with ESMTP id QAA42410; Wed, 13 Dec 2000 16:41:27 -0800 Received: from hursley.ibm.com (gsine03.us.sine.ibm.com [9.14.6.43]) by maui.almaden.ibm.com (AIX4.3/8.9.3/8.7) with ESMTP id QAA09640; Wed, 13 Dec 2000 16:44:23 -0800 Message-ID: <3A38179E.74BA7E1@hursley.ibm.com> Date: Wed, 13 Dec 2000 18:43:10 -0600 From: Brian E Carpenter Organization: IBM X-Mailer: Mozilla 4.61 [en] (Win98; I) X-Accept-Language: en,fr MIME-Version: 1.0 To: Matteo Pelati CC: diffserv@ietf.org Subject: Re: [Diffserv] some info References: <492EB4A3F68CD411ABE800508B69362E14B41B@RIPEXCH002.wcomnet.com> <012801c06560$5809ffd0$73d8fea9@w2kserver> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: diffserv-admin@ietf.org Errors-To: diffserv-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Diffserv Discussion List X-BeenThere: diffserv@ietf.org Content-Transfer-Encoding: 7bit The only field that diffserv "owns" is the DSCP, so clearly that is the only field that diffserv can modify. Brian _______________________________________________ diffserv mailing list diffserv@ietf.org http://www1.ietf.org/mailman/listinfo/diffserv Archive: http://www2.ietf.org/mail-archive/working-groups/diffserv/current/maillist.html From diffserv-admin@ietf.org Wed Dec 13 20:12: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 SMTP id UAA08892 for ; Wed, 13 Dec 2000 20:12:08 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id TAA18939; Wed, 13 Dec 2000 19:48:09 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id TAA18907 for ; Wed, 13 Dec 2000 19:48:05 -0500 (EST) Received: from mailhub1.almaden.ibm.com (mailhub1.almaden.ibm.com [198.4.83.44]) by ietf.org (8.9.1a/8.9.1a) with SMTP id TAA03241 for ; Wed, 13 Dec 2000 19:48:04 -0500 (EST) Received: from maui.almaden.ibm.com (maui.almaden.ibm.com [9.1.24.92]) by mailhub1.almaden.ibm.com (8.8.8/8.8.8) with ESMTP id QAA09248; Wed, 13 Dec 2000 16:44:36 -0800 Received: from hursley.ibm.com (gsine03.us.sine.ibm.com [9.14.6.43]) by maui.almaden.ibm.com (AIX4.3/8.9.3/8.7) with ESMTP id QAA20536; Wed, 13 Dec 2000 16:47:32 -0800 Message-ID: <3A38185B.F216350C@hursley.ibm.com> Date: Wed, 13 Dec 2000 18:46:19 -0600 From: Brian E Carpenter Organization: IBM X-Mailer: Mozilla 4.61 [en] (Win98; I) X-Accept-Language: en,fr MIME-Version: 1.0 To: Andrew Smith CC: Fred Baker , Kathleen Nichols , diffserv@ietf.org Subject: Re: [Diffserv] Counters in the classifier References: <5.0.2.1.2.20001213100135.0308d050@flipper.cisco.com> <3A37F797.F49575E6@packetdesign.com> <3A380C45.90105@allegronetworks.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: diffserv-admin@ietf.org Errors-To: diffserv-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Diffserv Discussion List X-BeenThere: diffserv@ietf.org Content-Transfer-Encoding: 7bit I would prefer that the model is not that specific about how counters are implemented, but if it is, then it needs to be consistent. Brian Andrew Smith wrote: > > This does, again, beg the question of having even more overlap with what the > DSMON MIB (in the RMON WG) does. > > I'm also a bit confused as to whether Fred's proposal *replaces* the existing > "counter action" material in the MIB or is in addition to it. And is this > addition/change expected to be rolled back into the Model draft also? > > Andrew > > Kathleen Nichols wrote: > > > > > Fred Baker wrote: > > .... > > > >> So this is my proposal. Kwok and I are editing the MIB this morning, with a > >> view to this outcome, Andrew's comments, and some comments from Bert > >> relating to TCs (want to pull them together into a separate module and do > >> some minor tweaks). We will put in a packet counter in the classifier, and > >> the chairs can tell us we did it wrong. > >> > >> Your comments, please. > >> > > > > > > Fred, I think what you are saying reflects what we talked > > about before Monday's meeting: you have to set up a classifier > > if you want to count (a particular DSCP for example). If > > this is so, I certainly support that and thought we emerged > > from that meeting with out any real case made for anything > > else. > > > > Kathie > > > > _______________________________________________ > > diffserv mailing list > > diffserv@ietf.org > > http://www1.ietf.org/mailman/listinfo/diffserv > > Archive: http://www2.ietf.org/mail-archive/working-groups/diffserv/current/maillist.html > > _______________________________________________ > diffserv mailing list > diffserv@ietf.org > http://www1.ietf.org/mailman/listinfo/diffserv > Archive: http://www2.ietf.org/mail-archive/working-groups/diffserv/current/maillist.html _______________________________________________ diffserv mailing list diffserv@ietf.org http://www1.ietf.org/mailman/listinfo/diffserv Archive: http://www2.ietf.org/mail-archive/working-groups/diffserv/current/maillist.html From diffserv-admin@ietf.org Wed Dec 13 22:24: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 SMTP id WAA03492 for ; Wed, 13 Dec 2000 22:24:47 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id VAA20907; Wed, 13 Dec 2000 21:59:32 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id VAA20803 for ; Wed, 13 Dec 2000 21:59:24 -0500 (EST) Received: from smtppop3pub.verizon.net (smtppop3pub.gte.net [206.46.170.22]) by ietf.org (8.9.1a/8.9.1a) with SMTP id VAA29909 for ; Wed, 13 Dec 2000 21:59:22 -0500 (EST) Received: from PROXIM (lsanca1-ar5-217-030.dsl.gtei.net [4.33.217.30]) by smtppop3pub.verizon.net with SMTP for ; id UAA75657392 Wed, 13 Dec 2000 20:54:31 -0600 (CST) Message-ID: <003601c06579$dc7865e0$2ed4e00a@vz.dsl.genuity.net> From: "Bill Courtney" To: "Diff Serv" References: <3A37BF28.219E231C@hursley.ibm.com> Subject: Re: [Diffserv] Yesterday's EF discussion Date: Wed, 13 Dec 2000 18:59:22 -0800 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.50.4133.2400 X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4133.2400 Content-Transfer-Encoding: 7bit Sender: diffserv-admin@ietf.org Errors-To: diffserv-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Diffserv Discussion List X-BeenThere: diffserv@ietf.org Content-Transfer-Encoding: 7bit Hi Brian, Among other things, you solicited opinion on the following > What should the name of the PHB be? > Chair's proposal: Defined Rate (DR). I believe that after this long > and confusing discussion, it would be wise to retire the previous name. I disagree with your proposal and believe that the EF name should be retained. My reasons are that 1) As I read the options and the WG consensus, the WG wanted to *fix EF*, not to provide a new PHB that has no relationship to EF. (I apologize to the WG if I have misread its intention.) I think that the consensus should be respected. 2) There is a great deal of interest in the industry (vendors and service providers) and in the academic and user community for having a final version of EF. We in the WG have continued to whet this interest by a) arriving at a consensus in Pittsburgh that *EF* should be made implementable and b)arriving at a consensus in San Diego that the preferred *EF fix* would take the approach laid out in the draft-charny compromise. There seems to be no reason for a sudden change in the name of the PHB. If a change were warranted, the time to have made it would have been the instant that the WG agreed that EF needed fixing. Yet, no one spoke out that such a change should be made. (Although it was the case that some felt that no fix was necessary, and that any so-called "fix" should instead be captured in some new PHB. As we know, this feeling was not embraced by the WG consensus.) A change seems unnecessary, and would, I believe create at least as much confusion in the community as it would alleviate. 3) As I have expressed in mailings back around the time just before the Pittsburgh meeting, the behavior defined in draft-charny-00 (and, as Bruce expressed at the meeting in San Diego, the behavior defined in the draft-charny compromise) is a minimal departure from the *words* written in RFC 2598. Since the WG agreed to fix EF via the compromise, it is not too much of a stretch, to conclude that the WG felt that the draft-charny-compromise behavior is close to the behavior that RFC 2598 sought to define. (Again, I apologise if I am reading the consensus incorrectly. If I am, other responses to your suggestion will certainly make that clear to me.) Since the behaviors are close, no change to the name is required, so none should be made. Bill _______________________________________________ diffserv mailing list diffserv@ietf.org http://www1.ietf.org/mailman/listinfo/diffserv Archive: http://www2.ietf.org/mail-archive/working-groups/diffserv/current/maillist.html From diffserv-admin@ietf.org Thu Dec 14 02:41: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 SMTP id CAA15876 for ; Thu, 14 Dec 2000 02:41:21 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id BAA29602; Thu, 14 Dec 2000 01:51:03 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id BAA29573 for ; Thu, 14 Dec 2000 01:50:59 -0500 (EST) Received: from crufty.research.bell-labs.com (crufty.research.bell-labs.com [204.178.16.49]) by ietf.org (8.9.1a/8.9.1a) with SMTP id BAA23276 for ; Thu, 14 Dec 2000 01:50:59 -0500 (EST) Received: from scummy.research.bell-labs.com ([135.104.2.10]) by crufty; Thu Dec 14 01:48:22 EST 2000 Received: from mail1.pa.bell-labs.com ([135.250.8.11]) by scummy; Thu Dec 14 01:49:20 EST 2000 Received: from research.bell-labs.com (ex-vpn68.pa.bell-labs.com [135.250.1.68]) by mail1.pa.bell-labs.com (Mirapoint) with ESMTP id AAW20125 (AUTH gja); Wed, 13 Dec 2000 22:49:16 -0800 (PST) Message-ID: <3A386DBA.42F44DAA@research.bell-labs.com> Date: Wed, 13 Dec 2000 22:50:34 -0800 From: Grenville Armitage Organization: Bell Labs Research Silicon Valley X-Mailer: Mozilla 4.61 [en] (WinNT; U) X-Accept-Language: en MIME-Version: 1.0 To: Brian E Carpenter CC: Diff Serv Subject: What's in a name? Re: [Diffserv] Yesterday's EF discussion References: <3A37BF28.219E231C@hursley.ibm.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: diffserv-admin@ietf.org Errors-To: diffserv-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Diffserv Discussion List X-BeenThere: diffserv@ietf.org Content-Transfer-Encoding: 7bit Brian E Carpenter wrote: [..] > What should the name of the PHB be? > Chair's proposal: Defined Rate (DR). I believe that after this long > and confusing discussion, it would be wise to retire the previous name. Brian, I think this suggestion is a good one. Clearly there are differing opinions over what RFC2598 intended. I watched from the rear of the room yesterday. I too saw a crowd sentiment broadly in favor of draft-charny(modified) as the WG PHB to support VW and similar services. But given the fact that "EF" has been differently interpreted by a number of relatively intelligent people, I cannot see the value in anyone being 'damn right' about owning the EF name from this point onwards. The WG needs a standards track PHB believed to support VW, etc, services....the name "Defined Rate" captures the rough consensus towards the rate-based interpretation of RFC2598. cheers, gja (not, it must be noted, speaking of behalf of EFRESOLVE) _______________________________________________ diffserv mailing list diffserv@ietf.org http://www1.ietf.org/mailman/listinfo/diffserv Archive: http://www2.ietf.org/mail-archive/working-groups/diffserv/current/maillist.html From diffserv-admin@ietf.org Thu Dec 14 05:56: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 SMTP id FAA27397 for ; Thu, 14 Dec 2000 05:56:55 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id FAA02132; Thu, 14 Dec 2000 05:33:17 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id FAA02101 for ; Thu, 14 Dec 2000 05:33:12 -0500 (EST) Received: from p-mail1.cnet.fr (p-mail1.rd.francetelecom.fr [193.49.124.31]) by ietf.org (8.9.1a/8.9.1a) with SMTP id FAA22561 for ; Thu, 14 Dec 2000 05:33:10 -0500 (EST) Received: by p-biset.issy.cnet.fr with Internet Mail Service (5.5.2650.21) id ; Thu, 14 Dec 2000 11:30:54 +0100 Message-ID: <91A311FF6A85D3118DDF0060080C3D82B7DAB3@lat3721.lannion.cnet.fr> From: GARBISU Jean-Pierre FTRD/DMI/CAE To: "'Brian E Carpenter'" , GARBISU Jean-Pierre FTRD/DMI/CAE Cc: Simon Leinen , Yoram Bernet , diffserv@ietf.org Subject: RE: LBE PHB [was: [Diffserv] comments on the bulk handling draft] Date: Thu, 14 Dec 2000 11:29:07 +0100 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: text/plain; charset="ISO-8859-1" X-MIME-Autoconverted: from quoted-printable to 8bit by optimus.ietf.org id FAA02102 Sender: diffserv-admin@ietf.org Errors-To: diffserv-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Diffserv Discussion List X-BeenThere: diffserv@ietf.org X-MIME-Autoconverted: from 8bit to quoted-printable by optimus.ietf.org id FAA02132 Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by ietf.org id FAA27397 So we should consider a future minor (?) modification of RFC 2474 which is stating in § 4.2.2.2 : PHBs selected by a Class Selector Codepoint SHOULD give packets a probability of timely forwarding that is not lower than that given to packets marked with a Class Selector codepoint of lower relative order, under reasonable operating conditions and traffic loads. Best regards jeanpierre.garbisu@francetelecom.fr -----Message d'origine----- De : Brian E Carpenter [mailto:brian@hursley.ibm.com] Envoyé : mardi 12 décembre 2000 17:04 À : GARBISU Jean-Pierre FTRD/DMI/CAE Cc : Simon Leinen; Yoram Bernet; diffserv@ietf.org Objet : Re: LBE PHB [was: [Diffserv] comments on the bulk handling draft] GARBISU Jean-Pierre FTRD/DMI/CAE wrote: ... > what will be the recommended precedence : 1 ? The suggested PHB was Class Selector 1, which can be viewed as backwards-compatible with TOS Precedence 1. Brian _______________________________________________ diffserv mailing list diffserv@ietf.org http://www1.ietf.org/mailman/listinfo/diffserv Archive: http://www2.ietf.org/mail-archive/working-groups/diffserv/current/maillist.h tml _______________________________________________ diffserv mailing list diffserv@ietf.org http://www1.ietf.org/mailman/listinfo/diffserv Archive: http://www2.ietf.org/mail-archive/working-groups/diffserv/current/maillist.html From diffserv-admin@ietf.org Thu Dec 14 06:28: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 SMTP id GAA03969 for ; Thu, 14 Dec 2000 06:28:21 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id GAA02517; Thu, 14 Dec 2000 06:09:21 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id GAA02494 for ; Thu, 14 Dec 2000 06:09:17 -0500 (EST) Received: from iraun1.ira.uka.de (iraun1.ira.uka.de [129.13.10.90]) by ietf.org (8.9.1a/8.9.1a) with SMTP id GAA29969 for ; Thu, 14 Dec 2000 06:09:14 -0500 (EST) Received: from blackfoot.telematik.informatik.uni-karlsruhe.de by iraun1 (PP) with ESMTP; Thu, 14 Dec 2000 12:09:02 +0100 Received: from tpce10.telematik.informatik.uni-karlsruhe.de (root@tpce10.telematik.informatik.uni-karlsruhe.de [129.13.41.110]) by blackfoot.telematik.informatik.uni-karlsruhe.de (8.9.3/8.9.3) with ESMTP id MAA24291; Thu, 14 Dec 2000 12:09:01 +0100 (MET) Received: from mailhost (bless@tpce10.telematik.informatik.uni-karlsruhe.de [129.13.41.110]) by tpce10.telematik.informatik.uni-karlsruhe.de (8.9.3/8.9.3) with ESMTP id MAA03984; Thu, 14 Dec 2000 12:09:00 +0100 Message-Id: <200012141109.MAA03984@tpce10.telematik.informatik.uni-karlsruhe.de> X-Mailer: exmh version 2.1.1 10/15/1999 To: Kathleen Nichols Cc: diffserv@ietf.org Subject: Re: [Diffserv] comments on the bulk handling draft In-Reply-To: Your message of "Tue, 12 Dec 2000 11:23:22 PST." <3A367B2A.8AF9847@packetdesign.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Thu, 14 Dec 2000 12:09:00 +0100 From: Roland Bless Sender: diffserv-admin@ietf.org Errors-To: diffserv-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Diffserv Discussion List X-BeenThere: diffserv@ietf.org Kathleen Nichcols wrote: > It's a shame you see it as a PHB...I really like that name, > "limited effort", it would be nice for a PDB. In fact, I > think we should have more "mechanistic" or "behavioral" names > for PHBs, but that's my opinion. Why is it a shame? Do you have technical reasons why it should not be a PHB? > Now I'm really confused. This is kind of at the core of diffserv. > The CS PHB group is derived from the old used of IP precedence > and CBQ schedulers. It's been meant from the start that one > could configure PHBs to have "resources only up to a defined > limit in case of congestion". This can even be said of EF. The Sure, that is clear. Sorry, my expression was not precise enough and easily led to misinterpretation. > notion we heard was for something that uses ONLY the excess > capacity. (Maybe there's a PDB name in there somewhere.) If we assume that the default PHB is able to use up all residual resources which are currently not needed by other PHBs, then the intended behavior is the following (examples were mentioned in the draft): 1. If best-effort traffic load is less than "residual bandwidth" (unused bandwidth from other PHBs excluding BE and LE), there is excess capacity which can be used by the LE PHB. 2. As best-effort traffic load increases, so that there is no residual bandwidth left (link is fully/over loaded), it preempts LE traffic, but only up to a defined limit. Particularly, permitted LE traffic will not exceed this limit in this case, independent of what the current LE load is. The results should be: A) If resources are fully used, BE traffic is protected from LE traffic, because the LE PHB cannot use more resources than defined by the limit. B) LE PHB can use excess capacity which is not used by the default PHB (without LE traffic link is not fully loaded). IMHO even in congestion situations, one should be able to get some LE packets through. Therefore, we think that starvation is even not good for this low priority class. But if an administrator decides to set the configurable limit to 0, then starvation is also permitted. > So we were looking for something that PERMITS starvation, but > doesn't require it. As I said above, I think that non-starvation, > but a possible limit is easily covered by a CS. The earlier > problem with using a CS had been concerns over breaking the > SHOULD to do starvation. I spoke about this yesterday and > Brian posted on this after you proposed your initial draft > some months ago. Naturally, you can use a (lower priority than CS0) CS or two AF PHBs (one for LE, one for default PHB) for _implementation_. The fact that you can also use a CS7 for EF PHB implementation does IMHO not make the EF PHB definition unnecessary and the same argument applies to the LE PHB definition. It's simply a more specific PHB than the more generic CS or AF PHBs. > But we want to describe a behavior across a domain. Both BE and > BH have null traffic conditioning, though there may be classification > required, may be marking, and may even be policing. Yes, but we want to describe a forwarding behavior. The origin of the LE PHB was in the context of our proposed multicast solution: if a new branch is grafted to a multicast tree by an existing mc-routing protocol, packets are re-marked to the LE PHB within a multicast DS node as long as no reservation was set up (by whatever mechanism) for the new branch. In order to protect ordinary BE users from a possible flood of re-marked packets which arrive with a better PHB, we defined this LE PHB. In this case, a source of LE packets is possibly located within a domain. Naturally, you will be able to do initial classification and marking or even policing, although I believe that often applications will do a pre-marking for LE. > can not use it on a network that is congested, but the words > were meant only to say that if a network has no capacity to > spare (that isn't being taken up by other types of traffic), > it may not be a good network to deploy this on. So, I don't > believe there is a conflict of philosophy here. In our definition, the LE PHB will be useful even in these congested networks, if you set the limit > 0. Regards, Roland -- Roland Bless -- e-Mail: bless@telematik.informatik.uni-karlsruhe.de Institute of Telematics, University of Karlsruhe, F.R. of Germany Zirkel 2, D-76128 Karlsruhe -- Office: Engesserstr.2 (Bld. 20.50), 1st floor Phone: +49 721 608-6396 Fax: +49 721 388097 _______________________________________________ diffserv mailing list diffserv@ietf.org http://www1.ietf.org/mailman/listinfo/diffserv Archive: http://www2.ietf.org/mail-archive/working-groups/diffserv/current/maillist.html From diffserv-admin@ietf.org Thu Dec 14 10:10: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 SMTP id KAA08329 for ; Thu, 14 Dec 2000 10:10:16 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id JAA04927; Thu, 14 Dec 2000 09:39:10 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id JAA04901 for ; Thu, 14 Dec 2000 09:39:06 -0500 (EST) Received: from crufty.research.bell-labs.com (crufty.research.bell-labs.com [204.178.16.49]) by ietf.org (8.9.1a/8.9.1a) with SMTP id JAA04299 for ; Thu, 14 Dec 2000 09:39:05 -0500 (EST) Received: from chair.dnrc.bell-labs.com ([135.180.161.201]) by crufty; Thu Dec 14 09:37:51 EST 2000 Received: from harlem.dnrc.bell-labs.com (harlem [135.180.161.4]) by chair.dnrc.bell-labs.com (8.9.3/8.9.3) with ESMTP id JAA05362; Thu, 14 Dec 2000 09:35:14 -0500 (EST) From: Dimitrios Stiliadis Received: (from stiliadi@localhost) by harlem.dnrc.bell-labs.com (8.9.3/8.9.3) id JAA25448; Thu, 14 Dec 2000 09:38:51 -0500 (EST) Message-Id: <200012141438.JAA25448@harlem.dnrc.bell-labs.com> Subject: Re: [Diffserv] Yesterday's EF discussion To: brian@hursley.ibm.com (Brian E Carpenter) Date: Thu, 14 Dec 2000 09:38:51 -0500 (EST) Cc: diffserv@ietf.org In-Reply-To: <3A38135E.1AD72AFF@hursley.ibm.com> from "Brian E Carpenter" at Dec 13, 2000 06:25:02 PM X-Mailer: ELM [version 2.5 PL2] MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: diffserv-admin@ietf.org Errors-To: diffserv-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Diffserv Discussion List X-BeenThere: diffserv@ietf.org Content-Transfer-Encoding: 7bit Brian, > > Nabil, > > The issue is what is least confusing to the user community - a new definition > with the old name, or a new name? I'm interested in opinions. > I fail to see why the definition is new. It is a complete definition of a previously vague text. I don't believe that the name should change, Cheers, Dimitri _______________________________________________ diffserv mailing list diffserv@ietf.org http://www1.ietf.org/mailman/listinfo/diffserv Archive: http://www2.ietf.org/mail-archive/working-groups/diffserv/current/maillist.html From diffserv-admin@ietf.org Thu Dec 14 10:50:28 2000 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with SMTP id KAA16377 for ; Thu, 14 Dec 2000 10:50:24 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id KAA05427; Thu, 14 Dec 2000 10:21:35 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id KAA05397 for ; Thu, 14 Dec 2000 10:21:31 -0500 (EST) 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 SMTP id KAA10097 for ; Thu, 14 Dec 2000 10:21:25 -0500 (EST) 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 JAA08415 for ; Thu, 14 Dec 2000 09:21:26 -0600 (CST) Received: from stl-hub-01.boeing.com (localhost [127.0.0.1]) by stl-av-01.boeing.com (8.9.3/8.9.2) with ESMTP id JAA16212 for ; Thu, 14 Dec 2000 09:21:24 -0600 (CST) Received: from xch-phlbh-01.he.boeing.com by stl-hub-01.boeing.com with ESMTP; Thu, 14 Dec 2000 09:21:17 -0600 Received: by xch-phlbh-01.he.boeing.com with Internet Mail Service (5.5.2650.21) id ; Thu, 14 Dec 2000 10:21:16 -0500 Message-Id: <4102273CEB77D211869200805FE6F593018C5BFC@xch-phl-01.he.boeing.com> From: "Manfredi, Albert E" To: "'Brian E Carpenter'" Cc: Diff Serv Subject: RE: [Diffserv] Yesterday's EF discussion Date: Thu, 14 Dec 2000 10:21:12 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: text/plain; charset="iso-8859-1" Sender: diffserv-admin@ietf.org Errors-To: diffserv-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Diffserv Discussion List X-BeenThere: diffserv@ietf.org Brian E Carpenter wrote: > Nabil, > > The issue is what is least confusing to the user community - > a new definition > with the old name, or a new name? I'm interested in opinions. My vote is to stay with EF, unless the group really wants to change EF into something that truly addresses only jitter (which I think would be unwise). Expedited implies that all delays are controlled, exactly as EFRESOLVE describes. Maybe some other class of EF service, which truly addresses jitter rather than delay, might be given a different name. Bert _______________________________________________ diffserv mailing list diffserv@ietf.org http://www1.ietf.org/mailman/listinfo/diffserv Archive: http://www2.ietf.org/mail-archive/working-groups/diffserv/current/maillist.html From diffserv-admin@ietf.org Thu Dec 14 10:53: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 SMTP id KAA17129 for ; Thu, 14 Dec 2000 10:53:47 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id KAA05495; Thu, 14 Dec 2000 10:24:55 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id KAA05462 for ; Thu, 14 Dec 2000 10:24:51 -0500 (EST) Received: from procyon.pmc-sierra.bc.ca (procyon.pmc-sierra.bc.ca [134.87.115.1]) by ietf.org (8.9.1a/8.9.1a) with SMTP id KAA10895 for ; Thu, 14 Dec 2000 10:24:49 -0500 (EST) Received: from bby1exi01.pmc-sierra.bc.ca (bby1exi01.pmc-sierra.bc.ca [216.241.231.251]) by procyon.pmc-sierra.bc.ca (6.6.6/6.6.6) with ESMTP id HAA15219 for ; Thu, 14 Dec 2000 07:24:20 -0800 (PST) Received: by bby1exi01.pmc-sierra.bc.ca with Internet Mail Service (5.5.2650.21) id ; Thu, 14 Dec 2000 07:24:20 -0800 Message-ID: <9DC5E2ABE65BD54CA9088DA3194461D6010C9AF9@BBY1EXM01> From: Shahram Davari To: diffserv@ietf.org Subject: RE: [Diffserv] Yesterday's EF discussion Date: Thu, 14 Dec 2000 07:24:19 -0800 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: text/plain Sender: diffserv-admin@ietf.org Errors-To: diffserv-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Diffserv Discussion List X-BeenThere: diffserv@ietf.org Hi All, Since, 1) The Charny-compromise is the closest to the RFC-2598 (as was expresses by overwhelming consensus), 2) It is essentially the same behavior as RFC-2598 (output rate-based definition), but has a more clear definition for all possible scenarios. 3) Implementers already know and have implemented EF and its rate-based definition and therefore changing the name would create confusion. Therefore I vote for keeping the EF name. Yours, Shahram Davari Systems Engineer Product Research Group PMC-Sierra, Inc. (Ottawa) Phone: (613) 271-4018 Fax: (613) 271-7007 _______________________________________________ diffserv mailing list diffserv@ietf.org http://www1.ietf.org/mailman/listinfo/diffserv Archive: http://www2.ietf.org/mail-archive/working-groups/diffserv/current/maillist.html From diffserv-admin@ietf.org Thu Dec 14 11:08: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 SMTP id LAA20233 for ; Thu, 14 Dec 2000 11:08:16 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id KAA05758; Thu, 14 Dec 2000 10:34:54 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id KAA05727 for ; Thu, 14 Dec 2000 10:34:50 -0500 (EST) 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 SMTP id KAA13042 for ; Thu, 14 Dec 2000 10:34:49 -0500 (EST) 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 KAA09576; Thu, 14 Dec 2000 10:35:41 -0600 Received: from d04nm200.raleigh.ibm.com (d04nm200.raleigh.ibm.com [9.67.228.37]) by southrelay02.raleigh.ibm.com (8.8.8m3/NCO v4.95) with ESMTP id KAA87306; Thu, 14 Dec 2000 10:34:14 -0500 Importance: Normal Subject: Re: [Diffserv] Counters in the classifier To: Andrew Smith Cc: Fred Baker , Kathleen Nichols , diffserv@ietf.org X-Mailer: Lotus Notes Release 5.0.3 (Intl) 21 March 2000 Message-ID: From: "Robert Moore" Date: Thu, 14 Dec 2000 10:34:29 -0500 X-MIMETrack: Serialize by Router on D04NM200/04/M/IBM(Release 5.0.3 (Intl)|21 March 2000) at 12/14/2000 10:34:19 AM MIME-Version: 1.0 Content-type: text/plain; charset=us-ascii Sender: diffserv-admin@ietf.org Errors-To: diffserv-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Diffserv Discussion List X-BeenThere: diffserv@ietf.org I don't know if my interpretation is correct, but here's what I *think* Fred is proposing: 1. Add a packet counter, but not an octet counter, to each ClassifierElement in a Classifier. 2. Retain the Counter action element for counting packets and/or octets that pass by an arbitrary point in the data path, such as one of the outputs from a meter. If this is in fact Fred's proposal, it's fine with me. Regards, Bob Bob Moore IBM Networking Software +1-919-254-4436 remoore@us.ibm.com Andrew Smith @ietf.org on 12/13/2000 06:54:45 PM Sent by: diffserv-admin@ietf.org To: Fred Baker cc: Kathleen Nichols , diffserv@ietf.org Subject: Re: [Diffserv] Counters in the classifier This does, again, beg the question of having even more overlap with what the DSMON MIB (in the RMON WG) does. I'm also a bit confused as to whether Fred's proposal *replaces* the existing "counter action" material in the MIB or is in addition to it. And is this addition/change expected to be rolled back into the Model draft also? Andrew Kathleen Nichols wrote: > > Fred Baker wrote: > .... > >> So this is my proposal. Kwok and I are editing the MIB this morning, with a >> view to this outcome, Andrew's comments, and some comments from Bert >> relating to TCs (want to pull them together into a separate module and do >> some minor tweaks). We will put in a packet counter in the classifier, and >> the chairs can tell us we did it wrong. >> >> Your comments, please. >> > > > Fred, I think what you are saying reflects what we talked > about before Monday's meeting: you have to set up a classifier > if you want to count (a particular DSCP for example). If > this is so, I certainly support that and thought we emerged > from that meeting with out any real case made for anything > else. > > Kathie > > _______________________________________________ > diffserv mailing list > diffserv@ietf.org > http://www1.ietf.org/mailman/listinfo/diffserv > Archive: http://www2.ietf.org/mail-archive/working-groups/diffserv/current/maillist.html _______________________________________________ diffserv mailing list diffserv@ietf.org http://www1.ietf.org/mailman/listinfo/diffserv Archive: http://www2.ietf.org/mail-archive/working-groups/diffserv/current/maillist.html _______________________________________________ diffserv mailing list diffserv@ietf.org http://www1.ietf.org/mailman/listinfo/diffserv Archive: http://www2.ietf.org/mail-archive/working-groups/diffserv/current/maillist.html From diffserv-admin@ietf.org Thu Dec 14 11:24: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 SMTP id LAA23769 for ; Thu, 14 Dec 2000 11:24:37 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id KAA05919; Thu, 14 Dec 2000 10:43:51 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id KAA05897 for ; Thu, 14 Dec 2000 10:43:43 -0500 (EST) Received: from usc.edu (root@usc.edu [128.125.253.136]) by ietf.org (8.9.1a/8.9.1a) with SMTP id KAA14955 for ; Thu, 14 Dec 2000 10:43:41 -0500 (EST) Received: from aludra.usc.edu (demir@aludra.usc.edu [128.125.253.184]) by usc.edu (8.9.3.1/8.9.3/usc) with ESMTP id HAA04398; Thu, 14 Dec 2000 07:43:38 -0800 (PST) Received: from localhost (demir@localhost) by aludra.usc.edu (8.9.3.1/8.9.3/usc) with ESMTP id HAA12574; Thu, 14 Dec 2000 07:43:37 -0800 (PST) Date: Thu, 14 Dec 2000 07:43:37 -0800 (PST) From: demir To: Brian E Carpenter cc: Diff Serv Subject: Re: What's in a name? Re: [Diffserv] Yesterday's EF discussion In-Reply-To: <3A386DBA.42F44DAA@research.bell-labs.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: diffserv-admin@ietf.org Errors-To: diffserv-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Diffserv Discussion List X-BeenThere: diffserv@ietf.org > Brian E Carpenter wrote: > [..] > > What should the name of the PHB be? > > Chair's proposal: Defined Rate (DR). I believe that after this long > > and confusing discussion, it would be wise to retire the previous name. > Brian, It sounds a good idea. However, I think, "Defined Rate" name is kind of misleading. How about "Destined Forwarding" PHB? (AF/DF, AC/DC :) Alper K. Demir _______________________________________________ diffserv mailing list diffserv@ietf.org http://www1.ietf.org/mailman/listinfo/diffserv Archive: http://www2.ietf.org/mail-archive/working-groups/diffserv/current/maillist.html From diffserv-admin@ietf.org Thu Dec 14 11:37: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 SMTP id LAA27226 for ; Thu, 14 Dec 2000 11:37:54 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id LAA06393; Thu, 14 Dec 2000 11:06:24 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id LAA06364 for ; Thu, 14 Dec 2000 11:06:18 -0500 (EST) Received: from mailhub1.almaden.ibm.com (mailhub1.almaden.ibm.com [198.4.83.44]) by ietf.org (8.9.1a/8.9.1a) with SMTP id LAA19810 for ; Thu, 14 Dec 2000 11:06:17 -0500 (EST) Received: from maui.almaden.ibm.com (maui.almaden.ibm.com [9.1.24.92]) by mailhub1.almaden.ibm.com (8.8.8/8.8.8) with ESMTP id IAA24582; Thu, 14 Dec 2000 08:02:39 -0800 Received: from hursley.ibm.com (gsine05.us.sine.ibm.com [9.14.6.45]) by maui.almaden.ibm.com (AIX4.3/8.9.3/8.7) with ESMTP id IAA27190; Thu, 14 Dec 2000 08:05:46 -0800 Message-ID: <3A38EF8E.FF65235D@hursley.ibm.com> Date: Thu, 14 Dec 2000 10:04:30 -0600 From: Brian E Carpenter Organization: IBM X-Mailer: Mozilla 4.61 [en] (Win98; I) X-Accept-Language: en,fr MIME-Version: 1.0 To: GARBISU Jean-Pierre FTRD/DMI/CAE CC: Simon Leinen , Yoram Bernet , diffserv@ietf.org Subject: Re: LBE PHB [was: [Diffserv] comments on the bulk handling draft] References: <91A311FF6A85D3118DDF0060080C3D82B7DAB3@lat3721.lannion.cnet.fr> Content-Type: text/plain; charset=iso-8859-1 X-MIME-Autoconverted: from quoted-printable to 8bit by optimus.ietf.org id LAA06365 Sender: diffserv-admin@ietf.org Errors-To: diffserv-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Diffserv Discussion List X-BeenThere: diffserv@ietf.org X-MIME-Autoconverted: from 8bit to quoted-printable by optimus.ietf.org id LAA06393 Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by ietf.org id LAA27226 No, we state explicitly that the SHOULD is not applied; in fact that is exactly why 2474 uses SHOULD instead of MUST. Please check the definition of SHOULD in RFC 2119. Brian GARBISU Jean-Pierre FTRD/DMI/CAE wrote: > > So we should consider a future minor (?) modification of RFC 2474 which is > stating in § 4.2.2.2 : > > PHBs selected by a Class Selector Codepoint > SHOULD give packets a probability of timely forwarding that is not > lower than that given to packets marked with a Class Selector > codepoint of lower relative order, under reasonable operating > conditions and traffic loads. > > Best regards > > jeanpierre.garbisu@francetelecom.fr > > -----Message d'origine----- > De : Brian E Carpenter [mailto:brian@hursley.ibm.com] > Envoyé : mardi 12 décembre 2000 17:04 > À : GARBISU Jean-Pierre FTRD/DMI/CAE > Cc : Simon Leinen; Yoram Bernet; diffserv@ietf.org > Objet : Re: LBE PHB [was: [Diffserv] comments on the bulk handling > draft] > > GARBISU Jean-Pierre FTRD/DMI/CAE wrote: > ... > > what will be the recommended precedence : 1 ? > > The suggested PHB was Class Selector 1, which can be viewed as > backwards-compatible with TOS Precedence 1. > > Brian > > _______________________________________________ > diffserv mailing list > diffserv@ietf.org > http://www1.ietf.org/mailman/listinfo/diffserv > Archive: > http://www2.ietf.org/mail-archive/working-groups/diffserv/current/maillist.h > tml > > _______________________________________________ > diffserv mailing list > diffserv@ietf.org > http://www1.ietf.org/mailman/listinfo/diffserv > Archive: http://www2.ietf.org/mail-archive/working-groups/diffserv/current/maillist.html _______________________________________________ diffserv mailing list diffserv@ietf.org http://www1.ietf.org/mailman/listinfo/diffserv Archive: http://www2.ietf.org/mail-archive/working-groups/diffserv/current/maillist.html From diffserv-admin@ietf.org Thu Dec 14 11:38: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 SMTP id LAA27268 for ; Thu, 14 Dec 2000 11:38:03 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id LAA06280; Thu, 14 Dec 2000 11:00:55 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id LAA06249 for ; Thu, 14 Dec 2000 11:00:51 -0500 (EST) Received: from pmesmtp02.wcom.com (pmesmtp02.wcom.com [199.249.20.2]) by ietf.org (8.9.1a/8.9.1a) with SMTP id LAA18646 for ; Thu, 14 Dec 2000 11:00:50 -0500 (EST) Received: from CONVERSION-DAEMON by firewall.mcit.com (PMDF V5.2-32 #42257) id <0G5K00701F2QDY@firewall.mcit.com> for diffserv@ietf.org; Thu, 14 Dec 2000 15:59:14 +0000 (GMT) Received: from pmismtp04.wcomnet.com ([166.38.62.39]) by firewall.mcit.com (PMDF V5.2-32 #42257) with ESMTP id <0G5K0062YF2QTN@firewall.mcit.com>; Thu, 14 Dec 2000 15:59:14 +0000 (GMT) Received: from CONVERSION-DAEMON by pmismtp04.wcomnet.com (PMDF V5.2-33 #42258) id <0G5K00201F2OAM@pmismtp04.wcomnet.com>; Thu, 14 Dec 2000 15:59:13 +0000 (GMT) Received: from pmismtp04.wcomnet.com by pmismtp04.wcomnet.com (PMDF V5.2-33 #42258) with SMTP id <0G5K00201F2L8O@pmismtp04.wcomnet.com>; Thu, 14 Dec 2000 15:59:12 +0000 (GMT) Received: from omzexch007.mcit.com ([166.37.194.38]) by pmismtp04.wcomnet.com (PMDF V5.2-33 #42258) with ESMTP id <0G5K00KPZF259T@pmismtp04.wcomnet.com>; Thu, 14 Dec 2000 15:58:53 +0000 (GMT) Received: by omzexch007 with Internet Mail Service (5.5.2651.58) id ; Thu, 14 Dec 2000 15:58:53 +0000 Content-return: allowed Date: Thu, 14 Dec 2000 15:58:51 +0000 From: "Iliff, Tina" Subject: RE: What's in a name? Re: [Diffserv] Yesterday's EF discussion To: "'demir'" , Brian E Carpenter Cc: Diff Serv Message-id: <492EB4A3F68CD411ABE800508B69362E14B422@RIPEXCH002.wcomnet.com> MIME-version: 1.0 X-Mailer: Internet Mail Service (5.5.2651.58) Content-type: text/plain; charset=ISO-8859-1 Sender: diffserv-admin@ietf.org Errors-To: diffserv-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Diffserv Discussion List X-BeenThere: diffserv@ietf.org I tend to agree with a name closer in context to Defined Rate. Destined Forwarding is closer in context to Assured Forwarding and does not describe this specific PHB. Tina Iliff -----Original Message----- From: demir [mailto:demir@usc.edu] Sent: Thursday, December 14, 2000 9:44 AM To: Brian E Carpenter Cc: Diff Serv Subject: Re: What's in a name? Re: [Diffserv] Yesterday's EF discussion > Brian E Carpenter wrote: > [..] > > What should the name of the PHB be? > > Chair's proposal: Defined Rate (DR). I believe that after this long > > and confusing discussion, it would be wise to retire the previous name. > Brian, It sounds a good idea. However, I think, "Defined Rate" name is kind of misleading. How about "Destined Forwarding" PHB? (AF/DF, AC/DC :) Alper K. Demir _______________________________________________ diffserv mailing list diffserv@ietf.org http://www1.ietf.org/mailman/listinfo/diffserv Archive: http://www2.ietf.org/mail-archive/working-groups/diffserv/current/maillist.h tml _______________________________________________ diffserv mailing list diffserv@ietf.org http://www1.ietf.org/mailman/listinfo/diffserv Archive: http://www2.ietf.org/mail-archive/working-groups/diffserv/current/maillist.html From diffserv-admin@ietf.org Thu Dec 14 11:50:32 2000 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with SMTP id LAA29845 for ; Thu, 14 Dec 2000 11:50:32 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id LAA06540; Thu, 14 Dec 2000 11:12:32 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id LAA06507 for ; Thu, 14 Dec 2000 11:12:27 -0500 (EST) Received: from zcars04e.ca.nortel.com (h56s242a129n47.user.nortelnetworks.com [47.129.242.56]) by ietf.org (8.9.1a/8.9.1a) with SMTP id LAA21151 for ; Thu, 14 Dec 2000 11:12:25 -0500 (EST) Message-Id: <200012141612.LAA21151@ietf.org> Received: from zcard00n.ca.nortel.com by zcars04e.ca.nortel.com; Thu, 14 Dec 2000 10:41:08 -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.2652.39) id YW39SXH7; Thu, 14 Dec 2000 10:37:48 -0500 Received: from zcars02x.ca.nortel.com ([47.23.81.10]) by zcard00f.ca.nortel.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2652.39) id Y6C6LYN2; Thu, 14 Dec 2000 10:37:47 -0500 Date: Thu, 14 Dec 2000 10:37:38 -0500 (EST) X-Sybari-Space: 00000000 00000000 00000000 From: "Nabil Seddigh" Reply-To: "Nabil Seddigh" Subject: Re: [Diffserv] Yesterday's EF discussion To: Brian E Carpenter cc: Diff Serv X-Mailer: Rosa 2.1 SunOS5.6 X-Rosa-Trace: nseddigh@zcars02x <47.23.81.10> MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-ID: X-Orig: Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by optimus.ietf.org id LAA06508 Sender: diffserv-admin@ietf.org Errors-To: 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 A new name may be useful for clarity/ownership amongst the authors of EF, EFRESOLVE and DRAFT-CHARNY - as well as possibly some of the folks on this list. However, there is another group of people to consider. I'm thinking of the multitudes of developers, product managers, network engineers, sales, marketting folks etc who are not on this list. It has taken a while to get terms like EF and AF socialized, understood and adopted. IMHO, adding a new name may cause more confusion than clarification. Best, Nabil >Nabil, > >The issue is what is least confusing to the user community - a new definition >with the old name, or a new name? I'm interested in opinions. > > Brian > >Nabil Seddigh wrote: >> >> In message "[Diffserv] Yesterday's EF discussion", Brian E Carpenter >> writes: >> >> > >> > What should the name of the PHB be? >> > Chair's proposal: Defined Rate (DR). I believe that after this >> long >> > and confusing discussion, it would be wise to retire the previous >> name. >> > >> >> Somehow DR sounds like a better name for a PDB. >> If it is decided that the "EF" name be retired, would suggest picking >> a name that's reflective of some kind of forwarding treatment. >> e.g. XF (Express Forwarding), LDJ (Low Delay Jitter Forwarding) >> etc >> >> Controversy aside, there's a lot of paper work out there with the name >> EF on it. Is there any way to escape without changing the name? >> >> Best, >> Nabil Seddigh > > _______________________________________________ diffserv mailing list diffserv@ietf.org http://www1.ietf.org/mailman/listinfo/diffserv Archive: http://www2.ietf.org/mail-archive/working-groups/diffserv/current/maillist.html From diffserv-admin@ietf.org Thu Dec 14 12:01: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 SMTP id MAA01222 for ; Thu, 14 Dec 2000 12:01:39 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id LAA06770; Thu, 14 Dec 2000 11:25:31 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id LAA06741 for ; Thu, 14 Dec 2000 11:25:27 -0500 (EST) Received: from mfo00.iij.ad.jp (mfo00.iij.ad.jp [202.232.2.117]) by ietf.org (8.9.1a/8.9.1a) with SMTP id LAA23957 for ; Thu, 14 Dec 2000 11:25:25 -0500 (EST) Received: from ff.iij4u.or.jp (ff.iij4u.or.jp [210.130.0.18]) by mfo00.iij.ad.jp (8.8.8/MFO1.3) with ESMTP id BAA04399; Fri, 15 Dec 2000 01:23:18 +0900 (JST) Received: from [207.137.70.218] (ietf.207.137.71.85.tx.verio.net [207.137.71.85]) by ff.iij4u.or.jp (8.8.8+2.2IIJ/4U1.1) with ESMTP id BAA17222; Fri, 15 Dec 2000 01:23:17 +0900 (JST) From: Yasusi Kanada To: diffserv Cc: kwok , crl Date: Thu, 14 Dec 2000 08:23:41 -0800 Message-Id: <20001214162341.27039@ff.iij4u.or.jp> X-Mailer: CTM PowerMail 3.0.1 MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Subject: [Diffserv] WIRR in Diffserv PIB Sender: diffserv-admin@ietf.org Errors-To: diffserv-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Diffserv Discussion List X-BeenThere: diffserv@ietf.org Content-Transfer-Encoding: 7bit In qosIfSchedulingCapsServiceDisc and qosSchedulerMethod in diffserv-pib-02, there is a scheduling algorithm called "wirr". (weighted interleaved roundrobin queueing (?) scheduling). However, there is no real explanation on this. If you keep this categorization in the next version of the draft, please add an explanation in Section 4.6.3. I am not sure the difference between "wrr" and "wirr", and I am not sure why they should be distinguished. Thanks. --- Yasusi Kanada, Ph.D, WWW: http://www.kanadas.com/ Email: kanada@crl.hitachi.co.jp (day), yasusi@kanadas.com (night) Network SE/SI Research Dept., IP Network Research Center., Hitachi Ltd. Totsuka-ku Yoshida-cho 292, Yokohama, 244-0817, Japan --- _______________________________________________ diffserv mailing list diffserv@ietf.org http://www1.ietf.org/mailman/listinfo/diffserv Archive: http://www2.ietf.org/mail-archive/working-groups/diffserv/current/maillist.html From diffserv-admin@ietf.org Thu Dec 14 12:24: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 SMTP id MAA04033 for ; Thu, 14 Dec 2000 12:24:55 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id LAA07226; Thu, 14 Dec 2000 11:43:40 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id LAA07196 for ; Thu, 14 Dec 2000 11:43:34 -0500 (EST) Received: from usc.edu (root@usc.edu [128.125.253.136]) by ietf.org (8.9.1a/8.9.1a) with SMTP id LAA28561 for ; Thu, 14 Dec 2000 11:43:32 -0500 (EST) Received: from koh-sun017.usc.edu (demir@koh-sun017.usc.edu [128.125.5.125]) by usc.edu (8.9.3.1/8.9.3/usc) with ESMTP id IAA12370; Thu, 14 Dec 2000 08:43:35 -0800 (PST) Received: from localhost (demir@localhost) by koh-sun017.usc.edu (8.9.3.1/8.9.3/usc) with ESMTP id IAA15388; Thu, 14 Dec 2000 08:43:33 -0800 (PST) Date: Thu, 14 Dec 2000 08:43:33 -0800 (PST) From: demir To: Nabil Seddigh cc: Brian E Carpenter , Diff Serv Subject: Re: [Diffserv] Yesterday's EF discussion In-Reply-To: <200012141612.LAA21151@ietf.org> 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 Nabil, > However, there is another group of people to consider. I'm thinking of > the multitudes of developers, product managers, network engineers, > sales, marketting folks etc who are not on this list. It has taken a > while to get terms like EF and AF socialized, understood and adopted. > IMHO, adding a new name may cause more confusion than clarification. I agree with above statements. However, what is their understanding of "EF"; yet, there is no "agreement" in Diffserv group on "EF"? Alper K. Demir _______________________________________________ diffserv mailing list diffserv@ietf.org http://www1.ietf.org/mailman/listinfo/diffserv Archive: http://www2.ietf.org/mail-archive/working-groups/diffserv/current/maillist.html From diffserv-admin@ietf.org Thu Dec 14 12:25: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 SMTP id MAA04052 for ; Thu, 14 Dec 2000 12:25:00 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id LAA07072; Thu, 14 Dec 2000 11:36:53 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id LAA07041 for ; Thu, 14 Dec 2000 11:36:49 -0500 (EST) Received: from usc.edu (root@usc.edu [128.125.253.136]) by ietf.org (8.9.1a/8.9.1a) with SMTP id LAA26960 for ; Thu, 14 Dec 2000 11:36:43 -0500 (EST) Received: from koh-sun017.usc.edu (demir@koh-sun017.usc.edu [128.125.5.125]) by usc.edu (8.9.3.1/8.9.3/usc) with ESMTP id IAA07386; Thu, 14 Dec 2000 08:36:46 -0800 (PST) Received: from localhost (demir@localhost) by koh-sun017.usc.edu (8.9.3.1/8.9.3/usc) with ESMTP id IAA15374; Thu, 14 Dec 2000 08:36:45 -0800 (PST) Date: Thu, 14 Dec 2000 08:36:45 -0800 (PST) From: demir To: "Iliff, Tina" cc: Brian E Carpenter , Diff Serv Subject: RE: What's in a name? Re: [Diffserv] Yesterday's EF discussion In-Reply-To: <492EB4A3F68CD411ABE800508B69362E14B422@RIPEXCH002.wcomnet.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 Tina, Is there any PHB whose "rate" is not "defined"? What about "EF" name? Yeah, in the alphabethical order, it is closer to letter 'A' than letter 'E'. 'E' can be associated with "delay variance", and 'D' with "delay". Between 'A' and 'D', 'B':Burstiness, 'C':Control :) Alper K. Demir > I tend to agree with a name closer in context to Defined Rate. Destined > Forwarding is closer in context to Assured Forwarding and does not describe > this specific PHB. > > Tina Iliff > > > -----Original Message----- > From: demir [mailto:demir@usc.edu] > Sent: Thursday, December 14, 2000 9:44 AM > To: Brian E Carpenter > Cc: Diff Serv > Subject: Re: What's in a name? Re: [Diffserv] Yesterday's EF discussion > > > > Brian E Carpenter wrote: > > [..] > > > What should the name of the PHB be? > > > Chair's proposal: Defined Rate (DR). I believe that after this long > > > and confusing discussion, it would be wise to retire the previous > name. > > > > Brian, > It sounds a good idea. However, I think, "Defined Rate" name is kind of > misleading. How about "Destined Forwarding" PHB? (AF/DF, AC/DC :) > > Alper K. Demir > > > _______________________________________________ > diffserv mailing list > diffserv@ietf.org > http://www1.ietf.org/mailman/listinfo/diffserv > Archive: > http://www2.ietf.org/mail-archive/working-groups/diffserv/current/maillist.h > tml > > _______________________________________________ > diffserv mailing list > diffserv@ietf.org > http://www1.ietf.org/mailman/listinfo/diffserv > Archive: http://www2.ietf.org/mail-archive/working-groups/diffserv/current/maillist.html > _______________________________________________ diffserv mailing list diffserv@ietf.org http://www1.ietf.org/mailman/listinfo/diffserv Archive: http://www2.ietf.org/mail-archive/working-groups/diffserv/current/maillist.html From diffserv-admin@ietf.org Thu Dec 14 12:37:08 2000 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with SMTP id MAA05522 for ; Thu, 14 Dec 2000 12:37:08 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id MAA07879; Thu, 14 Dec 2000 12:04:36 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id MAA07847 for ; Thu, 14 Dec 2000 12:04:32 -0500 (EST) Received: from procyon.pmc-sierra.bc.ca (procyon.pmc-sierra.bc.ca [134.87.115.1]) by ietf.org (8.9.1a/8.9.1a) with SMTP id MAA01553 for ; Thu, 14 Dec 2000 12:04:30 -0500 (EST) Received: from bby1exi01.pmc-sierra.bc.ca (bby1exi01.pmc-sierra.bc.ca [216.241.231.251]) by procyon.pmc-sierra.bc.ca (6.6.6/6.6.6) with ESMTP id JAA22896; Thu, 14 Dec 2000 09:00:43 -0800 (PST) Received: by bby1exi01.pmc-sierra.bc.ca with Internet Mail Service (5.5.2650.21) id ; Thu, 14 Dec 2000 09:00:44 -0800 Message-ID: <9DC5E2ABE65BD54CA9088DA3194461D6010C9AFA@BBY1EXM01> From: Shahram Davari To: "'demir'" , Nabil Seddigh Cc: Brian E Carpenter , Diff Serv Subject: RE: [Diffserv] Yesterday's EF discussion Date: Thu, 14 Dec 2000 09:00:43 -0800 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: text/plain Sender: diffserv-admin@ietf.org Errors-To: diffserv-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Diffserv Discussion List X-BeenThere: diffserv@ietf.org Demir, I think the industry's understanding of EF is what is in RFC-2598, which is a rate-based service in which the arrival rate is less than departure rate in small intervals. Since the language used in RFC-2598 was not very accurate, in the sense that it didn't cover some valid scenarios, the work group's intent was to lay a clear definition that covers those valid scenarios, and at the same time does not deviate from the industry's understanding of EF. So the intent was to keep the EF PHB behavior but to give a more accurate definition. Yours, -Shahram > -----Original Message----- > From: demir [mailto:demir@usc.edu] > Sent: Thursday, December 14, 2000 12:44 PM > To: Nabil Seddigh > Cc: Brian E Carpenter; Diff Serv > Subject: Re: [Diffserv] Yesterday's EF discussion > > > Nabil, > > However, there is another group of people to consider. I'm > thinking of > > the multitudes of developers, product managers, network engineers, > > sales, marketting folks etc who are not on this list. It > has taken a > > while to get terms like EF and AF socialized, understood > and adopted. > > IMHO, adding a new name may cause more confusion than clarification. > > I agree with above statements. However, what is their understanding of > "EF"; yet, there is no "agreement" in Diffserv group on "EF"? > > Alper K. Demir > > > _______________________________________________ > diffserv mailing list > diffserv@ietf.org > http://www1.ietf.org/mailman/listinfo/diffserv > Archive: > http://www2.ietf.org/mail-archive/working-groups/diffserv/curr ent/maillist.html _______________________________________________ diffserv mailing list diffserv@ietf.org http://www1.ietf.org/mailman/listinfo/diffserv Archive: http://www2.ietf.org/mail-archive/working-groups/diffserv/current/maillist.html From diffserv-admin@ietf.org Thu Dec 14 12:52:52 2000 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with SMTP id MAA07546 for ; Thu, 14 Dec 2000 12:52:52 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id MAA08153; Thu, 14 Dec 2000 12:19:46 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id MAA08123 for ; Thu, 14 Dec 2000 12:19:42 -0500 (EST) Received: from ennovatenetworks.com ([63.102.148.71]) by ietf.org (8.9.1a/8.9.1a) with SMTP id MAA03380 for ; Thu, 14 Dec 2000 12:19:40 -0500 (EST) Received: from tworster (ietf.207.137.72.80.tx.verio.net [207.137.72.80]) by ennovatenetworks.com (8.8.7/8.8.7) with SMTP id MAA25741; Thu, 14 Dec 2000 12:19:39 -0500 (EST) (envelope-from tom@ennovatenetworks.com) From: "tom worster" To: "'Brian E Carpenter'" Cc: "'Diff Serv'" Subject: RE: [Diffserv] Yesterday's EF discussion Date: Thu, 14 Dec 2000 12:19:39 -0500 Message-ID: <001a01c065f2$0ae4c630$504889cf@49thietf.org> 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.2911.0) Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2314.1300 In-Reply-To: <3A38135E.1AD72AFF@hursley.ibm.com> Content-Transfer-Encoding: 7bit Sender: diffserv-admin@ietf.org Errors-To: diffserv-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Diffserv Discussion List X-BeenThere: diffserv@ietf.org Content-Transfer-Encoding: 7bit From: diffserv-admin@ietf.org [mailto:diffserv-admin@ietf.org] On Behalf Of Brian E Carpenter > > The issue is what is least confusing to the user community - > a new definition > with the old name, or a new name? I'm interested in opinions. brian, i think it should be called ef. people have got used to talking about ef and the "compromise" fits what they mean by that. c u tom _______________________________________________ diffserv mailing list diffserv@ietf.org http://www1.ietf.org/mailman/listinfo/diffserv Archive: http://www2.ietf.org/mail-archive/working-groups/diffserv/current/maillist.html From diffserv-admin@ietf.org Thu Dec 14 13:07: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 SMTP id NAA09225 for ; Thu, 14 Dec 2000 13:07:00 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id MAA08620; Thu, 14 Dec 2000 12:33:41 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id MAA08589 for ; Thu, 14 Dec 2000 12:33:37 -0500 (EST) Received: from mailhub1.almaden.ibm.com (mailhub1.almaden.ibm.com [198.4.83.44]) by ietf.org (8.9.1a/8.9.1a) with SMTP id MAA05079 for ; Thu, 14 Dec 2000 12:33:24 -0500 (EST) Received: from maui.almaden.ibm.com (maui.almaden.ibm.com [9.1.24.92]) by mailhub1.almaden.ibm.com (8.8.8/8.8.8) with ESMTP id JAA35336; Thu, 14 Dec 2000 09:29:44 -0800 Received: from hursley.ibm.com (gsine05.us.sine.ibm.com [9.14.6.45]) by maui.almaden.ibm.com (AIX4.3/8.9.3/8.7) with ESMTP id JAA27200; Thu, 14 Dec 2000 09:32:53 -0800 Message-ID: <3A3903FC.69621E7D@hursley.ibm.com> Date: Thu, 14 Dec 2000 11:31:40 -0600 From: Brian E Carpenter Organization: IBM X-Mailer: Mozilla 4.61 [en] (Win98; I) X-Accept-Language: en,fr MIME-Version: 1.0 To: demir CC: Diff Serv Subject: Re: [Diffserv] Yesterday's EF discussion References: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: diffserv-admin@ietf.org Errors-To: diffserv-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Diffserv Discussion List X-BeenThere: diffserv@ietf.org Content-Transfer-Encoding: 7bit Demir, You've made your point. I'd like to hear from the silent majority: do we change the name or not? Brian demir wrote: > > Shahram, > I am not sure if what you stated was the industry's understanding. ... _______________________________________________ diffserv mailing list diffserv@ietf.org http://www1.ietf.org/mailman/listinfo/diffserv Archive: http://www2.ietf.org/mail-archive/working-groups/diffserv/current/maillist.html From diffserv-admin@ietf.org Thu Dec 14 13:09: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 SMTP id NAA09577 for ; Thu, 14 Dec 2000 13:09:48 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id MAA08388; Thu, 14 Dec 2000 12:28:57 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id MAA08357 for ; Thu, 14 Dec 2000 12:28:52 -0500 (EST) Received: from usc.edu (root@usc.edu [128.125.253.136]) by ietf.org (8.9.1a/8.9.1a) with SMTP id MAA04529 for ; Thu, 14 Dec 2000 12:28:52 -0500 (EST) Received: from koh-sun017.usc.edu (demir@koh-sun017.usc.edu [128.125.5.125]) by usc.edu (8.9.3.1/8.9.3/usc) with ESMTP id JAA17061; Thu, 14 Dec 2000 09:28:53 -0800 (PST) Received: from localhost (demir@localhost) by koh-sun017.usc.edu (8.9.3.1/8.9.3/usc) with ESMTP id JAA15493; Thu, 14 Dec 2000 09:28:52 -0800 (PST) Date: Thu, 14 Dec 2000 09:28:52 -0800 (PST) From: demir To: Shahram Davari cc: Nabil Seddigh , Brian E Carpenter , Diff Serv Subject: RE: [Diffserv] Yesterday's EF discussion In-Reply-To: <9DC5E2ABE65BD54CA9088DA3194461D6010C9AFA@BBY1EXM01> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: diffserv-admin@ietf.org Errors-To: diffserv-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Diffserv Discussion List X-BeenThere: diffserv@ietf.org Shahram, I am not sure if what you stated was the industry's understanding. Let me quote something taken from "The `Virtual Wire' Per-Domain Behavior" draft (you can see the same info at RFC 2598): "[RFC2598] describes a diffserv PHB called expedited forwarding (EF) intended for use in building a scalable, low loss, low latency, low jitter, assured bandwidth, end-to-end service that appears to the endpoints like an unshared, point-to-point connection or `virtual wire.'" I assume, that was the "industry's understanding" of EF. What happened? It was claimed that this "rate-based" definition was not enough to define such services in a "expedited" manner. As a result, there has been discussions: one "delay-oriented expedited" approach, other "delay variance-oriented expedited" aproach. What "expedited" meant is "low jitter" (RFC-2598). There is a tendency to "use" B. Davie and draft-charny's (and group's) this "delay-oriented" approach cause it has roots to "rate". If this "delay-oriented" approach will have the "EF" name, it would be VERY VERY confusing (I know they are just names). My suggestion is: To keep EF for its "low-jitter" expedition. Forget about old "rate-oriented" "EF" and all "rate" related names. Use a different name for the new one (my suggestion is: "Destined Forwarding"). P.S. "assured bandwidth"'s 'A' is not the same as "assured forwarding's" 'A'. It would be better to use another word for "assured bandwidth"'s 'A'. Alper K. Demir On Thu, 14 Dec 2000, Shahram Davari wrote: > Demir, > > I think the industry's understanding of EF is what is in RFC-2598, which is a rate-based service in which the arrival rate is less than departure rate in small intervals. Since the language used in RFC-2598 was not very accurate, in the sense that it didn't cover some valid scenarios, the work group's intent was to lay a clear definition that covers those valid scenarios, and at the same time does not deviate from the industry's understanding of EF. So the intent was to keep the EF PHB behavior but to give a more accurate definition. > > Yours, > -Shahram > > > -----Original Message----- > > From: demir [mailto:demir@usc.edu] > > Sent: Thursday, December 14, 2000 12:44 PM > > To: Nabil Seddigh > > Cc: Brian E Carpenter; Diff Serv > > Subject: Re: [Diffserv] Yesterday's EF discussion > > > > > > Nabil, > > > However, there is another group of people to consider. I'm > > thinking of > > > the multitudes of developers, product managers, network engineers, > > > sales, marketting folks etc who are not on this list. It > > has taken a > > > while to get terms like EF and AF socialized, understood > > and adopted. > > > IMHO, adding a new name may cause more confusion than clarification. > > > > I agree with above statements. However, what is their understanding of > > "EF"; yet, there is no "agreement" in Diffserv group on "EF"? > > > > Alper K. Demir > > > > > > _______________________________________________ > > diffserv mailing list > > diffserv@ietf.org > > http://www1.ietf.org/mailman/listinfo/diffserv > > Archive: > > http://www2.ietf.org/mail-archive/working-groups/diffserv/curr > ent/maillist.html > _______________________________________________ diffserv mailing list diffserv@ietf.org http://www1.ietf.org/mailman/listinfo/diffserv Archive: http://www2.ietf.org/mail-archive/working-groups/diffserv/current/maillist.html From diffserv-admin@ietf.org Thu Dec 14 13:25:57 2000 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with SMTP id NAA11512 for ; Thu, 14 Dec 2000 13:25:52 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id MAA08855; Thu, 14 Dec 2000 12:44:02 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id MAA08824 for ; Thu, 14 Dec 2000 12:43:58 -0500 (EST) Received: from bells.cs.ucl.ac.uk (bells.cs.ucl.ac.uk [128.16.5.31]) by ietf.org (8.9.1a/8.9.1a) with SMTP id MAA06492 for ; Thu, 14 Dec 2000 12:43:57 -0500 (EST) Received: from sonic.cs.ucl.ac.uk by bells.cs.ucl.ac.uk with local SMTP id ; Thu, 14 Dec 2000 17:43:17 +0000 To: Shahram Davari cc: Diff Serv Subject: Re: [Diffserv] Yesterday's EF discussion In-reply-to: Your message of "Thu, 14 Dec 2000 09:00:43 PST." <9DC5E2ABE65BD54CA9088DA3194461D6010C9AFA@BBY1EXM01> Date: Thu, 14 Dec 2000 17:43:16 +0000 Message-ID: <8220.976815796@cs.ucl.ac.uk> From: Jon Crowcroft Sender: diffserv-admin@ietf.org Errors-To: diffserv-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Diffserv Discussion List X-BeenThere: diffserv@ietf.org 1/ there is no ONE industry so this is wrong - the EF resolution show of hands in the room chose to take an interpretation of the rfc which is as you say - however, people should remember that there was acutally a very complex rich argument behind Van's original model which we've now lost - the model was not a CBR service (classic telco industry) with a rate but delay and delay jtter "to be defined"....because Van, unlike some of you, had considered the entire business case for an IP provider from the user requirement, down to the wire and routers..... If you are an ISP that owns your level 2 network (like many of the incumebbent telos that have succesfully deployed IP too), there's ZERO need to offer this new service as an IP level implemented service. if you are not, then its ggonna be hard to in some cases - van's service and phb (flawed as the explanation was) did actually have abusiness case - the colour aware "compromise" might be pulled out to do this perhaps, but its not the same PHB or the same VW combinastion that you seem to think industry understands, so we necessarily will have at least 2 PHBs and i believe at least two services i dont care what they are called personally, as brian said, goo and bar would do nicely (actually i have a hard time understanding the word "expedtited" anyhow, let alone speliong it:-) btw: the nearest i can think of the service, PDB, and colour blind spec being used ffor is some thing frame relay folks call committed information rate... In message <9DC5E2ABE65BD54CA9088DA3194461D6010C9AFA@BBY1EXM01>, Shahram Davari typed: >>Demir, >> >>I think the industry's understanding of EF is what is in RFC-2598, which is a rate-based service in which the arrival rate is less than departure rate in small intervals. Since the language used in RFC-2598 was not very accurate, in the sense that it didn't cover some valid scenarios, the work group's intent was to lay a clear definition that covers those valid scenarios, and at the same time does not deviate from the industry's understanding of EF. So the intent was to keep the EF PHB behavior but to give a more accurate definition. >> >>Yours, >>-Shahram >> >>> -----Original Message----- >>> From: demir [mailto:demir@usc.edu] >>> Sent: Thursday, December 14, 2000 12:44 PM >>> To: Nabil Seddigh >>> Cc: Brian E Carpenter; Diff Serv >>> Subject: Re: [Diffserv] Yesterday's EF discussion >>> >>> >>> Nabil, >>> > However, there is another group of people to consider. I'm >>> thinking of >>> > the multitudes of developers, product managers, network engineers, >>> > sales, marketting folks etc who are not on this list. It >>> has taken a >>> > while to get terms like EF and AF socialized, understood >>> and adopted. >>> > IMHO, adding a new name may cause more confusion than clarification. >>> >>> I agree with above statements. However, what is their understanding of >>> "EF"; yet, there is no "agreement" in Diffserv group on "EF"? >>> >>> Alper K. Demir >>> >>> >>> _______________________________________________ >>> diffserv mailing list >>> diffserv@ietf.org >>> http://www1.ietf.org/mailman/listinfo/diffserv >>> Archive: >>> http://www2.ietf.org/mail-archive/working-groups/diffserv/curr >>ent/maillist.html >> >>_______________________________________________ >>diffserv mailing list >>diffserv@ietf.org >>http://www1.ietf.org/mailman/listinfo/diffserv >>Archive: http://www2.ietf.org/mail-archive/working-groups/diffserv/current/maillist.html >> cheers jon _______________________________________________ diffserv mailing list diffserv@ietf.org http://www1.ietf.org/mailman/listinfo/diffserv Archive: http://www2.ietf.org/mail-archive/working-groups/diffserv/current/maillist.html From diffserv-admin@ietf.org Thu Dec 14 13:25: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 SMTP id NAA11537 for ; Thu, 14 Dec 2000 13:25:59 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id MAA08927; Thu, 14 Dec 2000 12:46:03 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id MAA08900 for ; Thu, 14 Dec 2000 12:45:59 -0500 (EST) Received: from procyon.pmc-sierra.bc.ca (procyon.pmc-sierra.bc.ca [134.87.115.1]) by ietf.org (8.9.1a/8.9.1a) with SMTP id MAA06720 for ; Thu, 14 Dec 2000 12:45:58 -0500 (EST) Received: from bby1exi01.pmc-sierra.bc.ca (bby1exi01.pmc-sierra.bc.ca [216.241.231.251]) by procyon.pmc-sierra.bc.ca (6.6.6/6.6.6) with ESMTP id JAA27403; Thu, 14 Dec 2000 09:44:56 -0800 (PST) Received: by bby1exi01.pmc-sierra.bc.ca with Internet Mail Service (5.5.2650.21) id ; Thu, 14 Dec 2000 09:44:56 -0800 Message-ID: <9DC5E2ABE65BD54CA9088DA3194461D6010C9AFB@BBY1EXM01> From: Shahram Davari To: "'demir'" Cc: "'diffserv@ietf.org'" Subject: RE: [Diffserv] Yesterday's EF discussion Date: Thu, 14 Dec 2000 09:44:54 -0800 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: text/plain Sender: diffserv-admin@ietf.org Errors-To: diffserv-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Diffserv Discussion List X-BeenThere: diffserv@ietf.org Demir, > -----Original Message----- > From: demir [mailto:demir@usc.edu] > Sent: Thursday, December 14, 2000 1:29 PM > To: Shahram Davari > Cc: Nabil Seddigh; Brian E Carpenter; Diff Serv > Subject: RE: [Diffserv] Yesterday's EF discussion > > > Shahram, > I am not sure if what you stated was the industry's > understanding. Let me > quote something taken from "The `Virtual Wire' Per-Domain > Behavior" draft > (you can see the same info at RFC 2598): > "[RFC2598] describes a diffserv PHB called expedited forwarding > (EF) intended for use in building a scalable, low loss, low > latency, low jitter, assured bandwidth, end-to-end service that > appears to the endpoints like an unshared, point-to-point > connection or > `virtual wire.'" > I assume, that was the "industry's understanding" of EF. What > happened? It was claimed that this "rate-based" definition > was not enough > to define such services in a "expedited" manner As a result, > there has > been discussions: one "delay-oriented expedited" approach, > other "delay > variance-oriented expedited" aproach. I am sorry, but I don't recall such a reason for changing RFC-2598. For your information it all started by me trying to check a number of schedulers that were mentioned in RFC-2598, for EF compliance. I found that for certain valid input traffic, I couldn't find any scheduler to satisfy the exact RFC-2598 definition. So I brought it up to the attention of the WG and many agreed that the EF definition as stated in RFC-2598 needed to be fixed. It was never the intend to redefine EF so that it could be used by any particular PDB. To do that there were better paths, such as defining a new PHB, or adding the additional restrictions to the PDB itself. Yours, -Shahram What "expedited" meant is "low > jitter" (RFC-2598). There is a tendency to "use" B. Davie and > draft-charny's (and group's) this "delay-oriented" approach > cause it has > roots to "rate". > If this "delay-oriented" approach will have the "EF" name, it would be > VERY VERY confusing (I know they are just names). > My suggestion is: To keep EF for its "low-jitter" expedition. > Forget about > old "rate-oriented" "EF" and all "rate" related names. Use a different > name for the new one (my suggestion is: "Destined Forwarding"). > > P.S. "assured bandwidth"'s 'A' is not the same as "assured > forwarding's" 'A'. It would be better to use another word for "assured > bandwidth"'s 'A'. > > Alper K. Demir > > > > > > On Thu, 14 Dec 2000, Shahram Davari wrote: > > > Demir, > > > > I think the industry's understanding of EF is what is in > RFC-2598, which is a rate-based service in which the arrival > rate is less than departure rate in small intervals. Since > the language used in RFC-2598 was not very accurate, in the > sense that it didn't cover some valid scenarios, the work > group's intent was to lay a clear definition that covers > those valid scenarios, and at the same time does not deviate > from the industry's understanding of EF. So the intent was to > keep the EF PHB behavior but to give a more accurate definition. > > > > Yours, > > -Shahram > > > > > -----Original Message----- > > > From: demir [mailto:demir@usc.edu] > > > Sent: Thursday, December 14, 2000 12:44 PM > > > To: Nabil Seddigh > > > Cc: Brian E Carpenter; Diff Serv > > > Subject: Re: [Diffserv] Yesterday's EF discussion > > > > > > > > > Nabil, > > > > However, there is another group of people to consider. I'm > > > thinking of > > > > the multitudes of developers, product managers, > network engineers, > > > > sales, marketting folks etc who are not on this list. It > > > has taken a > > > > while to get terms like EF and AF socialized, understood > > > and adopted. > > > > IMHO, adding a new name may cause more confusion than > clarification. > > > > > > I agree with above statements. However, what is their > understanding of > > > "EF"; yet, there is no "agreement" in Diffserv group on "EF"? > > > > > > Alper K. Demir > > > > > > > > > _______________________________________________ > > > diffserv mailing list > > > diffserv@ietf.org > > > http://www1.ietf.org/mailman/listinfo/diffserv > > > Archive: > > > http://www2.ietf.org/mail-archive/working-groups/diffserv/curr > > ent/maillist.html > > > > > _______________________________________________ > diffserv mailing list > diffserv@ietf.org > http://www1.ietf.org/mailman/listinfo/diffserv > Archive: > http://www2.ietf.org/mail-archive/working-groups/diffserv/curr ent/maillist.html _______________________________________________ diffserv mailing list diffserv@ietf.org http://www1.ietf.org/mailman/listinfo/diffserv Archive: http://www2.ietf.org/mail-archive/working-groups/diffserv/current/maillist.html From diffserv-admin@ietf.org Thu Dec 14 13:28: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 SMTP id NAA11808 for ; Thu, 14 Dec 2000 13:28:06 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id NAA09397; Thu, 14 Dec 2000 13:02:04 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id NAA09366 for ; Thu, 14 Dec 2000 13:02:00 -0500 (EST) Received: from usc.edu (root@usc.edu [128.125.253.136]) by ietf.org (8.9.1a/8.9.1a) with SMTP id NAA08667 for ; Thu, 14 Dec 2000 13:01:59 -0500 (EST) Received: from koh-sun017.usc.edu (demir@koh-sun017.usc.edu [128.125.5.125]) by usc.edu (8.9.3.1/8.9.3/usc) with ESMTP id KAA13779; Thu, 14 Dec 2000 10:01:59 -0800 (PST) Received: from localhost (demir@localhost) by koh-sun017.usc.edu (8.9.3.1/8.9.3/usc) with ESMTP id KAA15597; Thu, 14 Dec 2000 10:01:58 -0800 (PST) Date: Thu, 14 Dec 2000 10:01:58 -0800 (PST) From: demir To: Shahram Davari cc: "'diffserv@ietf.org'" Subject: RE: [Diffserv] Yesterday's EF discussion In-Reply-To: <9DC5E2ABE65BD54CA9088DA3194461D6010C9AFB@BBY1EXM01> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: diffserv-admin@ietf.org Errors-To: diffserv-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Diffserv Discussion List X-BeenThere: diffserv@ietf.org Shahram, > I am sorry, but I don't recall such a reason for changing RFC-2598. For your information it all started by me trying to check a number of schedulers that were mentioned in RFC-2598, for EF compliance. I found that for certain valid input traffic, I couldn't find any scheduler to satisfy the exact RFC-2598 definition. So I brought it up to the attention of the WG and many agreed that the EF definition as stated in RFC-2598 needed to be fixed. I am sorry if what I wrote is giving a source or reasoning. I was trying to "evaluate". Should I say "process/aim/result/?"? > > It was never the intend to redefine EF so that it could be used by any particular PDB. To do that there were better paths, such as defining a new PHB, or adding the additional restrictions to the PDB itself. I didn't say that it was intended for a particular PDB. I was trying to write some words about "industry's understanding". I happen to copy the quoted words from VW PDB. Same words are in RFC-2598 (I wrote this down, too). Alper K. Demir _______________________________________________ diffserv mailing list diffserv@ietf.org http://www1.ietf.org/mailman/listinfo/diffserv Archive: http://www2.ietf.org/mail-archive/working-groups/diffserv/current/maillist.html From diffserv-admin@ietf.org Thu Dec 14 13:40: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 SMTP id NAA13317 for ; Thu, 14 Dec 2000 13:40:57 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id NAA09710; Thu, 14 Dec 2000 13:16:02 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id NAA09678 for ; Thu, 14 Dec 2000 13:15:58 -0500 (EST) Received: from sj-msg-core-4.cisco.com (sj-msg-core-4.cisco.com [171.71.163.10]) by ietf.org (8.9.1a/8.9.1a) with SMTP id NAA10300 for ; Thu, 14 Dec 2000 13:15:57 -0500 (EST) Received: from airborne.cisco.com (airborne.cisco.com [171.71.154.32]) by sj-msg-core-4.cisco.com (8.9.3/8.9.1) with ESMTP id KAA11985 for ; Thu, 14 Dec 2000 10:15:29 -0800 (PST) Received: from localhost.localdomain.cisco.com (ssh-sj1.cisco.com [171.68.225.134]) by airborne.cisco.com (Mirapoint) with ESMTP id ACE00240; Thu, 14 Dec 2000 10:15:25 -0800 (PST) X-Mailer: emacs 20.7.1 (via feedmail 8 I); VM 6.87 under Emacs 20.7.1 From: "Scott Brim" MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <14905.3591.888860.570272@localhost.localdomain> Date: Thu, 14 Dec 2000 10:14:31 -0800 To: diffserv@ietf.org Subject: RE: [Diffserv] Yesterday's EF discussion In-Reply-To: <9DC5E2ABE65BD54CA9088DA3194461D6010C9AF9@BBY1EXM01> References: <9DC5E2ABE65BD54CA9088DA3194461D6010C9AF9@BBY1EXM01> Content-Transfer-Encoding: 7bit Sender: diffserv-admin@ietf.org Errors-To: diffserv-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 also think that while there may be some confusion for a while, it's much better to keep the name EF. There are multiple interpretations of "EF", but only below a certain threshold of detail. Those who know the differences and would be concerned by them are also those who would not be confused by calling whatever we produce EF. Those who are farther from the issues only know what EF is *for*, which has not changed. They are not concerned about the details, they often would feel uncomfortable when presented with them, and we would have to bother them with those details in order to explain the new name to them. The new name helps those who don't need it and potentially causes us trouble with those who might. ..Scott _______________________________________________ diffserv mailing list diffserv@ietf.org http://www1.ietf.org/mailman/listinfo/diffserv Archive: http://www2.ietf.org/mail-archive/working-groups/diffserv/current/maillist.html From diffserv-admin@ietf.org Thu Dec 14 13:45: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 SMTP id NAA13824 for ; Thu, 14 Dec 2000 13:45:10 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id NAA09651; Thu, 14 Dec 2000 13:14:22 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id NAA09623 for ; Thu, 14 Dec 2000 13:14:18 -0500 (EST) Received: from sj-msg-core-4.cisco.com (sj-msg-core-4.cisco.com [171.71.163.10]) by ietf.org (8.9.1a/8.9.1a) with SMTP id NAA10121 for ; Thu, 14 Dec 2000 13:14:17 -0500 (EST) Received: from bdaviepc.cisco.com (sjc-vpn-228.cisco.com [10.21.64.228]) by sj-msg-core-4.cisco.com (8.9.3/8.9.1) with SMTP id KAA10466 for ; Thu, 14 Dec 2000 10:13:49 -0800 (PST) From: "Bruce Davie" To: "Diffserv@Ietf. Org" Subject: RE: [Diffserv] Yesterday's EF discussion Date: Thu, 14 Dec 2000 13:14:10 -0500 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2910.0) Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2314.1300 Content-Transfer-Encoding: 7bit Sender: diffserv-admin@ietf.org Errors-To: diffserv-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Diffserv Discussion List X-BeenThere: diffserv@ietf.org Content-Transfer-Encoding: 7bit I think Brian's proposal that the name EF be retired and that the PHB selected by the WG on Tuesday be given a new name accurately captures the contention of the RFC 2598 authors that we had defined a new PHB. However, it was our clearly stated goal simply to clarify the PHB definition of RFC 2598, not to define a new PHB. One of the arguments made in favor of our definition (not only by its authors) was that it closely matched the market understanding of EF as currently implemented and deployed. And I believe the consensus in Pittsburgh was that RFC 2598 needed to be cleaned up, not that EF needed to be retired. So it is my impression that renaming our definition to something other than EF runs counter to the consensus expressed in the working group. It was also pointed out to me prior to the WG meeting by one of the proponents of the EFRESOLVE definition that it would be "irresponsible" to retire the term EF when it is already well-understood in the marketplace. Now that the WG has established consensus that draft-charny more accurately reflects the understanding of EF than EFRESOLVE, I can't imagine that it is any less irresponsible to retire the term. What's in a name? Once a name has a widely understood meaning, it only causes confusion to change it. A rose by any other name would smell as sweet, but if you try to sell bunches of sweet-smelling, red frobnitzes on Valentines day, the market will tell you what's in a name. Bruce _______________________________________________ diffserv mailing list diffserv@ietf.org http://www1.ietf.org/mailman/listinfo/diffserv Archive: http://www2.ietf.org/mail-archive/working-groups/diffserv/current/maillist.html From diffserv-admin@ietf.org Thu Dec 14 13:53:20 2000 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with SMTP id NAA15138 for ; Thu, 14 Dec 2000 13:53:20 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id NAA10001; Thu, 14 Dec 2000 13:28:06 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id NAA09962 for ; Thu, 14 Dec 2000 13:28:02 -0500 (EST) 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 NAA11788 for ; Thu, 14 Dec 2000 13:28:01 -0500 (EST) Received: from grubby.research.bell-labs.com ([135.104.2.9]) by dirty; Thu Dec 14 13:27:51 EST 2000 Received: from mail1.pa.bell-labs.com ([135.250.8.11]) by grubby; Thu Dec 14 13:27:51 EST 2000 Received: from research.bell-labs.com (ex-vpn66.pa.bell-labs.com [135.250.1.66]) by mail1.pa.bell-labs.com (Mirapoint) with ESMTP id AAW20745 (AUTH gja); Thu, 14 Dec 2000 10:27:47 -0800 (PST) Message-ID: <3A391172.960FDB28@research.bell-labs.com> Date: Thu, 14 Dec 2000 10:29:06 -0800 From: Grenville Armitage Organization: Bell Labs Research Silicon Valley X-Mailer: Mozilla 4.61 [en] (WinNT; U) X-Accept-Language: en MIME-Version: 1.0 To: diffserv@ietf.org Subject: Re: [Diffserv] Yesterday's EF discussion References: <9DC5E2ABE65BD54CA9088DA3194461D6010C9AF9@BBY1EXM01> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: diffserv-admin@ietf.org Errors-To: diffserv-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Diffserv Discussion List X-BeenThere: diffserv@ietf.org Content-Transfer-Encoding: 7bit Shahram Davari wrote: [..] > 3) Implementers already know and have implemented EF and its > rate-based definition and therefore changing the name would > create confusion. This part has always intrigued me - the assertion that people have 'implemented EF'. I'd be willing to believe schedulers were implemented, and the implementors know the operating ranges over which their schedulers can provide a rate-based EF behavior. But to say all these queue/scheduler implementations out there will suffer an identity crisis because the target behavior is more precisely renamed 'Defined Rate'..... unconvincing. cheers, gja _______________________________________________ diffserv mailing list diffserv@ietf.org http://www1.ietf.org/mailman/listinfo/diffserv Archive: http://www2.ietf.org/mail-archive/working-groups/diffserv/current/maillist.html From diffserv-admin@ietf.org Thu Dec 14 14: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 SMTP id OAA19111 for ; Thu, 14 Dec 2000 14:11:25 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id NAA10319; Thu, 14 Dec 2000 13:37:58 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id NAA10288 for ; Thu, 14 Dec 2000 13:37:53 -0500 (EST) Received: from mailserver.terawave.com (mailserver.terawave.com [38.168.8.12] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with SMTP id NAA12950 for ; Thu, 14 Dec 2000 13:37:52 -0500 (EST) Received: from jfletcher-2.terawave.com (JFLETCHER-2 [192.168.2.178]) by mailserver.terawave.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2650.21) id YSL9P2LP; Thu, 14 Dec 2000 10:40:01 -0800 Message-Id: <5.0.1.4.1.20001214103205.00a42530@mail.nwmahlerfestival.org> X-Sender: jfletche@mail.nwmahlerfestival.org (Unverified) X-Mailer: QUALCOMM Windows Eudora Version 5.0.1 Date: Thu, 14 Dec 2000 10:37:00 -0800 To: diffserv@ietf.org From: Justin Fletcher Subject: Re: [Diffserv] Yesterday's EF discussion Cc: brian@hursley.ibm.com Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: diffserv-admin@ietf.org Errors-To: diffserv-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Diffserv Discussion List X-BeenThere: diffserv@ietf.org > Demir, > > You've made your point. I'd like to hear from the silent majority: > do we change the name or not? > > Brian Keep the name. The issue has been what is EF, not the definition of a new behaviour. Justin Fletcher jfletcher@terawave.com _______________________________________________ diffserv mailing list diffserv@ietf.org http://www1.ietf.org/mailman/listinfo/diffserv Archive: http://www2.ietf.org/mail-archive/working-groups/diffserv/current/maillist.html From diffserv-admin@ietf.org Thu Dec 14 14: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 SMTP id OAA19429 for ; Thu, 14 Dec 2000 14:12:51 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id NAA10496; Thu, 14 Dec 2000 13:43:35 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id NAA10465 for ; Thu, 14 Dec 2000 13:43:31 -0500 (EST) Received: from uniwest1.redstonecom.com ([199.105.223.130]) by ietf.org (8.9.1a/8.9.1a) with SMTP id NAA13633 for ; Thu, 14 Dec 2000 13:43:30 -0500 (EST) Received: by uniwest1.redstonecom.com with Internet Mail Service (5.5.2650.21) id ; Thu, 14 Dec 2000 13:42:57 -0500 Message-ID: <49FF5C6DDBD8D311BBBD009027DE980C010C43C2@uniwest1.redstonecom.com> From: "Lemaire, Tom" To: "'Scott Brim'" Cc: "'diffserv@ietf.org'" Subject: RE: [Diffserv] Yesterday's EF discussion Date: Thu, 14 Dec 2000 13:42:56 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: text/plain; charset="iso-8859-1" Sender: diffserv-admin@ietf.org Errors-To: diffserv-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Diffserv Discussion List X-BeenThere: diffserv@ietf.org Well said. I would agree that keeping the name EF is the path of least confusion. Tom Lemaire Unisphere Networks -----Original Message----- From: Scott Brim [mailto:sbrim@cisco.com] Sent: Thursday, December 14, 2000 1:15 PM To: diffserv@ietf.org Subject: RE: [Diffserv] Yesterday's EF discussion I also think that while there may be some confusion for a while, it's much better to keep the name EF. There are multiple interpretations of "EF", but only below a certain threshold of detail. Those who know the differences and would be concerned by them are also those who would not be confused by calling whatever we produce EF. Those who are farther from the issues only know what EF is *for*, which has not changed. They are not concerned about the details, they often would feel uncomfortable when presented with them, and we would have to bother them with those details in order to explain the new name to them. The new name helps those who don't need it and potentially causes us trouble with those who might. ..Scott _______________________________________________ diffserv mailing list diffserv@ietf.org http://www1.ietf.org/mailman/listinfo/diffserv Archive: http://www2.ietf.org/mail-archive/working-groups/diffserv/current/maillist.h tml _______________________________________________ diffserv mailing list diffserv@ietf.org http://www1.ietf.org/mailman/listinfo/diffserv Archive: http://www2.ietf.org/mail-archive/working-groups/diffserv/current/maillist.html From diffserv-admin@ietf.org Thu Dec 14 14:43: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 SMTP id OAA26786 for ; Thu, 14 Dec 2000 14:43:11 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id OAA11019; Thu, 14 Dec 2000 14:06:09 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id OAA10988 for ; Thu, 14 Dec 2000 14:06:05 -0500 (EST) 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 OAA17948 for ; Thu, 14 Dec 2000 14:06:03 -0500 (EST) Received: from scummy.research.bell-labs.com ([135.104.2.10]) by dirty; Thu Dec 14 14:05:19 EST 2000 Received: from mail1.pa.bell-labs.com ([135.250.8.11]) by scummy; Thu Dec 14 14:05:17 EST 2000 Received: from research.bell-labs.com (ex-vpn66.pa.bell-labs.com [135.250.1.66]) by mail1.pa.bell-labs.com (Mirapoint) with ESMTP id AAW20862 (AUTH gja); Thu, 14 Dec 2000 11:05:14 -0800 (PST) Message-ID: <3A391A39.52A49EBE@research.bell-labs.com> Date: Thu, 14 Dec 2000 11:06:33 -0800 From: Grenville Armitage Organization: Bell Labs Research Silicon Valley X-Mailer: Mozilla 4.61 [en] (WinNT; U) X-Accept-Language: en MIME-Version: 1.0 To: "Diffserv@Ietf. Org" Subject: Re: [Diffserv] Yesterday's EF discussion References: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: diffserv-admin@ietf.org Errors-To: diffserv-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Diffserv Discussion List X-BeenThere: diffserv@ietf.org Content-Transfer-Encoding: 7bit Bruce Davie wrote: [..] > A rose by any other name would smell as > sweet, but if you try to sell bunches of sweet-smelling, red frobnitzes on > Valentines day, the market will tell you what's in a name. Charney-compromise will smell as sweet even while the market learns to call it by a more accurate name such as Defined Rate. I fully concur. cheers, gja _______________________________________________ diffserv mailing list diffserv@ietf.org http://www1.ietf.org/mailman/listinfo/diffserv Archive: http://www2.ietf.org/mail-archive/working-groups/diffserv/current/maillist.html From diffserv-admin@ietf.org Thu Dec 14 14:44: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 SMTP id OAA27027 for ; Thu, 14 Dec 2000 14:44:17 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id OAA11123; Thu, 14 Dec 2000 14:10:24 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id OAA11090 for ; Thu, 14 Dec 2000 14:10:20 -0500 (EST) Received: from packetbdc.packettech.com (packetbdc.riverdelta.com [198.112.190.11]) by ietf.org (8.9.1a/8.9.1a) with SMTP id OAA18873 for ; Thu, 14 Dec 2000 14:10:18 -0500 (EST) Received: by packetbdc.riverdelta.com with Internet Mail Service (5.5.2650.21) id ; Thu, 14 Dec 2000 14:11:42 -0500 Message-ID: <7F4AC78738EAD2119D86009027626C6D889025@packetbdc.riverdelta.com> From: Jon Bennett To: "'Brian E Carpenter'" , diffserv@ietf.org Subject: RE: [Diffserv] Yesterday's EF discussion Date: Thu, 14 Dec 2000 14:11:41 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: text/plain; charset="iso-8859-1" Sender: diffserv-admin@ietf.org Errors-To: diffserv-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Diffserv Discussion List X-BeenThere: diffserv@ietf.org Brian > What should the name of the PHB be? > Chair's proposal: Defined Rate (DR). I believe that > after this long and confusing discussion, it would be wise > to retire the previous name. If we had wanted to retire the name, then we would have just proposed a new PHB, and but we were not, we were clarifying the EF PHB, and the those in the room agreed with our clarification. It is clear that what was being discussed was what to do with EF, our assertion all along has been that what we wrote in draft-charny is what 2598 'says' regardless of what Van 'meant' to say. And that what it 'says' has been implemented by a lot of people already. To suggest that draft-charny should do anything other that obsolete RFC 2598 and be advanced as the EF PHB would be to suggest that it is in fact not the same as PHB. This would suggest that we had defined a new PHB, which would a) as you your self have pointed out be in violation of the WG charter and so is clearly not an option. b) leave the would outside thinking that there are two different PHB's EF and some new PHB. In addition you asked asked us on the list what our intentions for the draft were and were told that it was to obsolete 2598, and the EFRESOLVE draft states that it is proposed as a replacement for RFC 2598 and I quote; " An 'EF design team' was formed after the Pittsburgh IETF meeting to synthesize a new expression of the EF PHB. This Internet Draft captures our feedback to the DiffServ WG on a proposed revision to the EF PHB definition. A formal revision to RFC 2598 will be derived from this document." draft-charny had the same purpose, to be the basis for a formal revision of the EF PHB, the room was vastly in favor of our revision of EF, the room was also vastly opposed to two PHBs, I submit that leaving RFC 2598 unchanged as the EF PHB and introducing draft-charny as the FOO PHB besides violating the WG charter is simply to ignore the consensus of the room. I see no basis for this suggested approach and am fully opposed to it. _______________________________________________ diffserv mailing list diffserv@ietf.org http://www1.ietf.org/mailman/listinfo/diffserv Archive: http://www2.ietf.org/mail-archive/working-groups/diffserv/current/maillist.html From diffserv-admin@ietf.org Thu Dec 14 15:00: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 SMTP id PAA01167 for ; Thu, 14 Dec 2000 15:00:04 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id OAA11306; Thu, 14 Dec 2000 14:18:10 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id OAA11276 for ; Thu, 14 Dec 2000 14:18:06 -0500 (EST) Received: from pender.ee.upenn.edu (root@PENDER.EE.UPENN.EDU [158.130.64.183]) by ietf.org (8.9.1a/8.9.1a) with SMTP id OAA20986 for ; Thu, 14 Dec 2000 14:18:05 -0500 (EST) Received: from ee.upenn.edu (GUERIN.CIS.UPENN.EDU [158.130.12.253]) by pender.ee.upenn.edu (8.9.3/8.9.3) with ESMTP id OAA04318; Thu, 14 Dec 2000 14:18:05 -0500 (EST) Message-ID: <3A391CED.18A1CA6C@ee.upenn.edu> Date: Thu, 14 Dec 2000 14:18:05 -0500 From: Roch Guerin Organization: University of Pennsylvania X-Mailer: Mozilla 4.76 [en] (X11; U; Linux 2.2.16-3 i686) X-Accept-Language: en MIME-Version: 1.0 To: "Diffserv@Ietf. Org" CC: Bruce Davie Subject: Re: [Diffserv] Yesterday's EF discussion References: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: diffserv-admin@ietf.org Errors-To: diffserv-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Diffserv Discussion List X-BeenThere: diffserv@ietf.org Content-Transfer-Encoding: 7bit I'd also vote for keeping the name, and wont add to the several compelling arguments that have been made in favor of such a choice. Roch _______________________________________________ diffserv mailing list diffserv@ietf.org http://www1.ietf.org/mailman/listinfo/diffserv Archive: http://www2.ietf.org/mail-archive/working-groups/diffserv/current/maillist.html From diffserv-admin@ietf.org Thu Dec 14 15:00:08 2000 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with SMTP id PAA01186 for ; Thu, 14 Dec 2000 15:00:08 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id OAA11370; Thu, 14 Dec 2000 14:20:01 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id OAA11335 for ; Thu, 14 Dec 2000 14:19:57 -0500 (EST) Received: from mako1.telstra.net (mako1.telstra.net [203.50.0.28]) by ietf.org (8.9.1a/8.9.1a) with SMTP id OAA21381 for ; Thu, 14 Dec 2000 14:19:54 -0500 (EST) Received: from tecra.telstra.net (ietf.207.137.75.21.tx.verio.net [207.137.75.21]) by mako1.telstra.net (8.9.2/8.9.2) with ESMTP id GAA19376; Fri, 15 Dec 2000 06:19:19 +1100 (EST) (envelope-from gih@telstra.net) Message-Id: <4.3.2.7.2.20001215061513.00aadce0@localhost> X-Sender: gih@localhost X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Fri, 15 Dec 2000 06:18:25 +1100 To: Brian E Carpenter From: Geoff Huston Subject: Re: [Diffserv] Yesterday's EF discussion Cc: In-Reply-To: <3A3903FC.69621E7D@hursley.ibm.com> References: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: diffserv-admin@ietf.org Errors-To: diffserv-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Diffserv Discussion List X-BeenThere: diffserv@ietf.org At 12/14/00 11:31 AM -0600, Brian E Carpenter wrote: >Demir, > >You've made your point. I'd like to hear from the silent majority: >do we change the name or not? I'd suggest that while 'EF' may have a certain meaning to many here on this list, to many others its still 'expedited forwarding', which as a pair of words is not the full story with this intended service. You want to hear from those who have been observers so far? ok - I believe it would be appropriate to change the name! thanks, Geoff _______________________________________________ diffserv mailing list diffserv@ietf.org http://www1.ietf.org/mailman/listinfo/diffserv Archive: http://www2.ietf.org/mail-archive/working-groups/diffserv/current/maillist.html From diffserv-admin@ietf.org Thu Dec 14 15:22:36 2000 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with SMTP id PAA05434 for ; Thu, 14 Dec 2000 15:22:36 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id OAA11942; Thu, 14 Dec 2000 14:49:07 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id OAA11911 for ; Thu, 14 Dec 2000 14:49:03 -0500 (EST) Received: from crufty.research.bell-labs.com (crufty.research.bell-labs.com [204.178.16.49]) by ietf.org (8.9.1a/8.9.1a) with SMTP id OAA28122 for ; Thu, 14 Dec 2000 14:49:01 -0500 (EST) Received: from scummy.research.bell-labs.com ([135.104.2.10]) by crufty; Thu Dec 14 14:47:19 EST 2000 Received: from mail1.pa.bell-labs.com ([135.250.8.11]) by scummy; Thu Dec 14 14:48:20 EST 2000 Received: from research.bell-labs.com (ex-vpn66.pa.bell-labs.com [135.250.1.66]) by mail1.pa.bell-labs.com (Mirapoint) with ESMTP id AAW20953 (AUTH gja); Thu, 14 Dec 2000 11:48:17 -0800 (PST) Message-ID: <3A392450.E8F3230D@research.bell-labs.com> Date: Thu, 14 Dec 2000 11:49:36 -0800 From: Grenville Armitage Organization: Bell Labs Research Silicon Valley X-Mailer: Mozilla 4.61 [en] (WinNT; U) X-Accept-Language: en MIME-Version: 1.0 To: Jon Bennett CC: "'Brian E Carpenter'" , diffserv@ietf.org Subject: Re: [Diffserv] Yesterday's EF discussion References: <7F4AC78738EAD2119D86009027626C6D889025@packetbdc.riverdelta.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: diffserv-admin@ietf.org Errors-To: diffserv-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Diffserv Discussion List X-BeenThere: diffserv@ietf.org Content-Transfer-Encoding: 7bit Jon Bennett wrote: [..] > the room was > also vastly opposed to two PHBs, This is so stunningly different to my recollection as to leave me wondering what rooms we were in. Standing quietly at the rear room, I saw (with my own two beady little eyes) the question of "can the WG accept two PHBs" receive more 'yes' than 'no'. (The crowd was certainly with charny-compromise on the different, and more specific question of which text to use *if* there was to be only one PHB. But that *is* a different question.) cheers, gja _______________________________________________ diffserv mailing list diffserv@ietf.org http://www1.ietf.org/mailman/listinfo/diffserv Archive: http://www2.ietf.org/mail-archive/working-groups/diffserv/current/maillist.html From diffserv-admin@ietf.org Thu Dec 14 15:29: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 SMTP id PAA07436 for ; Thu, 14 Dec 2000 15:29:05 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id OAA12195; Thu, 14 Dec 2000 14:58:18 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id OAA12096 for ; Thu, 14 Dec 2000 14:58:11 -0500 (EST) Received: from diablo.cisco.com (diablo.cisco.com [171.68.224.210]) by ietf.org (8.9.1a/8.9.1a) with SMTP id OAA00925 for ; Thu, 14 Dec 2000 14:58:09 -0500 (EST) Received: from jschnizl1-pc (ssh-sj1.cisco.com [171.68.225.134]) by diablo.cisco.com (8.8.6 (PHNE_14041)/CISCO.SERVER.1.2) with SMTP id LAA29580; Thu, 14 Dec 2000 11:57:38 -0800 (PST) Message-Id: <4.1.20001214145159.00b86ca0@diablo.cisco.com> X-Sender: jschnizl@localhost X-Mailer: QUALCOMM Windows Eudora Pro Version 4.1 Date: Thu, 14 Dec 2000 14:56:17 -0500 To: Jon Bennett , diffserv@ietf.org From: John Schnizlein Subject: RE: [Diffserv] Yesterday's EF discussion In-Reply-To: <7F4AC78738EAD2119D86009027626C6D889025@packetbdc.riverdelt a.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 02:11 PM 12/14/2000 -0500, Jon Bennett wrote: >... our assertion all along has been that what we wrote in >draft-charny is what 2598 'says' regardless of what Van 'meant' >to say. >And that what it 'says' has been implemented by a lot of people >already. Could you provide some details about who has "implemented" EF? What exactly do you mean by "implemented"? John _______________________________________________ diffserv mailing list diffserv@ietf.org http://www1.ietf.org/mailman/listinfo/diffserv Archive: http://www2.ietf.org/mail-archive/working-groups/diffserv/current/maillist.html From diffserv-admin@ietf.org Thu Dec 14 16:28: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 SMTP id QAA22359 for ; Thu, 14 Dec 2000 16:28:20 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id PAA13286; Thu, 14 Dec 2000 15:56:20 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id PAA13255 for ; Thu, 14 Dec 2000 15:56:15 -0500 (EST) Received: from mailsrv.acc.com (mailsrv.acc.com [129.192.64.128]) by ietf.org (8.9.1a/8.9.1a) with SMTP id PAA14112 for ; Thu, 14 Dec 2000 15:56:12 -0500 (EST) Received: from antbird (devdhcp6293.dev.acc.am.ericsson.se [129.192.62.93]) by mailsrv.acc.com (8.9.3/8.9.1) with SMTP id MAA20879 for ; Thu, 14 Dec 2000 12:55:52 -0800 (PST) Message-Id: <3.0.1.32.20001214125613.00aa2610@mail.acc.com> X-Sender: layres@mail.acc.com X-Mailer: Windows Eudora Pro Version 3.0.1 (32) Date: Thu, 14 Dec 2000 12:56:13 -0800 To: diffserv@ietf.org From: Larry Ayres Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Subject: [Diffserv] A revised expression of the Expedited Forwarding PHB Sender: diffserv-admin@ietf.org Errors-To: diffserv-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Diffserv Discussion List X-BeenThere: diffserv@ietf.org It seems to me that the first sentence on page 3 which reads: If more EF traffic arrives than is acceptable, the device is NOT REQUIRED to deliver the EF behavior. is meant to convey: If more EF traffic arrives than is acceptable, the device is NOT REQUIRED to deliver the EF behavior to the excess traffic. Am I right in this interpretation ? regards, _______________________________________________ diffserv mailing list diffserv@ietf.org http://www1.ietf.org/mailman/listinfo/diffserv Archive: http://www2.ietf.org/mail-archive/working-groups/diffserv/current/maillist.html From diffserv-admin@ietf.org Thu Dec 14 16:29:08 2000 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with SMTP id QAA22612 for ; Thu, 14 Dec 2000 16:29:07 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id PAA13137; Thu, 14 Dec 2000 15:47:21 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id PAA13107 for ; Thu, 14 Dec 2000 15:47:16 -0500 (EST) Received: from web4206.mail.yahoo.com (web4206.mail.yahoo.com [216.115.104.139]) by ietf.org (8.9.1a/8.9.1a) with SMTP id PAA12152 for ; Thu, 14 Dec 2000 15:47:14 -0500 (EST) From: g_mercankosk@yahoo.com Message-ID: <20001214204715.2430.qmail@web4206.mail.yahoo.com> Received: from [207.137.70.66] by web4206.mail.yahoo.com; Thu, 14 Dec 2000 12:47:15 PST Date: Thu, 14 Dec 2000 12:47:15 -0800 (PST) Subject: Re: [Diffserv] Yesterday's EF discussion To: brian@hursley.ibm.com, diffserv@ietf.org Cc: guven@ee.uwa.edu.au MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Sender: diffserv-admin@ietf.org Errors-To: diffserv-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Diffserv Discussion List X-BeenThere: diffserv@ietf.org Brian, > You've made your point. I'd like to hear from the > silent majority: > do we change the name or not? The authors of the original document clearly state that their intention of EF was accurately captured in the EF RESOLVE team version. On the other hand, Charny et al claim that the majority of the people in the industry understood something DIFFERENT. The consensus has been reached that the people wanted to go along with this DIFFERENT understanding. If they were the SAME, we would not be having this argument. Now keeping the name tells the original authors, "No, no, your intention was DIFFERENT!" I think, common sense tells that this has not been the consensus. Accordingly, I find your suggestion of name change quite appropriate. Guven. __________________________________________________ Do You Yahoo!? Yahoo! Shopping - Thousands of Stores. Millions of Products. http://shopping.yahoo.com/ _______________________________________________ diffserv mailing list diffserv@ietf.org http://www1.ietf.org/mailman/listinfo/diffserv Archive: http://www2.ietf.org/mail-archive/working-groups/diffserv/current/maillist.html From diffserv-admin@ietf.org Thu Dec 14 16:35:08 2000 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with SMTP id QAA24468 for ; Thu, 14 Dec 2000 16:35:06 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id QAA13707; Thu, 14 Dec 2000 16:13:02 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id QAA13676 for ; Thu, 14 Dec 2000 16:12:58 -0500 (EST) Received: from exchsrv1.cosinecom.com (mail.cosinecom.com [63.88.104.16]) by ietf.org (8.9.1a/8.9.1a) with SMTP id QAA17967 for ; Thu, 14 Dec 2000 16:12:55 -0500 (EST) Received: by exchsrv1.cosinecom.com with Internet Mail Service (5.5.2650.21) id ; Thu, 14 Dec 2000 13:10:33 -0800 Message-ID: <7EB7C6B62C4FD41196A80090279A2911D8AB24@exchsrv1.cosinecom.com> From: Jay Wang To: "'Brian E Carpenter'" , diffserv@ietf.org Date: Thu, 14 Dec 2000 13:10:27 -0800 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C06612.48840530" Subject: [Diffserv] Dropping Strategy in AF PHB Sender: diffserv-admin@ietf.org Errors-To: diffserv-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Diffserv Discussion List X-BeenThere: diffserv@ietf.org 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_01C06612.48840530 Content-Type: text/plain; charset="iso-8859-1" Lots of efforts have been spent to EF, but little attention is paid to AF. I have a specific question regarding AF as per RFC 2597, in which (Section 4) a statement was made: "The dropping algorithm MUST be insensitive to the short-term traffic characteristics of the micro flows using AF class. That is, flows with different short-term burst but identical longer-term packets rates should have packets discarded with essentially equal probability." For one thing, I don't know why the authors of the RFC wanted to mandate this. It seems logical and OK to me that we drop packets of a very bursty flow more than one that is "smooth" even though the long term average rate are the same between the two. Consider two flows both with a long term average rate r. Yet one comes in as a CBR and the other has an on-off pattern which toggles between rates 0 and R, where R>>r. The rate R can be so large that not only I want to drop it (since I consider it as a ill-behaving to keep it from depleting system resources while the flow is on), but I may in fact have no choice but drop packets simply due to limited buffer space for that PHB. What are your thoughts? - Jay ------_=_NextPart_001_01C06612.48840530 Content-Type: text/html; charset="iso-8859-1" Dropping Strategy in AF PHB

Lots of efforts have been spent to EF, but little attention
is paid to AF.  I have a specific question regarding AF
as per RFC 2597, in which (Section 4) a statement was made:

"The dropping algorithm MUST be insensitive to the short-term
traffic characteristics of the micro flows using AF class.
That is, flows with different short-term burst but identical
longer-term packets rates should have packets discarded with
essentially equal probability."


For one thing, I don't know why the authors of the RFC wanted
to mandate this. It seems logical and OK to me that we drop
packets of a very bursty flow more than one that is "smooth"
even though the long term average rate are the same between the
two. Consider two flows both with a long term average rate r.
Yet one comes in as a CBR and the other has an on-off pattern
which toggles between rates 0 and R, where R>>r.  The rate R can
be so large that not only I want to drop it (since I consider
it as a ill-behaving to keep it from depleting system resources
while the flow is on), but I may in fact have no choice but drop
packets simply due to limited buffer space for that PHB.

What are your thoughts?

- Jay

------_=_NextPart_001_01C06612.48840530-- _______________________________________________ diffserv mailing list diffserv@ietf.org http://www1.ietf.org/mailman/listinfo/diffserv Archive: http://www2.ietf.org/mail-archive/working-groups/diffserv/current/maillist.html From diffserv-admin@ietf.org Thu Dec 14 16:55: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 SMTP id QAA27942 for ; Thu, 14 Dec 2000 16:55:03 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id QAA13891; Thu, 14 Dec 2000 16:21:32 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id QAA13859 for ; Thu, 14 Dec 2000 16:21:28 -0500 (EST) Received: from lohi.eng.telia.fi (lohi.eng.telia.fi [195.10.149.18]) by ietf.org (8.9.1a/8.9.1a) with SMTP id QAA20121 for ; Thu, 14 Dec 2000 16:21:25 -0500 (EST) Received: (from jh@localhost) by lohi.eng.telia.fi (8.11.1/8.11.1/Debian 8.11.0-6) id eBELLNh19973; Thu, 14 Dec 2000 23:21:23 +0200 From: Juha Heinanen MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <14905.14803.287064.154318@lohi.eng.telia.fi> Date: Thu, 14 Dec 2000 23:21:23 +0200 (EET) To: John Schnizlein Cc: Jon Bennett , diffserv@ietf.org Subject: RE: [Diffserv] Yesterday's EF discussion In-Reply-To: <4.1.20001214145159.00b86ca0@diablo.cisco.com> References: <7F4AC78738EAD2119D86009027626C6D889025@packetbdc.riverdelt a.com> <4.1.20001214145159.00b86ca0@diablo.cisco.com> X-Mailer: VM 6.75 under Emacs 19.34.1 Content-Transfer-Encoding: 7bit Sender: diffserv-admin@ietf.org Errors-To: diffserv-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Diffserv Discussion List X-BeenThere: diffserv@ietf.org Content-Transfer-Encoding: 7bit John Schnizlein writes: > Could you provide some details about who has "implemented" EF? > > What exactly do you mean by "implemented"? i would also be interested in hearing this, since the most common routers on the market that i have played with simply allow me to define various queueing and dropping policies and then map packets with any selected diffserv codepoints to those queues. -- juha _______________________________________________ diffserv mailing list diffserv@ietf.org http://www1.ietf.org/mailman/listinfo/diffserv Archive: http://www2.ietf.org/mail-archive/working-groups/diffserv/current/maillist.html From diffserv-admin@ietf.org Thu Dec 14 17:05: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 SMTP id RAA29266 for ; Thu, 14 Dec 2000 17:05:49 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id QAA14351; Thu, 14 Dec 2000 16:41:03 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id QAA14316 for ; Thu, 14 Dec 2000 16:40:59 -0500 (EST) Received: from diablo.cisco.com (diablo.cisco.com [171.68.224.210]) by ietf.org (8.9.1a/8.9.1a) with SMTP id QAA26082 for ; Thu, 14 Dec 2000 16:40:58 -0500 (EST) Received: from jschnizl1-pc (ssh-sj1.cisco.com [171.68.225.134]) by diablo.cisco.com (8.8.6 (PHNE_14041)/CISCO.SERVER.1.2) with SMTP id NAA25529; Thu, 14 Dec 2000 13:39:53 -0800 (PST) Message-Id: <4.1.20001214163942.00a15b80@diablo.cisco.com> X-Sender: jschnizl@localhost X-Mailer: QUALCOMM Windows Eudora Pro Version 4.1 Date: Thu, 14 Dec 2000 16:40:03 -0500 To: Larry Ayres , diffserv@ietf.org From: John Schnizlein Subject: Re: [Diffserv] A revised expression of the Expedited Forwarding PHB In-Reply-To: <3.0.1.32.20001214125613.00aa2610@mail.acc.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 12:56 PM 12/14/2000 -0800, Larry Ayres wrote: >It seems to me that the first sentence on page 3 which reads: > >If more EF traffic arrives than is acceptable, the device is NOT REQUIRED >to deliver the EF behavior. > >is meant to convey: > >If more EF traffic arrives than is acceptable, the device is NOT REQUIRED >to deliver the EF behavior to the excess traffic. > >Am I right in this interpretation ? Yes. _______________________________________________ diffserv mailing list diffserv@ietf.org http://www1.ietf.org/mailman/listinfo/diffserv Archive: http://www2.ietf.org/mail-archive/working-groups/diffserv/current/maillist.html From diffserv-admin@ietf.org Thu Dec 14 17:27: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 SMTP id RAA02275 for ; Thu, 14 Dec 2000 17:27:11 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id QAA14605; Thu, 14 Dec 2000 16:53:48 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id QAA14582 for ; Thu, 14 Dec 2000 16:53:44 -0500 (EST) Received: from mailhub1.almaden.ibm.com (mailhub1.almaden.ibm.com [198.4.83.44]) by ietf.org (8.9.1a/8.9.1a) with SMTP id QAA27772 for ; Thu, 14 Dec 2000 16:53:43 -0500 (EST) Received: from maui.almaden.ibm.com (maui.almaden.ibm.com [9.1.24.92]) by mailhub1.almaden.ibm.com (8.8.8/8.8.8) with ESMTP id NAA37378; Thu, 14 Dec 2000 13:49:58 -0800 Received: from hursley.ibm.com (gsine01.us.sine.ibm.com [9.14.6.41]) by maui.almaden.ibm.com (AIX4.3/8.9.3/8.7) with ESMTP id NAA20848; Thu, 14 Dec 2000 13:53:11 -0800 Message-ID: <3A3940EC.64FFCAEE@hursley.ibm.com> Date: Thu, 14 Dec 2000 15:51:40 -0600 From: Brian E Carpenter Organization: IBM X-Mailer: Mozilla 4.61 [en] (Win98; I) X-Accept-Language: en,fr MIME-Version: 1.0 To: Jon Bennett CC: diffserv@ietf.org Subject: Re: [Diffserv] Yesterday's EF discussion References: <7F4AC78738EAD2119D86009027626C6D889025@packetbdc.riverdelta.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: diffserv-admin@ietf.org Errors-To: diffserv-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Diffserv Discussion List X-BeenThere: diffserv@ietf.org Content-Transfer-Encoding: 7bit Jon, just an (obvious) point of clarification: RFC 2598 will not go away - it will stay there for ever, presumably marked in the index as (Obsoleted by RFCxxxx). Your preference for not changing the name is noted. Brian Jon Bennett wrote: > > Brian > > > What should the name of the PHB be? > > Chair's proposal: Defined Rate (DR). I believe that > > after this long and confusing discussion, it would be wise > > to retire the previous name. > > If we had wanted to retire the name, then we would have just proposed a new > PHB, and but we were not, we were clarifying the EF PHB, and the those in > the room agreed with our clarification. It is clear that what was being > discussed was what to do with EF, our assertion all along has been that what > we wrote in draft-charny is what 2598 'says' regardless of what Van 'meant' > to say. And that what it 'says' has been implemented by a lot of people > already. To suggest that draft-charny should do anything other that obsolete > RFC 2598 and be advanced as the EF PHB would be to suggest that it is in > fact not the same as PHB. This would suggest that we had defined a new PHB, > which would > > a) as you your self have pointed out be in violation of the WG charter and > so is clearly not an option. > > b) leave the would outside thinking that there are two different PHB's EF > and some new PHB. > > In addition you asked asked us on the list what our intentions for the draft > were and were told that it was to obsolete 2598, and the EFRESOLVE draft > states that it is proposed as a replacement for RFC 2598 and I quote; > > " An 'EF design team' was formed after the > Pittsburgh IETF meeting to synthesize a new expression of the EF PHB. > This Internet Draft captures our feedback to the DiffServ WG on a > proposed revision to the EF PHB definition. > > A formal revision to RFC 2598 will be derived from this document." > > draft-charny had the same purpose, to be the basis for a formal revision of > the EF PHB, the room was vastly in favor of our revision of EF, the room was > also vastly opposed to two PHBs, I submit that leaving RFC 2598 unchanged as > the EF PHB and introducing draft-charny as the FOO PHB besides violating the > WG charter is simply to ignore the consensus of the room. I see no basis for > this suggested approach and am fully opposed to it. _______________________________________________ diffserv mailing list diffserv@ietf.org http://www1.ietf.org/mailman/listinfo/diffserv Archive: http://www2.ietf.org/mail-archive/working-groups/diffserv/current/maillist.html From diffserv-admin@ietf.org Thu Dec 14 17:39: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 SMTP id RAA03644 for ; Thu, 14 Dec 2000 17:39:00 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id RAA15046; Thu, 14 Dec 2000 17:03:47 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id RAA15017 for ; Thu, 14 Dec 2000 17:03:43 -0500 (EST) Received: from meter.eng.uci.edu (root@meter.eng.uci.edu [128.200.85.3]) by ietf.org (8.9.1a/8.9.1a) with SMTP id RAA29038 for ; Thu, 14 Dec 2000 17:03:42 -0500 (EST) Received: from ece.uci.edu (vp184015.reshsg.uci.edu [128.195.184.15]) by meter.eng.uci.edu (8.9.3/) with ESMTP id OAA28315; Thu, 14 Dec 2000 14:03:06 -0800 (PST) Message-ID: <3A394640.4112DD@ece.uci.edu> Date: Thu, 14 Dec 2000 14:14:25 -0800 From: Mahadevan Iyer X-Mailer: Mozilla 4.72 [en] (Win98; I) X-Accept-Language: en MIME-Version: 1.0 To: Larry Ayres , diffserv@ietf.org Subject: Re: [Diffserv] A revised expression of the Expedited Forwarding PHB References: <3.0.1.32.20001214125613.00aa2610@mail.acc.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: diffserv-admin@ietf.org Errors-To: diffserv-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Diffserv Discussion List X-BeenThere: diffserv@ietf.org Content-Transfer-Encoding: 7bit Larry Ayres wrote: > It seems to me that the first sentence on page 3 which reads: > > If more EF traffic arrives than is acceptable, the device is NOT REQUIRED > to deliver the EF behavior. > I hope the above sentence is itself not considered as part of the EF behavior definition, because then the definition will become a circular (self-referring) statement! _______________________________________________ diffserv mailing list diffserv@ietf.org http://www1.ietf.org/mailman/listinfo/diffserv Archive: http://www2.ietf.org/mail-archive/working-groups/diffserv/current/maillist.html From diffserv-admin@ietf.org Thu Dec 14 17:39:01 2000 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with SMTP id RAA03655 for ; Thu, 14 Dec 2000 17:39:01 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id RAA15113; Thu, 14 Dec 2000 17:05:25 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id RAA15083 for ; Thu, 14 Dec 2000 17:05:21 -0500 (EST) Received: from zcars04e.ca.nortel.com (h56s242a129n47.user.nortelnetworks.com [47.129.242.56]) by ietf.org (8.9.1a/8.9.1a) with SMTP id RAA29219 for ; Thu, 14 Dec 2000 17:05:20 -0500 (EST) Message-Id: <200012142205.RAA29219@ietf.org> Received: from zcard00m.ca.nortel.com by zcars04e.ca.nortel.com; Thu, 14 Dec 2000 17:04:05 -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.2652.39) id YP1FC5YJ; Thu, 14 Dec 2000 17:03:56 -0500 Received: from zcars02x.ca.nortel.com ([47.23.81.10]) by zcard00f.ca.nortel.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2652.39) id Y6C6L528; Thu, 14 Dec 2000 17:03:48 -0500 Date: Thu, 14 Dec 2000 17:03:38 -0500 (EST) X-Sybari-Space: 00000000 00000000 00000000 From: "Nabil Seddigh" Reply-To: "Nabil Seddigh" Subject: re:[Diffserv] Dropping Strategy in AF PHB To: Jay Wang cc: "'Brian E Carpenter'" , diffserv@ietf.org X-Mailer: Rosa 2.1 SunOS5.6 X-Rosa-Trace: nseddigh@zcars02x <47.23.81.10> MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-ID: X-Orig: Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by optimus.ietf.org id RAA15085 Sender: diffserv-admin@ietf.org Errors-To: 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 dropping algorithm MUST be insensitive to the short-term >traffic characteristics of the micro flows using AF class. >That is, flows with different short-term burst but identical >longer-term packets rates should have packets discarded with >essentially equal probability." > >For one thing, I don't know why the authors of the RFC wanted >to mandate this. There was certainly a lot of attention paid to AF. If I recall correctly, the intent of the quoted paragraph was to ensure that drop-tail was not used for AF. It essentially mandates an AQM mechanism that takes past history into account when making its drop decisions. I don't think the intent of that paragraph was to require per-micro-flow drop decisions. Best Nabil _______________________________________________ diffserv mailing list diffserv@ietf.org http://www1.ietf.org/mailman/listinfo/diffserv Archive: http://www2.ietf.org/mail-archive/working-groups/diffserv/current/maillist.html From diffserv-admin@ietf.org Thu Dec 14 17:43:31 2000 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with SMTP id RAA04264 for ; Thu, 14 Dec 2000 17:43:31 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id RAA15287; Thu, 14 Dec 2000 17:12:41 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id RAA15256 for ; Thu, 14 Dec 2000 17:12:37 -0500 (EST) Received: from mailhub1.almaden.ibm.com (mailhub1.almaden.ibm.com [198.4.83.44]) by ietf.org (8.9.1a/8.9.1a) with SMTP id RAA00060 for ; Thu, 14 Dec 2000 17:12:35 -0500 (EST) Received: from maui.almaden.ibm.com (maui.almaden.ibm.com [9.1.24.92]) by mailhub1.almaden.ibm.com (8.8.8/8.8.8) with ESMTP id OAA62096; Thu, 14 Dec 2000 14:08:53 -0800 Received: from hursley.ibm.com (gsine01.us.sine.ibm.com [9.14.6.41]) by maui.almaden.ibm.com (AIX4.3/8.9.3/8.7) with ESMTP id OAA20858; Thu, 14 Dec 2000 14:11:58 -0800 Message-ID: <3A394551.90D4C28D@hursley.ibm.com> Date: Thu, 14 Dec 2000 16:10:25 -0600 From: Brian E Carpenter Organization: IBM X-Mailer: Mozilla 4.61 [en] (Win98; I) X-Accept-Language: en,fr MIME-Version: 1.0 To: Nabil Seddigh CC: Jay Wang , diffserv@ietf.org Subject: Re: [Diffserv] Dropping Strategy in AF PHB References: <200012142204.WAA14472@mail-gw1.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 Nabil Seddigh wrote: > > >"The dropping algorithm MUST be insensitive to the short-term > >traffic characteristics of the micro flows using AF class. > >That is, flows with different short-term burst but identical > >longer-term packets rates should have packets discarded with > >essentially equal probability." > > > >For one thing, I don't know why the authors of the RFC wanted > >to mandate this. > > There was certainly a lot of attention paid to AF. > > If I recall correctly, the intent of the quoted paragraph was to ensure > > that drop-tail was not used for AF. It essentially mandates an AQM > mechanism that takes past history into account when making its drop > decisions. I don't think the intent of that paragraph was > to require per-micro-flow drop decisions. I think it was also to avoid trying to redefine RED, which would have been out of place in a diffserv document. Anyway it was a carefully debated paragraph. Brian Brian _______________________________________________ diffserv mailing list diffserv@ietf.org http://www1.ietf.org/mailman/listinfo/diffserv Archive: http://www2.ietf.org/mail-archive/working-groups/diffserv/current/maillist.html From diffserv-admin@ietf.org Thu Dec 14 17:45:08 2000 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with SMTP id RAA04480 for ; Thu, 14 Dec 2000 17:45:08 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id RAA15366; Thu, 14 Dec 2000 17:14:04 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id RAA15334 for ; Thu, 14 Dec 2000 17:14:00 -0500 (EST) 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 RAA00218 for ; Thu, 14 Dec 2000 17:13:59 -0500 (EST) Received: from scummy.research.bell-labs.com ([135.104.2.10]) by dirty; Thu Dec 14 17:12:29 EST 2000 Received: from mail1.pa.bell-labs.com ([135.250.8.11]) by scummy; Thu Dec 14 17:12:28 EST 2000 Received: from research.bell-labs.com (ex-vpn66.pa.bell-labs.com [135.250.1.66]) by mail1.pa.bell-labs.com (Mirapoint) with ESMTP id AAW21260 (AUTH gja); Thu, 14 Dec 2000 14:12:25 -0800 (PST) Message-ID: <3A394611.9592B7CF@research.bell-labs.com> Date: Thu, 14 Dec 2000 14:13:37 -0800 From: Grenville Armitage Organization: Bell Labs Research Silicon Valley X-Mailer: Mozilla 4.61 [en] (WinNT; U) X-Accept-Language: en MIME-Version: 1.0 To: Brian E Carpenter CC: Jon Bennett , diffserv@ietf.org Subject: Re: [Diffserv] Yesterday's EF discussion References: <7F4AC78738EAD2119D86009027626C6D889025@packetbdc.riverdelta.com> <3A392450.E8F3230D@research.bell-labs.com> <3A394186.FE4FF1F5@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 live and learn, i suppose. i saw the votes taken on questions on the slides, and then turned away - perhaps i *was* in a different room by the time of the final iteration ;) cheers, gja Brian E Carpenter wrote: > > Grenville, > > Actually Jon is correct because my final iteration was: would > the WG *prefer* one or two PHBs, which produced a large majority > for only one. > > Brian > > Grenville Armitage wrote: > > > > Jon Bennett wrote: > > [..] > > > the room was > > > also vastly opposed to two PHBs, > > > > This is so stunningly different to my recollection as to leave me > > wondering what rooms we were in. Standing quietly at the rear > > room, I saw (with my own two beady little eyes) the question > > of "can the WG accept two PHBs" receive more 'yes' than 'no'. > > > > (The crowd was certainly with charny-compromise on the different, > > and more specific question of which text to use *if* there was to > > be only one PHB. But that *is* a different question.) > > > > 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://www2.ietf.org/mail-archive/working-groups/diffserv/current/maillist.html From diffserv-admin@ietf.org Thu Dec 14 17:56:28 2000 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with SMTP id RAA03665 for ; Thu, 14 Dec 2000 17:39:02 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id QAA14695; Thu, 14 Dec 2000 16:56:20 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id QAA14664 for ; Thu, 14 Dec 2000 16:56:15 -0500 (EST) Received: from mailhub1.almaden.ibm.com (mailhub1.almaden.ibm.com [198.4.83.44]) by ietf.org (8.9.1a/8.9.1a) with SMTP id QAA28119 for ; Thu, 14 Dec 2000 16:56:14 -0500 (EST) Received: from maui.almaden.ibm.com (maui.almaden.ibm.com [9.1.24.92]) by mailhub1.almaden.ibm.com (8.8.8/8.8.8) with ESMTP id NAA23402; Thu, 14 Dec 2000 13:52:32 -0800 Received: from hursley.ibm.com (gsine01.us.sine.ibm.com [9.14.6.41]) by maui.almaden.ibm.com (AIX4.3/8.9.3/8.7) with ESMTP id NAA22404; Thu, 14 Dec 2000 13:55:45 -0800 Message-ID: <3A394186.FE4FF1F5@hursley.ibm.com> Date: Thu, 14 Dec 2000 15:54:14 -0600 From: Brian E Carpenter Organization: IBM X-Mailer: Mozilla 4.61 [en] (Win98; I) X-Accept-Language: en,fr MIME-Version: 1.0 To: Grenville Armitage CC: Jon Bennett , diffserv@ietf.org Subject: Re: [Diffserv] Yesterday's EF discussion References: <7F4AC78738EAD2119D86009027626C6D889025@packetbdc.riverdelta.com> <3A392450.E8F3230D@research.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, Actually Jon is correct because my final iteration was: would the WG *prefer* one or two PHBs, which produced a large majority for only one. Brian Grenville Armitage wrote: > > Jon Bennett wrote: > [..] > > the room was > > also vastly opposed to two PHBs, > > This is so stunningly different to my recollection as to leave me > wondering what rooms we were in. Standing quietly at the rear > room, I saw (with my own two beady little eyes) the question > of "can the WG accept two PHBs" receive more 'yes' than 'no'. > > (The crowd was certainly with charny-compromise on the different, > and more specific question of which text to use *if* there was to > be only one PHB. But that *is* a different question.) > > cheers, > gja _______________________________________________ diffserv mailing list diffserv@ietf.org http://www1.ietf.org/mailman/listinfo/diffserv Archive: http://www2.ietf.org/mail-archive/working-groups/diffserv/current/maillist.html From diffserv-admin@ietf.org Thu Dec 14 18:02:37 2000 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with SMTP id SAA06783 for ; Thu, 14 Dec 2000 18:02:36 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id RAA15842; Thu, 14 Dec 2000 17:34:20 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id RAA15812 for ; Thu, 14 Dec 2000 17:34:16 -0500 (EST) Received: from dgesmtp02.wcom.com (dgesmtp02.wcom.com [199.249.16.17]) by ietf.org (8.9.1a/8.9.1a) with SMTP id RAA03104 for ; Thu, 14 Dec 2000 17:34:14 -0500 (EST) Received: from CONVERSION-DAEMON by firewall.mcit.com (PMDF V5.2-33 #42261) id <0G5K00L01XCAVP@firewall.mcit.com> for diffserv@ietf.org; Thu, 14 Dec 2000 22:33:46 +0000 (GMT) Received: from pmismtp01.wcomnet.com ([166.38.62.36]) by firewall.mcit.com (PMDF V5.2-33 #42261) with ESMTP id <0G5K00IFRXC999@firewall.mcit.com> for diffserv@ietf.org; Thu, 14 Dec 2000 22:33:46 +0000 (GMT) Received: from CONVERSION-DAEMON by pmismtp01.wcomnet.com (PMDF V5.2-33 #42258) id <0G5K00101XC9WI@pmismtp01.wcomnet.com> for diffserv@ietf.org; Thu, 14 Dec 2000 22:33:45 +0000 (GMT) Received: from pmismtp01.wcomnet.com by pmismtp01.wcomnet.com (PMDF V5.2-33 #42258) with SMTP id <0G5K00101XBYSU@pmismtp01.wcomnet.com> for diffserv@ietf.org; Thu, 14 Dec 2000 22:33:45 +0000 (GMT) Received: from omzexch006.mcit.com ([166.37.194.37]) by pmismtp01.wcomnet.com (PMDF V5.2-33 #42258) with ESMTP id <0G5K0011VXBUA0@pmismtp01.wcomnet.com> for diffserv@ietf.org; Thu, 14 Dec 2000 22:33:30 +0000 (GMT) Received: by omzexch006 with Internet Mail Service (5.5.2651.58) id ; Thu, 14 Dec 2000 22:33:30 +0000 Content-return: allowed Date: Thu, 14 Dec 2000 22:33:28 +0000 From: "Iliff, Tina" Subject: FW: [Diffserv] diffsev-pib-02: qosQSchdParam To: "'diffserv@ietf.org'" Message-id: <492EB4A3F68CD411ABE800508B69362E14B436@RIPEXCH002.wcomnet.com> MIME-version: 1.0 X-Mailer: Internet Mail Service (5.5.2651.58) Content-type: multipart/alternative; boundary="Boundary_(ID_yHdUVKCJauOIjJ+ovpV9lw)" Sender: diffserv-admin@ietf.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. --Boundary_(ID_yHdUVKCJauOIjJ+ovpV9lw) Content-type: text/plain; charset=iso-8859-1 Tina Iliff -----Original Message----- From: Iliff, Tina Sent: Thursday, December 14, 2000 4:30 PM To: 'Kwok-Ho Chan' Subject: RE: [Diffserv] diffsev-pib-02: qosQSchdParam Kwok, Since multiple inter-mixed qosQ and qosScheduler entries can reference the same qosSchdParam entry and the qosQNext value must always be a qosScheduler instance, then I propose just creating one table to include queue attributes, scheduler and scheduling parameters. In this case, the qosAlgDropQMeasure value can be a reference to a QId. I believe this may be a little more efficient and would provide a slight reduction in referencing. Tina Iliff -----Original Message----- From: Kwok-Ho Chan [mailto:khchan@nortelnetworks.com] Sent: Thursday, December 07, 2000 2:55 PM To: Iliff, Tina Cc: Kwok-Ho Chan Subject: RE: [Diffserv] diffsev-pib-02: qosQSchdParam Tina: What do you have in mind when you are thinking of moving the scheduling attributes (priority, min/max rates) into the Q? There are also multi layer schedulers, meaning schedulers also need scheduling attributes (output of a scheduler goes into another scheduler as one of many inputs). This would mean the scheduling attributes will need to exist there too. I would like to understand what you are trying to do better, and would not mind incorporating that into the PIB and MIB if appropriate. Thanks! -- Kwok -- At 09:11 PM 12/6/00 +0000, you wrote: Kwok, I understand the "Fan-In" concept and architecture. However, how about considering this suggestion: add a priority attribute to qosQ, remove the SchdParam attribute and remove the priority attribute from qosSchdParam since priority is a Queue specific "tag" and not Scheduler specific. Tina -----Original Message----- From: Kwok-Ho Chan [mailto:khchan@nortelnetworks.com] Sent: Wednesday, December 06, 2000 1:28 PM To: Iliff, Tina Cc: 'diffserv@ietf.org' Subject: Re: [Diffserv] diffsev-pib-02: qosQSchdParam Tina: Because a scheduler is a "Fan-In" element, many input, single output; the queues that fan-into a scheduler will each need a SchdParam entry to specify its scheduling order with respect to the other queues that feed into the same scheduler. It is also possible to have scheduler feeding into scheduler, hence the SchdParam entry associated with a scheduler entry. Hope this clear things up for you, please let me know. -- Kwok -- At 04:37 PM 12/6/00 +0000, Iliff, Tina wrote: All, I have a concern regarding the structure of the qosQ table. It contains an attribute named SchdParam which provides the parameters used by the scheduler element for this particular queue. My concern is that there is also a SchdParam attribute in the qosScheduler table. It makes more sense to leave the parameter in the qosScheduler table and not in the qosQ table. It seems it is a duplication of information. Tina Iliff --Boundary_(ID_yHdUVKCJauOIjJ+ovpV9lw) Content-type: text/html; charset=iso-8859-1
 
 

Tina Iliff

-----Original Message-----
From: Iliff, Tina
Sent: Thursday, December 14, 2000 4:30 PM
To: 'Kwok-Ho Chan'
Subject: RE: [Diffserv] diffsev-pib-02: qosQSchdParam

Kwok,
 
Since multiple inter-mixed qosQ and qosScheduler entries can reference the same qosSchdParam entry and the qosQNext value must always be a qosScheduler instance, then I propose just creating one table to include queue attributes, scheduler and scheduling parameters.  In this case, the qosAlgDropQMeasure value can be a reference to a QId. 
 
I believe this may be a little more efficient and would provide a slight reduction in referencing.

Tina Iliff

 
-----Original Message-----
From: Kwok-Ho Chan [mailto:khchan@nortelnetworks.com]
Sent: Thursday, December 07, 2000 2:55 PM
To: Iliff, Tina
Cc: Kwok-Ho Chan
Subject: RE: [Diffserv] diffsev-pib-02: qosQSchdParam

Tina:
What do you have in mind when you are thinking of moving the scheduling
attributes (priority, min/max rates) into the Q?
There are also multi layer schedulers, meaning schedulers also need scheduling
attributes (output of a scheduler goes into another scheduler as one of many inputs).
This would mean the scheduling attributes will need to exist there too.
I would like to understand what you are trying to do better, and would not
mind incorporating that into the PIB and MIB if appropriate.
Thanks!
-- Kwok --


At 09:11 PM 12/6/00 +0000, you wrote:
Kwok,
 
I understand the "Fan-In" concept and architecture.  However, how about considering this suggestion:  add a priority attribute to qosQ, remove the SchdParam attribute and remove the priority attribute from qosSchdParam since priority is a Queue specific "tag" and not Scheduler specific.
 
Tina
-----Original Message-----
From: Kwok-Ho Chan [mailto:khchan@nortelnetworks.com]
Sent: Wednesday, December 06, 2000 1:28 PM
To: Iliff, Tina
Cc: 'diffserv@ietf.org'
Subject: Re: [Diffserv] diffsev-pib-02: qosQSchdParam
Tina:
Because a scheduler is a "Fan-In" element, many input, single output;
the queues that fan-into a scheduler will each need a SchdParam entry
to specify its scheduling order with respect to the other queues that feed
into the same scheduler.
It is also possible to have scheduler feeding into scheduler, hence the
SchdParam entry associated with a scheduler entry.
Hope this clear things up for you, please let me know.
-- Kwok --

At 04:37 PM 12/6/00 +0000, Iliff, Tina wrote:

All,

I have a concern regarding the structure of the qosQ table.  It contains an attribute named SchdParam which provides the parameters used by the scheduler element for this particular queue.  My concern is that there is also a SchdParam attribute in the qosScheduler table.  It makes more sense to leave the parameter in the qosScheduler table and not in the qosQ table.  It seems it is a duplication of information.
Tina Iliff

--Boundary_(ID_yHdUVKCJauOIjJ+ovpV9lw)-- _______________________________________________ diffserv mailing list diffserv@ietf.org http://www1.ietf.org/mailman/listinfo/diffserv Archive: http://www2.ietf.org/mail-archive/working-groups/diffserv/current/maillist.html From diffserv-admin@ietf.org Thu Dec 14 18:03: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 SMTP id SAA06886 for ; Thu, 14 Dec 2000 18:03:22 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id RAA15894; Thu, 14 Dec 2000 17:36:21 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id RAA15865 for ; Thu, 14 Dec 2000 17:36:17 -0500 (EST) Received: from mta6.snfc21.pbi.net (mta6.snfc21.pbi.net [206.13.28.240]) by ietf.org (8.9.1a/8.9.1a) with SMTP id RAA03337 for ; Thu, 14 Dec 2000 17:36:16 -0500 (EST) Received: from allegronetworks.com ([206.170.1.8]) by mta6.snfc21.pbi.net (Sun Internet Mail Server sims.3.5.2000.01.05.12.18.p9) with ESMTP id <0G5K0015ZWUCMK@mta6.snfc21.pbi.net> for diffserv@ietf.org; Thu, 14 Dec 2000 14:23:02 -0800 (PST) Date: Thu, 14 Dec 2000 14:31:25 -0800 From: Andrew Smith Subject: Re: [Diffserv] Counters in the classifier To: Robert Moore Cc: diffserv@ietf.org Message-id: <3A394A3D.1010902@allegronetworks.com> Organization: Allegro Networks MIME-version: 1.0 Content-type: text/plain; charset=us-ascii; format=flowed Content-transfer-encoding: 7bit User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; m18) Gecko/20001108 Netscape6/6.0 X-Accept-Language: en References: Content-Transfer-Encoding: 7bit Sender: diffserv-admin@ietf.org Errors-To: diffserv-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Diffserv Discussion List X-BeenThere: diffserv@ietf.org Content-Transfer-Encoding: 7bit Fine with me too. Andrew Robert Moore wrote: > I don't know if my interpretation is correct, but here's > what I *think* Fred is proposing: > > 1. Add a packet counter, but not an octet counter, to each > ClassifierElement in a Classifier. > 2. Retain the Counter action element for counting packets > and/or octets that pass by an arbitrary point in the > data path, such as one of the outputs from a meter. > > If this is in fact Fred's proposal, it's fine with me. > > Regards, > Bob > > Bob Moore > IBM Networking Software > +1-919-254-4436 > remoore@us.ibm.com > > > > Andrew Smith @ietf.org on 12/13/2000 06:54:45 > PM > > Sent by: diffserv-admin@ietf.org > > > To: Fred Baker > cc: Kathleen Nichols , diffserv@ietf.org > Subject: Re: [Diffserv] Counters in the classifier > > > > This does, again, beg the question of having even more overlap with what > the > DSMON MIB (in the RMON WG) does. > > I'm also a bit confused as to whether Fred's proposal *replaces* the > existing > "counter action" material in the MIB or is in addition to it. And is this > addition/change expected to be rolled back into the Model draft also? > > Andrew > > Kathleen Nichols wrote: > > >> Fred Baker wrote: >> .... >> >> >>> So this is my proposal. Kwok and I are editing the MIB this morning, >> > with a > >>> view to this outcome, Andrew's comments, and some comments from Bert >>> relating to TCs (want to pull them together into a separate module and >> > do > >>> some minor tweaks). We will put in a packet counter in the classifier, >> > and > >>> the chairs can tell us we did it wrong. >>> >>> Your comments, please. >>> >> >> >> Fred, I think what you are saying reflects what we talked >> about before Monday's meeting: you have to set up a classifier >> if you want to count (a particular DSCP for example). If >> this is so, I certainly support that and thought we emerged >> from that meeting with out any real case made for anything >> else. >> >> Kathie >> >> _______________________________________________ >> diffserv mailing list >> diffserv@ietf.org >> http://www1.ietf.org/mailman/listinfo/diffserv >> Archive: > > http://www2.ietf.org/mail-archive/working-groups/diffserv/current/maillist.html > > > > _______________________________________________ > diffserv mailing list > diffserv@ietf.org > http://www1.ietf.org/mailman/listinfo/diffserv > Archive: > http://www2.ietf.org/mail-archive/working-groups/diffserv/current/maillist.html > > > > > _______________________________________________ > diffserv mailing list > diffserv@ietf.org > http://www1.ietf.org/mailman/listinfo/diffserv > Archive: http://www2.ietf.org/mail-archive/working-groups/diffserv/current/maillist.html _______________________________________________ diffserv mailing list diffserv@ietf.org http://www1.ietf.org/mailman/listinfo/diffserv Archive: http://www2.ietf.org/mail-archive/working-groups/diffserv/current/maillist.html From diffserv-admin@ietf.org Thu Dec 14 18:06: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 SMTP id SAA07311 for ; Thu, 14 Dec 2000 18:06:41 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id RAA16225; Thu, 14 Dec 2000 17:42:37 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id RAA16195 for ; Thu, 14 Dec 2000 17:42:33 -0500 (EST) Received: from pmesmtp02.wcom.com (pmesmtp02.wcom.com [199.249.20.2]) by ietf.org (8.9.1a/8.9.1a) with SMTP id RAA04123 for ; Thu, 14 Dec 2000 17:42:31 -0500 (EST) Received: from CONVERSION-DAEMON by firewall.mcit.com (PMDF V5.2-32 #42257) id <0G5K00B01XQ3BI@firewall.mcit.com> for diffserv@ietf.org; Thu, 14 Dec 2000 22:42:03 +0000 (GMT) Received: from pmismtp04.wcomnet.com ([166.38.62.39]) by firewall.mcit.com (PMDF V5.2-32 #42257) with ESMTP id <0G5K00A5BXQ3GV@firewall.mcit.com>; Thu, 14 Dec 2000 22:42:03 +0000 (GMT) Received: from CONVERSION-DAEMON by pmismtp04.wcomnet.com (PMDF V5.2-33 #42258) id <0G5K00F01XQ088@pmismtp04.wcomnet.com>; Thu, 14 Dec 2000 22:42:00 +0000 (GMT) Received: from pmismtp04.wcomnet.com by pmismtp04.wcomnet.com (PMDF V5.2-33 #42258) with SMTP id <0G5K00E01XNRIK@pmismtp04.wcomnet.com>; Thu, 14 Dec 2000 22:41:58 +0000 (GMT) Received: from omzexch007.mcit.com ([166.37.194.38]) by pmismtp04.wcomnet.com (PMDF V5.2-33 #42258) with ESMTP id <0G5K00D3BXN5U7@pmismtp04.wcomnet.com>; Thu, 14 Dec 2000 22:40:18 +0000 (GMT) Received: by omzexch007 with Internet Mail Service (5.5.2651.58) id ; Thu, 14 Dec 2000 22:40:17 +0000 Content-return: allowed Date: Thu, 14 Dec 2000 22:40:15 +0000 From: "Iliff, Tina" Subject: RE: [Diffserv] diffsev-pib-02: qosQSchdParam To: "'Kwok-Ho Chan'" Cc: "'diffserv@ietf.org'" Message-id: <492EB4A3F68CD411ABE800508B69362E14B437@RIPEXCH002.wcomnet.com> MIME-version: 1.0 X-Mailer: Internet Mail Service (5.5.2651.58) Content-type: multipart/alternative; boundary="Boundary_(ID_B+Gc/Wl9PirEgoX90DYF2g)" Sender: diffserv-admin@ietf.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. --Boundary_(ID_B+Gc/Wl9PirEgoX90DYF2g) Content-type: text/plain; charset=ISO-8859-1 But that still leaves the issue of a Scheduler following a Scheduler...the queue attributes would not be needed in this case....unless it is specified that the queue attributes can have a NULL value Tina Iliff -----Original Message----- From: Iliff, Tina Sent: Thursday, December 14, 2000 4:30 PM To: 'Kwok-Ho Chan' Subject: RE: [Diffserv] diffsev-pib-02: qosQSchdParam Kwok, Since multiple inter-mixed qosQ and qosScheduler entries can reference the same qosSchdParam entry and the qosQNext value must always be a qosScheduler instance, then I propose just creating one table to include queue attributes, scheduler and scheduling parameters. In this case, the qosAlgDropQMeasure value can be a reference to a QId. I believe this may be a little more efficient and would provide a slight reduction in referencing. Tina Iliff -----Original Message----- From: Kwok-Ho Chan [mailto:khchan@nortelnetworks.com] Sent: Thursday, December 07, 2000 2:55 PM To: Iliff, Tina Cc: Kwok-Ho Chan Subject: RE: [Diffserv] diffsev-pib-02: qosQSchdParam Tina: What do you have in mind when you are thinking of moving the scheduling attributes (priority, min/max rates) into the Q? There are also multi layer schedulers, meaning schedulers also need scheduling attributes (output of a scheduler goes into another scheduler as one of many inputs). This would mean the scheduling attributes will need to exist there too. I would like to understand what you are trying to do better, and would not mind incorporating that into the PIB and MIB if appropriate. Thanks! -- Kwok -- At 09:11 PM 12/6/00 +0000, you wrote: Kwok, I understand the "Fan-In" concept and architecture. However, how about considering this suggestion: add a priority attribute to qosQ, remove the SchdParam attribute and remove the priority attribute from qosSchdParam since priority is a Queue specific "tag" and not Scheduler specific. Tina -----Original Message----- From: Kwok-Ho Chan [mailto:khchan@nortelnetworks.com] Sent: Wednesday, December 06, 2000 1:28 PM To: Iliff, Tina Cc: 'diffserv@ietf.org' Subject: Re: [Diffserv] diffsev-pib-02: qosQSchdParam Tina: Because a scheduler is a "Fan-In" element, many input, single output; the queues that fan-into a scheduler will each need a SchdParam entry to specify its scheduling order with respect to the other queues that feed into the same scheduler. It is also possible to have scheduler feeding into scheduler, hence the SchdParam entry associated with a scheduler entry. Hope this clear things up for you, please let me know. -- Kwok -- At 04:37 PM 12/6/00 +0000, Iliff, Tina wrote: All, I have a concern regarding the structure of the qosQ table. It contains an attribute named SchdParam which provides the parameters used by the scheduler element for this particular queue. My concern is that there is also a SchdParam attribute in the qosScheduler table. It makes more sense to leave the parameter in the qosScheduler table and not in the qosQ table. It seems it is a duplication of information. Tina Iliff --Boundary_(ID_B+Gc/Wl9PirEgoX90DYF2g) Content-type: text/html; charset=ISO-8859-1
But that still leaves the issue of a Scheduler following a Scheduler...the queue attributes would not be needed in this case....unless it is specified that the queue attributes can have a NULL value

Tina Iliff

-----Original Message-----
From: Iliff, Tina
Sent: Thursday, December 14, 2000 4:30 PM
To: 'Kwok-Ho Chan'
Subject: RE: [Diffserv] diffsev-pib-02: qosQSchdParam

Kwok,
 
Since multiple inter-mixed qosQ and qosScheduler entries can reference the same qosSchdParam entry and the qosQNext value must always be a qosScheduler instance, then I propose just creating one table to include queue attributes, scheduler and scheduling parameters.  In this case, the qosAlgDropQMeasure value can be a reference to a QId. 
 
I believe this may be a little more efficient and would provide a slight reduction in referencing.

Tina Iliff

 
-----Original Message-----
From: Kwok-Ho Chan [mailto:khchan@nortelnetworks.com]
Sent: Thursday, December 07, 2000 2:55 PM
To: Iliff, Tina
Cc: Kwok-Ho Chan
Subject: RE: [Diffserv] diffsev-pib-02: qosQSchdParam

Tina:
What do you have in mind when you are thinking of moving the scheduling
attributes (priority, min/max rates) into the Q?
There are also multi layer schedulers, meaning schedulers also need scheduling
attributes (output of a scheduler goes into another scheduler as one of many inputs).
This would mean the scheduling attributes will need to exist there too.
I would like to understand what you are trying to do better, and would not
mind incorporating that into the PIB and MIB if appropriate.
Thanks!
-- Kwok --


At 09:11 PM 12/6/00 +0000, you wrote:
Kwok,
 
I understand the "Fan-In" concept and architecture.  However, how about considering this suggestion:  add a priority attribute to qosQ, remove the SchdParam attribute and remove the priority attribute from qosSchdParam since priority is a Queue specific "tag" and not Scheduler specific.
 
Tina
-----Original Message-----
From: Kwok-Ho Chan [mailto:khchan@nortelnetworks.com]
Sent: Wednesday, December 06, 2000 1:28 PM
To: Iliff, Tina
Cc: 'diffserv@ietf.org'
Subject: Re: [Diffserv] diffsev-pib-02: qosQSchdParam
Tina:
Because a scheduler is a "Fan-In" element, many input, single output;
the queues that fan-into a scheduler will each need a SchdParam entry
to specify its scheduling order with respect to the other queues that feed
into the same scheduler.
It is also possible to have scheduler feeding into scheduler, hence the
SchdParam entry associated with a scheduler entry.
Hope this clear things up for you, please let me know.
-- Kwok --

At 04:37 PM 12/6/00 +0000, Iliff, Tina wrote:

All,

I have a concern regarding the structure of the qosQ table.  It contains an attribute named SchdParam which provides the parameters used by the scheduler element for this particular queue.  My concern is that there is also a SchdParam attribute in the qosScheduler table.  It makes more sense to leave the parameter in the qosScheduler table and not in the qosQ table.  It seems it is a duplication of information.
Tina Iliff

--Boundary_(ID_B+Gc/Wl9PirEgoX90DYF2g)-- _______________________________________________ diffserv mailing list diffserv@ietf.org http://www1.ietf.org/mailman/listinfo/diffserv Archive: http://www2.ietf.org/mail-archive/working-groups/diffserv/current/maillist.html From diffserv-admin@ietf.org Thu Dec 14 18:09:54 2000 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with SMTP id SAA07698 for ; Thu, 14 Dec 2000 18:09:54 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id RAA16129; Thu, 14 Dec 2000 17:40:40 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id RAA16026 for ; Thu, 14 Dec 2000 17:40:30 -0500 (EST) Received: from exchsrv1.cosinecom.com (mail.cosinecom.com [63.88.104.16]) by ietf.org (8.9.1a/8.9.1a) with SMTP id RAA03887 for ; Thu, 14 Dec 2000 17:40:29 -0500 (EST) Received: by exchsrv1.cosinecom.com with Internet Mail Service (5.5.2650.21) id ; Thu, 14 Dec 2000 14:38:12 -0800 Message-ID: <7EB7C6B62C4FD41196A80090279A2911D8AB25@exchsrv1.cosinecom.com> From: Jay Wang To: "'Nabil Seddigh'" Cc: "'Brian E Carpenter'" , diffserv@ietf.org Subject: RE: [Diffserv] Dropping Strategy in AF PHB Date: Thu, 14 Dec 2000 14:38:10 -0800 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C0661E.8973E5E0" Sender: diffserv-admin@ietf.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_01C0661E.8973E5E0 Content-Type: text/plain; charset="iso-8859-1" I don't see the connection at all on both counts. If I allow highly bursty flows to have higher chances of being dropped than those perfectly smoothed, since they are placed under the same PSC, when RED kicks in I drop packets marked out-of-profile first. And those packets tend to be ones coming from the bursty flows. It won't be tail-dropping. Also, giving smooth traffic better treatment does not necessarily mean I do or have to discount the past history either. thanks. - Jay > -----Original Message----- > From: Nabil Seddigh [mailto:nseddigh@nortelnetworks.com] > Sent: Thursday, December 14, 2000 2:04 PM > To: Jay Wang > Cc: 'Brian E Carpenter'; diffserv@ietf.org > Subject: re:[Diffserv] Dropping Strategy in AF PHB > > > >"The dropping algorithm MUST be insensitive to the short-term > >traffic characteristics of the micro flows using AF class. > >That is, flows with different short-term burst but identical > >longer-term packets rates should have packets discarded with > >essentially equal probability." > > > >For one thing, I don't know why the authors of the RFC wanted > >to mandate this. > > There was certainly a lot of attention paid to AF. > > If I recall correctly, the intent of the quoted paragraph was > to ensure > > that drop-tail was not used for AF. It essentially mandates an AQM > mechanism that takes past history into account when making its drop > decisions. I don't think the intent of that paragraph was > to require per-micro-flow drop decisions. > > Best > Nabil > ------_=_NextPart_001_01C0661E.8973E5E0 Content-Type: text/html; charset="iso-8859-1" RE: [Diffserv] Dropping Strategy in AF PHB

I don't see the connection at all on both counts.  If I
allow highly bursty flows to have higher chances of being
dropped than those perfectly smoothed, since they are placed
under the same PSC, when RED kicks in I drop packets marked
out-of-profile first. And those packets tend to be ones
coming from the bursty flows.  It won't be tail-dropping. 
Also, giving smooth traffic better treatment does not
necessarily mean I do or have to discount the past history either. 

thanks.

- Jay

> -----Original Message-----
> From: Nabil Seddigh [mailto:nseddigh@nortelnetworks.com]
> Sent: Thursday, December 14, 2000 2:04 PM
> To: Jay Wang
> Cc: 'Brian E Carpenter'; diffserv@ietf.org
> Subject: re:[Diffserv] Dropping Strategy in AF PHB
>
>
> >"The dropping algorithm MUST be insensitive to the short-term
> >traffic characteristics of the micro flows using AF class.
> >That is, flows with different short-term burst but identical
> >longer-term packets rates should have packets discarded with
> >essentially equal probability."
> >
> >For one thing, I don't know why the authors of the RFC wanted
> >to mandate this.
>
> There was certainly a lot of attention paid to AF.
>
> If I recall correctly, the intent of the quoted paragraph was
> to  ensure
>
> that drop-tail was not used for AF. It essentially mandates an AQM
> mechanism that takes past history into account when making its drop
> decisions. I don't think the intent of that paragraph was
> to require per-micro-flow drop decisions.
>
> Best
> Nabil
>

------_=_NextPart_001_01C0661E.8973E5E0-- _______________________________________________ diffserv mailing list diffserv@ietf.org http://www1.ietf.org/mailman/listinfo/diffserv Archive: http://www2.ietf.org/mail-archive/working-groups/diffserv/current/maillist.html From diffserv-admin@ietf.org Thu Dec 14 18:15: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 SMTP id SAA09194 for ; Thu, 14 Dec 2000 18:15:00 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id RAA16571; Thu, 14 Dec 2000 17:50:30 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id RAA16535 for ; Thu, 14 Dec 2000 17:50:25 -0500 (EST) Received: from yarilo.pluris.com (pluris.com [208.227.9.12]) by ietf.org (8.9.1a/8.9.1a) with SMTP id RAA05213 for ; Thu, 14 Dec 2000 17:50:22 -0500 (EST) Received: from DL100779.pluris.com (volsung.pluris.com [172.16.50.19]) by yarilo.pluris.com (8.9.2/8.9.1) with ESMTP id OAA19721; Thu, 14 Dec 2000 14:49:58 -0800 (PST) Message-Id: <5.0.2.1.0.20001214144924.02844be8@localhost> X-Sender: akyol@localhost X-Mailer: QUALCOMM Windows Eudora Version 5.0.2 Date: Thu, 14 Dec 2000 14:49:49 -0800 To: Grenville Armitage From: Bora Akyol Subject: Re: What's in a name? Re: [Diffserv] Yesterday's EF discussion Cc: Brian E Carpenter , Diff Serv In-Reply-To: <3A386DBA.42F44DAA@research.bell-labs.com> References: <3A37BF28.219E231C@hursley.ibm.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: diffserv-admin@ietf.org Errors-To: diffserv-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Diffserv Discussion List X-BeenThere: diffserv@ietf.org Having a second name effectively allows two PHBs. This was NOT the consensus in the meeting. Bora At 10:50 PM 12/13/2000, Grenville Armitage wrote: >Brian E Carpenter wrote: > [..] > > What should the name of the PHB be? > > Chair's proposal: Defined Rate (DR). I believe that after this long > > and confusing discussion, it would be wise to retire the previous > name. > >Brian, I think this suggestion is a good one. Clearly there are differing >opinions over what RFC2598 intended. I watched from the rear of the room >yesterday. I too saw a crowd sentiment broadly in favor of >draft-charny(modified) as the WG PHB to support VW and similar services. >But given the fact that "EF" has been differently interpreted by a number >of relatively intelligent people, I cannot see the value in anyone being >'damn right' about owning the EF name from this point onwards. The WG needs >a standards track PHB believed to support VW, etc, services....the name >"Defined Rate" captures the rough consensus towards the rate-based >interpretation of RFC2598. > >cheers, >gja (not, it must be noted, speaking of behalf of EFRESOLVE) > >_______________________________________________ >diffserv mailing list >diffserv@ietf.org >http://www1.ietf.org/mailman/listinfo/diffserv >Archive: >http://www2.ietf.org/mail-archive/working-groups/diffserv/current/maillist.html > Bora Akyol Pluris akyol@pluris.com _______________________________________________ diffserv mailing list diffserv@ietf.org http://www1.ietf.org/mailman/listinfo/diffserv Archive: http://www2.ietf.org/mail-archive/working-groups/diffserv/current/maillist.html From diffserv-admin@ietf.org Thu Dec 14 18:29:55 2000 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with SMTP id SAA13627 for ; Thu, 14 Dec 2000 18:29:50 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id SAA16814; Thu, 14 Dec 2000 18:00:06 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id SAA16773 for ; Thu, 14 Dec 2000 18:00:00 -0500 (EST) 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 RAA06430 for ; Thu, 14 Dec 2000 17:59:59 -0500 (EST) Received: from grubby.research.bell-labs.com ([135.104.2.9]) by dirty; Thu Dec 14 17:58:59 EST 2000 Received: from mail1.pa.bell-labs.com ([135.250.8.11]) by grubby; Thu Dec 14 17:58:57 EST 2000 Received: from research.bell-labs.com (ex-vpn66.pa.bell-labs.com [135.250.1.66]) by mail1.pa.bell-labs.com (Mirapoint) with ESMTP id AAW21342 (AUTH gja); Thu, 14 Dec 2000 14:58:56 -0800 (PST) Message-ID: <3A395100.A991CB2D@research.bell-labs.com> Date: Thu, 14 Dec 2000 15:00:16 -0800 From: Grenville Armitage Organization: Bell Labs Research Silicon Valley X-Mailer: Mozilla 4.61 [en] (WinNT; U) X-Accept-Language: en MIME-Version: 1.0 To: Bora Akyol CC: Diff Serv Subject: Re: What's in a name? Re: [Diffserv] Yesterday's EF discussion References: <3A37BF28.219E231C@hursley.ibm.com> <5.0.2.1.0.20001214144924.02844be8@localhost> 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 nobody's asking for a second name. it is a new name. 'EF' gets retired along with RFC2598. only one PHB is the standards track successor to RFC2598, and it will be built on charny-compromise. no problem. cheers, gja Bora Akyol wrote: > > Having a second name effectively allows two PHBs. This was NOT the > consensus in the meeting. > > Bora _______________________________________________ diffserv mailing list diffserv@ietf.org http://www1.ietf.org/mailman/listinfo/diffserv Archive: http://www2.ietf.org/mail-archive/working-groups/diffserv/current/maillist.html From diffserv-admin@ietf.org Thu Dec 14 18:37: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 SMTP id SAA16097 for ; Thu, 14 Dec 2000 18:37:14 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id SAA17247; Thu, 14 Dec 2000 18:10:51 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id SAA17216 for ; Thu, 14 Dec 2000 18:10:46 -0500 (EST) Received: from zrtps06s.us.nortel.com (h50s48a140n47.user.nortelnetworks.com [47.140.48.50]) by ietf.org (8.9.1a/8.9.1a) with SMTP id SAA07920 for ; Thu, 14 Dec 2000 18:10:39 -0500 (EST) Received: from zrtpd00y.us.nortel.com by zrtps06s.us.nortel.com; Thu, 14 Dec 2000 18:01:36 -0500 Received: by zrtpd00y.us.nortel.com with Internet Mail Service (5.5.2652.35) id ; Thu, 14 Dec 2000 18:01:27 -0500 Message-ID: From: "Ralph Santitoro" To: diffserv@ietf.org Subject: RE: [Diffserv] Yesterday's EF discussion Date: Thu, 14 Dec 2000 18:01:20 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2652.35) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C06621.C5F4C2C0" X-Orig: Sender: diffserv-admin@ietf.org Errors-To: diffserv-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Diffserv Discussion List X-BeenThere: diffserv@ietf.org This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. ------_=_NextPart_001_01C06621.C5F4C2C0 Content-Type: text/plain; charset="iso-8859-1" I agree with those in favor of keeping the 'EF' name. My reasons are as follows: 1) The goal of the WG (as discussed at the Pittsburgh meeting) was to "fix" RFC 2598 and -not- to create a new PHB (supporting info already posted to the DiffServ list). Given this, a new name will imply a new PHB. 2) Given that the 'EF' PHB (RFC 2598) was a proposed standard for about a year before it was challenged, vendors have already implemented their interpretation of the 'EF' PHB and its associated 'EF' DSCP. Therefore, the 'EF' term is proliferated in a variety of product literature, whitepapers, marketing literature, engineering documentation, training courseware and device/service configuration tools. Note that the 'EF' name and EF PHB/DSCP definition has been around for at least 2 years and has been an RFC for 1.5 years. 3) The 'EF' term has been socialized for the last 2 years to network managers and the marketplace in general. Given the new term is meant to have the same "intended" behavior that 'EF' was to provide, this new term will create more confusion than clarification for those who are not as close to the subtle details discussed in the WG. Scott's posting below further articulates my point. .... Ralph -----Original Message----- From: Scott Brim [mailto:sbrim@cisco.com] Sent: Thursday, December 14, 2000 10:15 AM To: diffserv@ietf.org Subject: RE: [Diffserv] Yesterday's EF discussion I also think that while there may be some confusion for a while, it's much better to keep the name EF. There are multiple interpretations of "EF", but only below a certain threshold of detail. Those who know the differences and would be concerned by them are also those who would not be confused by calling whatever we produce EF. Those who are farther from the issues only know what EF is *for*, which has not changed. They are not concerned about the details, they often would feel uncomfortable when presented with them, and we would have to bother them with those details in order to explain the new name to them. The new name helps those who don't need it and potentially causes us trouble with those who might. ..Scott _______________________________________________ diffserv mailing list diffserv@ietf.org http://www1.ietf.org/mailman/listinfo/diffserv Archive: http://www2.ietf.org/mail-archive/working-groups/diffserv/current/maillist.h tml ------_=_NextPart_001_01C06621.C5F4C2C0 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable RE: [Diffserv] Yesterday's EF discussion

I agree with those in favor of keeping the 'EF' = name.  My reasons are as follows:

1) The goal of the WG (as discussed at the Pittsburgh = meeting) was to "fix" RFC 2598 and -not- to create a new PHB = (supporting info already posted to the DiffServ list).  Given = this, a new name will imply a new PHB.

2) Given that the 'EF' PHB (RFC 2598) was a proposed = standard for about a year before it was challenged, vendors have = already implemented their interpretation of  the 'EF' PHB and its = associated 'EF' DSCP.  Therefore, the 'EF' term is proliferated in = a variety of product literature, whitepapers, marketing literature, = engineering documentation, training courseware and device/service = configuration tools.  Note that the 'EF' name and EF PHB/DSCP = definition has been around for at least 2 years and has been an RFC for = 1.5 years.

3) The 'EF' term has been socialized for the last 2 = years to network managers and the marketplace in general.  Given = the new term is meant to have the same "intended" behavior = that 'EF' was to provide, this new term will create more confusion than = clarification for those who are not as close to the subtle details = discussed in the WG.  Scott's posting below further articulates my = point.

.... Ralph

-----Original Message-----
From: Scott Brim [mailto:sbrim@cisco.com]
Sent: Thursday, December 14, 2000 10:15 AM
To: diffserv@ietf.org
Subject: RE: [Diffserv] Yesterday's EF = discussion


I also think that while there may be some confusion = for a while, it's
much better to keep the name EF.  There are = multiple interpretations of
"EF", but only below a certain threshold = of detail.  Those who know the
differences and would be concerned by them are also = those who would not
be confused by calling whatever we produce EF.  = Those who are farther
from the issues only know what EF is *for*, which = has not changed.  They
are not concerned about the details, they often = would feel uncomfortable
when presented with them, and we would have to = bother them with those
details in order to explain the new name to = them.  The new name helps
those who don't need it and potentially causes us = trouble with those who
might.

..Scott


_______________________________________________
diffserv mailing list
diffserv@ietf.org
http://www1.ietf.org/mailman/listinfo/diffserv
Archive: http://www2.ietf.org/mail-archive/working-groups/diffs= erv/current/maillist.html

------_=_NextPart_001_01C06621.C5F4C2C0-- _______________________________________________ diffserv mailing list diffserv@ietf.org http://www1.ietf.org/mailman/listinfo/diffserv Archive: http://www2.ietf.org/mail-archive/working-groups/diffserv/current/maillist.html From diffserv-admin@ietf.org Thu Dec 14 18:58: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 SMTP id SAA16094 for ; Thu, 14 Dec 2000 18:37:14 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id SAA17090; Thu, 14 Dec 2000 18:06:26 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id SAA17052 for ; Thu, 14 Dec 2000 18:06:21 -0500 (EST) Received: from mailhub1.almaden.ibm.com (mailhub1.almaden.ibm.com [198.4.83.44]) by ietf.org (8.9.1a/8.9.1a) with SMTP id SAA07266 for ; Thu, 14 Dec 2000 18:06:18 -0500 (EST) Received: from maui.almaden.ibm.com (maui.almaden.ibm.com [9.1.24.92]) by mailhub1.almaden.ibm.com (8.8.8/8.8.8) with ESMTP id PAA53760; Thu, 14 Dec 2000 15:02:35 -0800 Received: from hursley.ibm.com (gsine01.us.sine.ibm.com [9.14.6.41]) by maui.almaden.ibm.com (AIX4.3/8.9.3/8.7) with ESMTP id PAA09498; Thu, 14 Dec 2000 15:05:48 -0800 Message-ID: <3A3951D7.A7D94D21@hursley.ibm.com> Date: Thu, 14 Dec 2000 17:03:51 -0600 From: Brian E Carpenter Organization: IBM X-Mailer: Mozilla 4.61 [en] (Win98; I) X-Accept-Language: en,fr MIME-Version: 1.0 To: Jay Wang CC: "'Nabil Seddigh'" , diffserv@ietf.org Subject: Re: [Diffserv] Dropping Strategy in AF PHB References: <7EB7C6B62C4FD41196A80090279A2911D8AB25@exchsrv1.cosinecom.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: diffserv-admin@ietf.org Errors-To: diffserv-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Diffserv Discussion List X-BeenThere: diffserv@ietf.org Content-Transfer-Encoding: 7bit I suggest you refer to the diffserv archive. We discussed all this at great length before reaching consensus on the text of RFC 2597. Brian > Jay Wang wrote: > > I don't see the connection at all on both counts. If I > allow highly bursty flows to have higher chances of being > dropped than those perfectly smoothed, since they are placed > under the same PSC, when RED kicks in I drop packets marked > out-of-profile first. And those packets tend to be ones > coming from the bursty flows. It won't be tail-dropping. > Also, giving smooth traffic better treatment does not > necessarily mean I do or have to discount the past history either. > > thanks. > > - Jay > > > -----Original Message----- > > From: Nabil Seddigh [mailto:nseddigh@nortelnetworks.com] > > Sent: Thursday, December 14, 2000 2:04 PM > > To: Jay Wang > > Cc: 'Brian E Carpenter'; diffserv@ietf.org > > Subject: re:[Diffserv] Dropping Strategy in AF PHB > > > > > > >"The dropping algorithm MUST be insensitive to the short-term > > >traffic characteristics of the micro flows using AF class. > > >That is, flows with different short-term burst but identical > > >longer-term packets rates should have packets discarded with > > >essentially equal probability." > > > > > >For one thing, I don't know why the authors of the RFC wanted > > >to mandate this. > > > > There was certainly a lot of attention paid to AF. > > > > If I recall correctly, the intent of the quoted paragraph was > > to ensure > > > > that drop-tail was not used for AF. It essentially mandates an AQM > > mechanism that takes past history into account when making its drop > > decisions. I don't think the intent of that paragraph was > > to require per-micro-flow drop decisions. > > > > Best > > Nabil > > _______________________________________________ diffserv mailing list diffserv@ietf.org http://www1.ietf.org/mailman/listinfo/diffserv Archive: http://www2.ietf.org/mail-archive/working-groups/diffserv/current/maillist.html From diffserv-admin@ietf.org Thu Dec 14 19:47:52 2000 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with SMTP id TAA07767 for ; Thu, 14 Dec 2000 19:47:52 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id TAA18528; Thu, 14 Dec 2000 19:16:21 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id TAA18497 for ; Thu, 14 Dec 2000 19:16:17 -0500 (EST) Received: from pmesmtp02.wcom.com (pmesmtp02.wcom.com [199.249.20.2]) by ietf.org (8.9.1a/8.9.1a) with SMTP id TAA28327 for ; Thu, 14 Dec 2000 19:16:16 -0500 (EST) Received: from CONVERSION-DAEMON by firewall.mcit.com (PMDF V5.2-32 #42257) id <0G5L0080122BD2@firewall.mcit.com> for diffserv@ietf.org; Fri, 15 Dec 2000 00:15:47 +0000 (GMT) Received: from dgismtp04.wcomnet.com ([166.38.58.144]) by firewall.mcit.com (PMDF V5.2-32 #42257) with ESMTP id <0G5L005D522AHM@firewall.mcit.com>; Fri, 15 Dec 2000 00:15:46 +0000 (GMT) Received: from CONVERSION-DAEMON by dgismtp04.wcomnet.com (PMDF V5.2-33 #42262) id <0G5L00N0122A0B@dgismtp04.wcomnet.com>; Fri, 15 Dec 2000 00:15:46 +0000 (GMT) Received: from dgismtp04.wcomnet.com by dgismtp04.wcomnet.com (PMDF V5.2-33 #42262) with SMTP id <0G5L00M01222WG@dgismtp04.wcomnet.com>; Fri, 15 Dec 2000 00:15:45 +0000 (GMT) Received: from pc007978875 ([166.44.247.132]) by dgismtp04.wcomnet.com (PMDF V5.2-33 #42262) with SMTP id <0G5L00JCR21FE2@dgismtp04.wcomnet.com>; Fri, 15 Dec 2000 00:15:33 +0000 (GMT) Date: Thu, 14 Dec 2000 19:15:19 -0500 From: Dave McDysan Subject: RE: [Diffserv] Yesterday's EF discussion In-reply-to: <3A3903FC.69621E7D@hursley.ibm.com> To: Brian E Carpenter Cc: Diff Serv Message-id: MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V5.00.2314.1300 X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2910.0) Content-type: text/plain; charset=iso-8859-1 Content-transfer-encoding: 7bit Importance: Normal X-Priority: 3 (Normal) X-MSMail-priority: Normal Content-Transfer-Encoding: 7bit Sender: diffserv-admin@ietf.org Errors-To: diffserv-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Diffserv Discussion List X-BeenThere: diffserv@ietf.org Content-Transfer-Encoding: 7bit I would like to keep the name EF for the Charny compromise for the reasons stated in prior Emails. None of the name changers present a compelling argument. For me, Expedited Forwarding is an easy to explain reference to priority queuing, which by all accounts is a viable implementation of this PHB (with limits to protect other traffic, as stated in 2598). Dave > -----Original Message----- > From: diffserv-admin@ietf.org [mailto:diffserv-admin@ietf.org]On Behalf > Of Brian E Carpenter > Sent: Thursday, December 14, 2000 12:32 PM > To: demir > Cc: Diff Serv > Subject: Re: [Diffserv] Yesterday's EF discussion > > > Demir, > > You've made your point. I'd like to hear from the silent majority: > do we change the name or not? > > Brian > > demir wrote: > > > > Shahram, > > I am not sure if what you stated was the industry's understanding. ... > > _______________________________________________ > diffserv mailing list > diffserv@ietf.org > http://www1.ietf.org/mailman/listinfo/diffserv > Archive: > http://www2.ietf.org/mail-archive/working-groups/diffserv/current/ maillist.html _______________________________________________ diffserv mailing list diffserv@ietf.org http://www1.ietf.org/mailman/listinfo/diffserv Archive: http://www2.ietf.org/mail-archive/working-groups/diffserv/current/maillist.html From diffserv-admin@ietf.org Thu Dec 14 20:42: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 SMTP id UAA22897 for ; Thu, 14 Dec 2000 20:41:59 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id UAA19337; Thu, 14 Dec 2000 20:17:26 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id UAA19315 for ; Thu, 14 Dec 2000 20:17:22 -0500 (EST) Received: from sj-msg-core-1.cisco.com (sj-msg-core-1.cisco.com [171.71.163.11]) by ietf.org (8.9.1a/8.9.1a) with SMTP id UAA16813 for ; Thu, 14 Dec 2000 20:17:20 -0500 (EST) 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 RAA29440; Thu, 14 Dec 2000 17:16:57 -0800 (PST) Received: from localhost.localdomain.cisco.com (ssh-sj1.cisco.com [171.68.225.134]) by airborne.cisco.com (Mirapoint) with ESMTP id ACI00129; Thu, 14 Dec 2000 17:16:49 -0800 (PST) X-Mailer: emacs 20.7.1 (via feedmail 8 Q); VM 6.87 under Emacs 20.7.1 From: "Scott Brim" MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <14905.18001.925155.288693@localhost.localdomain> Date: Thu, 14 Dec 2000 14:14:41 -0800 To: John Schnizlein Cc: Larry Ayres , diffserv@ietf.org Subject: Re: [Diffserv] A revised expression of the Expedited Forwarding PHB In-Reply-To: <4.1.20001214163942.00a15b80@diablo.cisco.com> References: <3.0.1.32.20001214125613.00aa2610@mail.acc.com> <4.1.20001214163942.00a15b80@diablo.cisco.com> Content-Transfer-Encoding: 7bit Sender: diffserv-admin@ietf.org Errors-To: diffserv-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Diffserv Discussion List X-BeenThere: diffserv@ietf.org Content-Transfer-Encoding: 7bit On 14 Dec 2000 at 16:40 -0500, John Schnizlein apparently wrote: > At 12:56 PM 12/14/2000 -0800, Larry Ayres wrote: > >It seems to me that the first sentence on page 3 which reads: > > > >If more EF traffic arrives than is acceptable, the device is NOT REQUIRED > >to deliver the EF behavior. > > > >is meant to convey: > > > >If more EF traffic arrives than is acceptable, the device is NOT REQUIRED > >to deliver the EF behavior to the excess traffic. > > > >Am I right in this interpretation ? > > Yes. Um, except that implies to me a requirement that the forwarder discriminate between traffic which is "excess" and traffic which is not. The top version is better in that respect. ...Scott _______________________________________________ diffserv mailing list diffserv@ietf.org http://www1.ietf.org/mailman/listinfo/diffserv Archive: http://www2.ietf.org/mail-archive/working-groups/diffserv/current/maillist.html From diffserv-admin@ietf.org Thu Dec 14 21:14: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 SMTP id VAA05213 for ; Thu, 14 Dec 2000 21:14:59 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id UAA19819; Thu, 14 Dec 2000 20:48:32 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id UAA19790 for ; Thu, 14 Dec 2000 20:48:28 -0500 (EST) Received: from pilgrim.cisco.com (pilgrim.cisco.com [171.69.204.12]) by ietf.org (8.9.1a/8.9.1a) with SMTP id UAA24913 for ; Thu, 14 Dec 2000 20:48:26 -0500 (EST) Received: from acharny-nt.cisco.com ([161.44.189.106]) by pilgrim.cisco.com (8.8.8-Cisco List Logging/8.8.8) with ESMTP id UAA01852 for ; Thu, 14 Dec 2000 20:47:57 -0500 (EST) Message-Id: <4.3.2.7.2.20001214205122.00c91ef0@pilgrim.cisco.com> X-Sender: acharny@pilgrim.cisco.com X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Thu, 14 Dec 2000 20:53:41 -0500 To: diffserv@ietf.org From: Anna Charny Subject: RE: [Diffserv] Yesterday's EF discussion In-Reply-To: References: <3A3903FC.69621E7D@hursley.ibm.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: diffserv-admin@ietf.org Errors-To: diffserv-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Diffserv Discussion List X-BeenThere: diffserv@ietf.org Brian, I believe the new document replacing the RFC 2598 should keep the name EF. I have nothing to add to the arguments already expressed on the list. Anna --------------------------------------- Anna Charny Cisco Systems, Inc 300 Apollo Drive Chelmsford, MA 01824 Tel. (978)-244-8172 Fax (978)-244-8126 _______________________________________________ diffserv mailing list diffserv@ietf.org http://www1.ietf.org/mailman/listinfo/diffserv Archive: http://www2.ietf.org/mail-archive/working-groups/diffserv/current/maillist.html From diffserv-admin@ietf.org Thu Dec 14 21:18: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 SMTP id VAA06417 for ; Thu, 14 Dec 2000 21:18:42 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id UAA19965; Thu, 14 Dec 2000 20:53:09 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id UAA19859 for ; Thu, 14 Dec 2000 20:53:00 -0500 (EST) Received: from zcars04f.ca.nortel.com (h57s242a129n47.user.nortelnetworks.com [47.129.242.57]) by ietf.org (8.9.1a/8.9.1a) with SMTP id UAA26692 for ; Thu, 14 Dec 2000 20:52:58 -0500 (EST) Received: from zcard015.ca.nortel.com by zcars04f.ca.nortel.com; Thu, 14 Dec 2000 20:52:10 -0500 Received: by zcard015.ca.nortel.com with Internet Mail Service (5.5.2652.35) id ; Thu, 14 Dec 2000 20:52:11 -0500 Message-ID: <13E2EF604DE5D111B2E50000F80824E8057A89F3@zwdld001.ca.nortel.com> From: "Gary Kenward" To: "'Grenville Armitage'" , Jon Bennett Cc: "'Brian E Carpenter'" , diffserv@ietf.org Subject: RE: [Diffserv] Yesterday's EF discussion Date: Thu, 14 Dec 2000 20:52:09 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2652.35) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C06639.A2C67CE0" X-Orig: Sender: diffserv-admin@ietf.org Errors-To: diffserv-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Diffserv Discussion List X-BeenThere: diffserv@ietf.org This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. ------_=_NextPart_001_01C06639.A2C67CE0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable No, sorry. With all due respect to the wg chair, the phrasing of the questions was illogical.=20 The first question was "how many support two PHBs", for which there was moderate response. The second question was "how many would not accept = two PHBs", for which there was a weaker response. The votes were not exclusive. The correct phrasing for the second = question=20 should have been "how many support having only one PHB". While I many or many not support two PHBs, I *may* accept two PHBs when faced with a less desirable alternative.=20 Cheers, Gary =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D Gary W. Kenward gkenward@nortelnetworks.com Advisor, Wireless Architecture (613) 765-1437 Advanced Technology Labs ESN 395-1437 Wireless Solutions FAX: (613) 763-2686 Nortel Networks =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D Plus =E7a change, plus c'est la m=EAme chose. The contents of this email are Nortel Networks Confidential > -----Original Message----- > From: Grenville Armitage [mailto:gja@research.bell-labs.com] > Sent: Thursday, December 14, 2000 2:50 PM > To: Jon Bennett > Cc: 'Brian E Carpenter'; diffserv@ietf.org > Subject: Re: [Diffserv] Yesterday's EF discussion >=20 >=20 >=20 >=20 > Jon Bennett wrote: > [..] > > the room was > > also vastly opposed to two PHBs, >=20 > This is so stunningly different to my recollection as to leave me > wondering what rooms we were in. Standing quietly at the rear > room, I saw (with my own two beady little eyes) the question > of "can the WG accept two PHBs" receive more 'yes' than 'no'. =20 >=20 > (The crowd was certainly with charny-compromise on the different, > and more specific question of which text to use *if* there was to > be only one PHB. But that *is* a different question.) >=20 > cheers, > gja >=20 > _______________________________________________ > diffserv mailing list > diffserv@ietf.org > http://www1.ietf.org/mailman/listinfo/diffserv > Archive:=20 http://www2.ietf.org/mail-archive/working-groups/diffserv/current/mailli= st.h tml ------_=_NextPart_001_01C06639.A2C67CE0 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable RE: [Diffserv] Yesterday's EF discussion

No, sorry. With all due respect to the wg chair, the = phrasing of the questions
was illogical.

The first question was "how many support two = PHBs", for which there was
moderate response. The second question was "how = many would not accept two PHBs",
for which there was a weaker response.

The votes were not exclusive. The correct phrasing = for the second question
should have been "how many support having only = one PHB".

While I many or many not support two PHBs, I *may* = accept two PHBs when
faced with a less desirable alternative.

Cheers,
Gary

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

Plus =E7a change, plus c'est la m=EAme chose.

The contents of this email are Nortel Networks = Confidential



> -----Original Message-----
> From: Grenville Armitage [mailto:gja@research.bell-labs= .com]
> Sent: Thursday, December 14, 2000 2:50 = PM
> To: Jon Bennett
> Cc: 'Brian E Carpenter'; = diffserv@ietf.org
> Subject: Re: [Diffserv] Yesterday's EF = discussion
>
>
>
>
> Jon Bennett wrote:
>       [..]
> > the room was
> > also vastly opposed to two PHBs,
>
> This is so stunningly different to my = recollection as to leave me
> wondering what rooms we were in.  Standing = quietly at the rear
> room, I saw (with my own two beady little eyes) = the question
> of "can the WG accept two PHBs" = receive more 'yes' than 'no'. 
>
> (The crowd was certainly with charny-compromise = on the different,
> and more specific question of which text to use = *if* there was to
> be only one PHB. But that *is* a different = question.)
>
> cheers,
> gja
>
> = _______________________________________________
> diffserv mailing list
> diffserv@ietf.org
> http://www1.ietf.org/mailman/listinfo/diffserv
> Archive:
http://www2.ietf.org/mail-archive/working-groups/diffs= erv/current/maillist.html

------_=_NextPart_001_01C06639.A2C67CE0-- _______________________________________________ diffserv mailing list diffserv@ietf.org http://www1.ietf.org/mailman/listinfo/diffserv Archive: http://www2.ietf.org/mail-archive/working-groups/diffserv/current/maillist.html From diffserv-admin@ietf.org Thu Dec 14 21: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 SMTP id VAA10839 for ; Thu, 14 Dec 2000 21:30:25 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id VAA20278; Thu, 14 Dec 2000 21:04:47 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id VAA20254 for ; Thu, 14 Dec 2000 21:04:43 -0500 (EST) Received: from hertz.ece.wisc.edu (hertz.ece.wisc.edu [128.104.183.33]) by ietf.org (8.9.1a/8.9.1a) with SMTP id VAA01735 for ; Thu, 14 Dec 2000 21:04:41 -0500 (EST) Received: (from dovrolis@localhost) by hertz.ece.wisc.edu (8.8.8+Sun/8.8.8) id UAA05924; Thu, 14 Dec 2000 20:03:58 -0600 (CST) From: Constantinos Message-Id: <200012150203.UAA05924@hertz.ece.wisc.edu> Subject: Re: [Diffserv] Yesterday's EF discussion To: brian@hursley.ibm.com (Brian E Carpenter) Date: Thu, 14 Dec 2000 20:03:58 -0600 (CST) Cc: demir@usc.edu (demir), diffserv@ietf.org (Diff Serv) In-Reply-To: <3A3903FC.69621E7D@hursley.ibm.com> from "Brian E Carpenter" at Dec 14, 2000 11:31:40 AM X-Mailer: ELM [version 2.5 PL2] MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: diffserv-admin@ietf.org Errors-To: diffserv-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Diffserv Discussion List X-BeenThere: diffserv@ietf.org Content-Transfer-Encoding: 7bit > > You've made your point. I'd like to hear from the silent majority: > do we change the name or not? I guess I was in the silent majority for a while.. My opinion is to not change the name. It is a rather major change to abandon the EF term, now that the working group should be approaching the end of its tasks. Regarding the EF issue in general: Whether the issue that came up with the EF RFC is important for the industry or not, it remains to be seen. If there is indeed a problem of interoperable implementations and strictly verifiable SLAs, then the EF PHB will not be used, and later on, a Diffserv II working group for instance, may attempt a different definition/term/architecture. If on the other hand the router vendors and the network providers start using the EF PHB then our concerns about it may prove to be unimportant. Just my 2 cents, -- Constantinos ---- http://www.cae.wisc.edu/~dovrolis _______________________________________________ diffserv mailing list diffserv@ietf.org http://www1.ietf.org/mailman/listinfo/diffserv Archive: http://www2.ietf.org/mail-archive/working-groups/diffserv/current/maillist.html From diffserv-admin@ietf.org Thu Dec 14 21:46: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 SMTP id VAA17190 for ; Thu, 14 Dec 2000 21:46:00 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id VAA20515; Thu, 14 Dec 2000 21:21:49 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id VAA20484 for ; Thu, 14 Dec 2000 21:21:45 -0500 (EST) Received: from packetbdc.packettech.com (packetbdc.riverdelta.com [198.112.190.11]) by ietf.org (8.9.1a/8.9.1a) with SMTP id VAA07412 for ; Thu, 14 Dec 2000 21:21:43 -0500 (EST) Received: by packetbdc.riverdelta.com with Internet Mail Service (5.5.2650.21) id ; Thu, 14 Dec 2000 21:23:07 -0500 Message-ID: <7F4AC78738EAD2119D86009027626C6D889027@packetbdc.riverdelta.com> From: Jon Bennett To: "'John Schnizlein'" , Jon Bennett , diffserv@ietf.org Subject: RE: [Diffserv] Yesterday's EF discussion Date: Thu, 14 Dec 2000 21:23:07 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: text/plain; charset="iso-8859-1" Sender: diffserv-admin@ietf.org Errors-To: diffserv-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Diffserv Discussion List X-BeenThere: diffserv@ietf.org > > At 02:11 PM 12/14/2000 -0500, Jon Bennett wrote: > >... our assertion all along has been that what we wrote in > >draft-charny is what 2598 'says' regardless of what Van 'meant' > >to say. > >And that what it 'says' has been implemented by a lot of people > >already. > > Could you provide some details about who has "implemented" EF? > > What exactly do you mean by "implemented"? > > John Well you know that's an interesting question, perhaps you should go ask those who are claiming to be implementing or deploying EF what it is that they meant; For starters there is this Abilene press release that says they are implementing EF on Cisco routers. http://www.internet2.edu/abilene/qos/announcement.html And there is a nice article in Cisco's Packet magazine about it as well http://www.cisco.com/warp/public/784/packet/apr00/netizens.html And the IOS 12.1 release docs are quite clear that EF is supported, its the second RFC on the list. http://www.cisco.com/warp/public/cc/general/bulletin/software/general/1189_p p.htm Since I see from your e-mail address that you work at Cisco, presumably you can figure out who inside your company actually knows what Cisco's EF implementation is like and ask them about it. Of course it you don't know anyone in Cisco who is working with EF you could ask one of the WG co-chairs, since I see from this talk about the testing of EF at iCAIR that Brian Carpenter is listed as one of the collaborators http://www.internet2.edu/qos/houston2000/proceedings/Mambretti/20000209-QoS2 000-Mambretti.pdf And he's listed on the conference program next to this talk so he must know all about it http://sss.advanced.org/meetings/houston2000/ let me know if that answers your question, or if you would like me to explain further... jon _______________________________________________ diffserv mailing list diffserv@ietf.org http://www1.ietf.org/mailman/listinfo/diffserv Archive: http://www2.ietf.org/mail-archive/working-groups/diffserv/current/maillist.html From diffserv-admin@ietf.org Thu Dec 14 21: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 SMTP id VAA18385 for ; Thu, 14 Dec 2000 21:49:39 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id VAA20636; Thu, 14 Dec 2000 21:28:21 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id VAA20607 for ; Thu, 14 Dec 2000 21:28:17 -0500 (EST) Received: from packetbdc.packettech.com (packetbdc.riverdelta.com [198.112.190.11]) by ietf.org (8.9.1a/8.9.1a) with SMTP id VAA09985 for ; Thu, 14 Dec 2000 21:28:15 -0500 (EST) Received: by packetbdc.riverdelta.com with Internet Mail Service (5.5.2650.21) id ; Thu, 14 Dec 2000 21:29:40 -0500 Message-ID: <7F4AC78738EAD2119D86009027626C6D889028@packetbdc.riverdelta.com> From: Jon Bennett To: "'Brian E Carpenter'" , Jon Bennett Cc: diffserv@ietf.org Subject: RE: [Diffserv] Yesterday's EF discussion Date: Thu, 14 Dec 2000 21:29:39 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: text/plain; charset="iso-8859-1" Sender: diffserv-admin@ietf.org Errors-To: diffserv-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Diffserv Discussion List X-BeenThere: diffserv@ietf.org Brian, > Jon, just an (obvious) point of clarification: RFC 2598 will not go > away - it will stay there for ever, presumably marked in the index as > (Obsoleted by RFCxxxx). Question to the chair, given that I said our intentions were "to obsolete RFC 2598" what was it that you were clarifying? Or were you just worried I didn't know 'to obsolete' meant? > Your preference for not changing the name is noted. Thank you for taking note of my opinion. jon _______________________________________________ diffserv mailing list diffserv@ietf.org http://www1.ietf.org/mailman/listinfo/diffserv Archive: http://www2.ietf.org/mail-archive/working-groups/diffserv/current/maillist.html From diffserv-admin@ietf.org Fri Dec 15 01:39: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 SMTP id BAA14863 for ; Fri, 15 Dec 2000 01:39:17 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id BAA28964; Fri, 15 Dec 2000 01:13:09 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id BAA28933 for ; Fri, 15 Dec 2000 01:13:05 -0500 (EST) Received: from motgate2.mot.com (motgate2.mot.com [136.182.1.10]) by ietf.org (8.9.1a/8.9.1a) with SMTP id BAA00727 for ; Fri, 15 Dec 2000 01:13:05 -0500 (EST) Received: [from mothost.mot.com (mothost.mot.com [129.188.137.101]) by motgate2.mot.com (motgate2 2.1) with ESMTP id XAA29298 for ; Thu, 14 Dec 2000 23:13:05 -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 XAA07599 for ; Thu, 14 Dec 2000 23:13:05 -0700 (MST)] Received: from dma.isg.mot.com (t_il06_m_slip11.corp.mot.com [129.188.171.112]) by noah.dma.isg.mot.com (8.8.8+Sun/8.8.8) with ESMTP id BAA08111; Fri, 15 Dec 2000 01:13:02 -0500 (EST) Message-ID: <3A39B7F6.4E990FB4@dma.isg.mot.com> Date: Fri, 15 Dec 2000 01:19:37 -0500 From: Dan Grossman X-Mailer: Mozilla 4.51 (Macintosh; I; PPC) X-Accept-Language: en MIME-Version: 1.0 To: Brian E Carpenter CC: Diff Serv Subject: Re: [Diffserv] Yesterday's EF discussion References: <3A37BF28.219E231C@hursley.ibm.com> Content-Type: text/plain; charset=us-ascii; x-mac-type="54455854"; x-mac-creator="4D4F5353" Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: diffserv-admin@ietf.org Errors-To: diffserv-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Diffserv Discussion List X-BeenThere: diffserv@ietf.org Content-Transfer-Encoding: 7bit Brian E Carpenter wrote: > Summary of conclusions from EF discussion on 12/12/2000 A replacement for RFC 2598 > should be drafted, in the strict format > of a PHB definition as specified in RFC 2474, based on the > "possible compromise" revision to the model described in > draft-charny-ef-definition-01.txt. This is to be progressed as > a WG draft intended to be submitted as a Proposed Standard. > > Open issues: > > Authorship of the new document. > Chair's proposal: all contributors to RFC 2598, > to draft-charny-ef-definition-01.txt, and to > draft-ietf-diffserv-efresolve-00.txt should be recognized as authors. Um... I know this is a delicate issue, but it would look rather odd to have the co-authors list longer than the substance of the text. We do have an Acknowledgements section. Suggest that co-authorship be left to the good will of the contributors, with the understanding that it be reserved for those who contriubted significant text or major concepts. > > > Should the recommended code point be 101110? > Chair's proposal: yes Yes > > > What should the name of the PHB be? > Chair's proposal: Defined Rate (DR). I believe that after this long > and confusing discussion, it would be wise to retire the previous name. The name should not be changed, for reasons already discussed, and in particular because we have caused enough confusion to the industry, and to do so would make matters worse. _______________________________________________ diffserv mailing list diffserv@ietf.org http://www1.ietf.org/mailman/listinfo/diffserv Archive: http://www2.ietf.org/mail-archive/working-groups/diffserv/current/maillist.html From diffserv-admin@ietf.org Fri Dec 15 03:45: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 SMTP id DAA04626 for ; Fri, 15 Dec 2000 03:45:30 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id DAA00301; Fri, 15 Dec 2000 03:15:43 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id DAA00278 for ; Fri, 15 Dec 2000 03:15:35 -0500 (EST) Received: from central.switch.ch (central.switch.ch [130.59.4.1]) by ietf.org (8.9.1a/8.9.1a) with SMTP id DAA25606 for ; Fri, 15 Dec 2000 03:15:33 -0500 (EST) Received: from leinen by central.switch.ch with local (Exim 3.15 #3) id 146q1A-0006Xn-00; Fri, 15 Dec 2000 09:15:04 +0100 To: brian@hursley.ibm.com CC: diffserv@ietf.org Subject: Re: [Diffserv] Yesterday's EF discussion References: <20001214204715.2430.qmail@web4206.mail.yahoo.com> X-Face: 1Nk*r=:$IBBb8|TyRB'2WSY6u:BzMO7N)#id#-4_}MsU5?vTI?dez|JiutW4sKBLjp.l7,F 7QOld^hORRtpCUj)!cP]gtK_SyK5FW(+o"!or:v^C^]OxX^3+IPd\z,@ttmwYVO7l`6OXXYR` From: Simon Leinen In-Reply-To: g_mercankosk@yahoo.com's message of "Thu, 14 Dec 2000 12:47:15 -0800 (PST)" Date: 15 Dec 2000 09:15:04 +0100 Message-ID: Lines: 18 X-Mailer: Gnus v5.7/Emacs 20.7 Sender: diffserv-admin@ietf.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 entirely support Guven's argument for changing the name. -- Simon. >>>>> "gm" == g mercankosk writes: > The authors of the original document clearly state > that their intention of EF was accurately captured in > the EF RESOLVE team version. On the other hand, Charny > et al claim that the majority of the people in the > industry understood something DIFFERENT. The consensus > has been reached that the people wanted to go along > with this DIFFERENT understanding. If they were the > SAME, we would not be having this argument. Now > keeping the name tells the original authors, "No, no, > your intention was DIFFERENT!" I think, common sense > tells that this has not been the consensus. > Accordingly, I find your suggestion of name change > quite appropriate. _______________________________________________ diffserv mailing list diffserv@ietf.org http://www1.ietf.org/mailman/listinfo/diffserv Archive: http://www2.ietf.org/mail-archive/working-groups/diffserv/current/maillist.html From diffserv-admin@ietf.org Fri Dec 15 05:09:50 2000 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with SMTP id FAA23344 for ; Fri, 15 Dec 2000 05:09:50 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id EAA00949; Fri, 15 Dec 2000 04:18:01 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id EAA00927 for ; Fri, 15 Dec 2000 04:17:56 -0500 (EST) Received: from mail.sedonanetworks.com ([64.26.140.3]) by ietf.org (8.9.1a/8.9.1a) with SMTP id EAA11694 for ; Fri, 15 Dec 2000 04:17:55 -0500 (EST) Received: by MAIL with Internet Mail Service (5.5.2653.19) id ; Fri, 15 Dec 2000 04:16:45 -0500 Message-ID: <81BAD602267CD3119016009027747F67AF82B8@MAIL> From: Toyanne Lauriston To: "'Brian E Carpenter'" Cc: Diff Serv Subject: RE: [Diffserv] Yesterday's EF discussion Date: Fri, 15 Dec 2000 04:16:37 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Sender: diffserv-admin@ietf.org Errors-To: diffserv-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Diffserv Discussion List X-BeenThere: diffserv@ietf.org I believe the Charny-compromise should be called EF. It builds on the EF definition as described in the EF RFC. It is unfortunate that the EF RFC was written such that it was open to misinterpretation of the authors' intent but that is water under the bridge. Changing the name now will introduce unnecessary confusion. Toyanne -----Original Message----- From: Brian E Carpenter [mailto:brian@hursley.ibm.com] Sent: December 14, 2000 12:32 PM To: demir Cc: Diff Serv Subject: Re: [Diffserv] Yesterday's EF discussion Demir, You've made your point. I'd like to hear from the silent majority: do we change the name or not? Brian demir wrote: > > Shahram, > I am not sure if what you stated was the industry's understanding. ... _______________________________________________ diffserv mailing list diffserv@ietf.org http://www1.ietf.org/mailman/listinfo/diffserv Archive: http://www2.ietf.org/mail-archive/working-groups/diffserv/current/maillist.h tml _______________________________________________ diffserv mailing list diffserv@ietf.org http://www1.ietf.org/mailman/listinfo/diffserv Archive: http://www2.ietf.org/mail-archive/working-groups/diffserv/current/maillist.html From diffserv-admin@ietf.org Fri Dec 15 08:42: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 SMTP id IAA07361 for ; Fri, 15 Dec 2000 08:42:04 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id IAA03084; Fri, 15 Dec 2000 08:09:51 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id IAA03053 for ; Fri, 15 Dec 2000 08:09:47 -0500 (EST) Received: from p-mail2.cnet.fr (p-mail2.rd.francetelecom.fr [193.49.124.32]) by ietf.org (8.9.1a/8.9.1a) with SMTP id IAA01066 for ; Fri, 15 Dec 2000 08:09:45 -0500 (EST) Received: by p-voyageur.issy.cnet.fr with Internet Mail Service (5.5.2650.21) id ; Fri, 15 Dec 2000 14:09:14 +0100 Message-ID: <98388C05D464D111B61800805F15041601418A7B@p-ibis.issy.cnet.fr> From: ROBERTS James FTRD/DAC/ISS To: "'Diff Serv'" Subject: RE: [Diffserv] Yesterday's EF discussion Date: Fri, 15 Dec 2000 14:09:06 +0100 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: text/plain; charset="ISO-8859-1" Sender: diffserv-admin@ietf.org Errors-To: diffserv-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Diffserv Discussion List X-BeenThere: diffserv@ietf.org I think "expedited forwarding" is a more appropriate description for what is defined than "defined rate". In my view the essential parameters of the PHB are the bounds E_a and E_p rather than the rate R. This is true at least for an implementation using priority queuing. My choice would therefore be to keep the name EF. Jim _______________________________________________ diffserv mailing list diffserv@ietf.org http://www1.ietf.org/mailman/listinfo/diffserv Archive: http://www2.ietf.org/mail-archive/working-groups/diffserv/current/maillist.html From diffserv-admin@ietf.org Fri Dec 15 09:17: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 SMTP id JAA11349 for ; Fri, 15 Dec 2000 09:17:55 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id IAA03420; Fri, 15 Dec 2000 08:47:38 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id IAA03389 for ; Fri, 15 Dec 2000 08:47:34 -0500 (EST) Received: from usc.edu (root@usc.edu [128.125.253.136]) by ietf.org (8.9.1a/8.9.1a) with SMTP id IAA07954 for ; Fri, 15 Dec 2000 08:47:32 -0500 (EST) Received: from nunki.usc.edu (demir@nunki.usc.edu [128.125.5.168]) by usc.edu (8.9.3.1/8.9.3/usc) with ESMTP id FAA26571 for ; Fri, 15 Dec 2000 05:47:33 -0800 (PST) Received: from localhost (demir@localhost) by nunki.usc.edu (8.9.3.1/8.9.3/usc) with ESMTP id FAA12037 for ; Fri, 15 Dec 2000 05:47:32 -0800 (PST) X-Authentication-Warning: nunki.usc.edu: demir owned process doing -bs Date: Fri, 15 Dec 2000 05:47:32 -0800 (PST) From: demir To: diffserv@ietf.org Subject: [Diffserv] Questions and Comments on "Possible compromise between EFRESOLVE and draft-charny" In-Reply-To: <4.3.2.7.2.20001214205122.00c91ef0@pilgrim.cisco.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: diffserv-admin@ietf.org Errors-To: diffserv-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Diffserv Discussion List X-BeenThere: diffserv@ietf.org This "compromise" has two parts: D(j) < B/R + E_p (color-aware) - Delay constraint d(j) < F(j) + E_a (color-blind) - Rate constraint F(j) = MAX(a(j),MIN(d(j-1),F(j-1))) + L(j)/R 1) In this "specific" choice on "delay constraint" and "rate constraint" "Efficiency" of "delay constraint" depends on the choice of R that also will have an impact on the choice of B where both choices will have an impact on "loss rate". Is it okay to "standardize" this by Diffserv group? Note: If so, i) It seems to me that defining B as: B = SIGMA Bi, where Bi is the B of the ith input interface would provide some "flexibility". ii) Above relations should be clarified 2) "Rate constraint" reminds me discussions on "Fair Queuing". I believe, there are other ways to achieve "rate constraints" of EF in short-time scales. In this specific choice, "packet scale MAX-MIN rate guarantee R with latency E_a" is chosen. Is it okay to standardize this "rate constraint" by Diffserv group? (RFC-2598 has already achieved this) 3) It seems it is okay to "formulize" "delay constraint" by Diffserv group. I don't have any problem with accepting this. The choice of B will give lots of "flexibility"( Still, I believe, as an RFC this should left to implementations. There are "references". Let me relate this to AF PHB. I know they are intended for different purposes. I already said I don't have any problem of accepting this. AF doesn't standardize RIO, RED. However, it gives RIO, RED as a "specific" mechanism. I don't assume that someone who is supporting AF will come up with new mechanism to "replace" RIO other than someone from academia. RED is on the way to be accepted as AQM universally. However, for this new proposal, neither is on the way to be accepted as universally. 4) isn't this new proposal something new defined (more "expedited" than RFC-2598)? My 2 cents, Alper K. Demir _______________________________________________ diffserv mailing list diffserv@ietf.org http://www1.ietf.org/mailman/listinfo/diffserv Archive: http://www2.ietf.org/mail-archive/working-groups/diffserv/current/maillist.html From diffserv-admin@ietf.org Fri Dec 15 12:24: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 SMTP id MAA03684 for ; Fri, 15 Dec 2000 12:24:35 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id LAA05362; Fri, 15 Dec 2000 11:41:10 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id LAA05331 for ; Fri, 15 Dec 2000 11:41:05 -0500 (EST) Received: from sj-msg-core-2.cisco.com (sj-msg-core-2.cisco.com [171.69.43.88]) by ietf.org (8.9.1a/8.9.1a) with SMTP id LAA20619 for ; Fri, 15 Dec 2000 11:41:03 -0500 (EST) Received: from p7020-img-nt.cisco.com (sj-dial-3-200.cisco.com [171.68.180.201]) by sj-msg-core-2.cisco.com (8.9.3/8.9.1) with ESMTP id IAA06818; Fri, 15 Dec 2000 08:40:35 -0800 (PST) Message-Id: <5.0.2.1.2.20001214154513.03a02ec0@flipper.cisco.com> X-Sender: fred@flipper.cisco.com X-Mailer: QUALCOMM Windows Eudora Version 5.0.2 Date: Thu, 14 Dec 2000 16:12:04 -0800 To: Andrew Smith From: Fred Baker Subject: Re: [Diffserv] MIB - technical comments (part 1) Cc: diffserv In-Reply-To: <3A349D52.1080108@allegronetworks.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 Andrew: Kwok and I applied many to most of your comments; I'll let you see that when the diffs and new draft are posted over the weekend. We have a few more substantive comments, which I will call out, leaving out the "OK... OK..." stuff. At 01:24 AM 12/11/00 -0800, Andrew Smith wrote: >1. 2.1 (This comment is somewhat related to the ongoing discussion with >Bob Moore on the mailing list). A term is introduced here, "Data Path", >which is somewhat different to the "Datapath" idea used in the Model >draft. From [MODEL]: > "Datapath A conceptual path taken by packets with particular > characteristics through a Diffserv router. Decisions > as to the path taken by a packet are made by functional > datapath elements such as Classifiers and Meters." > >The usage in the MIB document is different to this i.e. it is single >interface, single direction. The last paragraph of 2.1 could also use some >clarification: e.g. >"The notion of a Datapath introduced in [MODEL] is used in this MIB to >indicate the DiffServ processing that a packet experiences as it travels >in a given direction ("in" or "out") of a given interface of a Diffserv >device. A diffServDataPathTable contains entries that indicate the first >of possibly multiple functional datapath elements that will apply DiffServ >treatment to the packet." > >That's closer to consistency. But then there's a comment down in the MIB: >"Each entry of the diffServQTable belongs to one and only one datapath." > >This is a more specific usage of "datapath" than up in 2.1: Is this >supposed to be saying that a datapath is the complete collection of >functional datapath elements that exist for a given {interface,direction} >combination? That would conflict with the usage in [MODEL] where it means >just a single potential path (and thus would allow multiple such paths to >merge into the same queue). As I understand your comment, I think it brings up a shortcoming in the model more than it does in the MIB. Example: ---> classifier ---> meter --> succeed actions --> queue | A | | +----> failure actions -----+ I believe that you just told me that the sequence including the "succeed actions" is one datapath, and the sequence including the "failure actions" is another data path, and that it is inappropriate to ever refer to the treatment of the entire class of traffic, including both succeed and failure actions and winding up in the same queue, as a single data path. I will argue that while the first two are obviously atomic data paths, the two together is an example of applying a PHB to a class of traffic, and constitutes an aggregate datapath. Personally, I'd rather widen the definition in the model than try to hobble the MIB. That said, I would be willing to remove the controversial sentence from the document. We did not, but if the working group wants to do that, fine. >9. 3 "DiffServ treatment parameterization" is used in several places: see >comment 3 above, but suggest we use some other existing terms e.g. >"paramterisation of DiffServ functional datapath elements". The word "treatment" has been used quite a bit to describe what we do to packets. I think this mostly adds to wordiness and therefore obfuscation without really clarifying anything. In a number of places, we swapped the word for "functional datapath", but by no means all. >12. 3.1 "Given some basic information, e.g. >ifIndex and interface direction, the first DiffServ Functional Element >is determined." >Define "first". Done, I think. "first" usually refers to the one that happens "before all the rest", and is fairly common in English... However, we stuck in "the first Diffserv Functional Datapath Element applied to a given packet on a given interface is determined." In another note, if you like, I could define "is"... _______________________________________________ diffserv mailing list diffserv@ietf.org http://www1.ietf.org/mailman/listinfo/diffserv Archive: http://www2.ietf.org/mail-archive/working-groups/diffserv/current/maillist.html From diffserv-admin@ietf.org Fri Dec 15 12: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 SMTP id MAA06216 for ; Fri, 15 Dec 2000 12:33:59 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id LAA05546; Fri, 15 Dec 2000 11:55:50 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id LAA05517 for ; Fri, 15 Dec 2000 11:55:46 -0500 (EST) Received: from mailhub1.almaden.ibm.com (mailhub1.almaden.ibm.com [198.4.83.44]) by ietf.org (8.9.1a/8.9.1a) with SMTP id LAA25432 for ; Fri, 15 Dec 2000 11:55:43 -0500 (EST) Received: from maui.almaden.ibm.com (maui.almaden.ibm.com [9.1.24.92]) by mailhub1.almaden.ibm.com (8.8.8/8.8.8) with ESMTP id IAA59448; Fri, 15 Dec 2000 08:51:46 -0800 Received: from hursley.ibm.com (gsine01.us.sine.ibm.com [9.14.6.41]) by maui.almaden.ibm.com (AIX4.3/8.9.3/8.7) with ESMTP id IAA32430; Fri, 15 Dec 2000 08:55:12 -0800 Message-ID: <3A3A374F.87D0F02F@hursley.ibm.com> Date: Fri, 15 Dec 2000 09:22:55 -0600 From: Brian E Carpenter Organization: IBM X-Mailer: Mozilla 4.61 [en] (Win98; I) X-Accept-Language: en,fr MIME-Version: 1.0 To: Gary Kenward CC: "'Grenville Armitage'" , Jon Bennett , diffserv@ietf.org Subject: Re: [Diffserv] Yesterday's EF discussion References: <13E2EF604DE5D111B2E50000F80824E8057A89F3@zwdld001.ca.nortel.com> Content-Type: text/plain; charset=iso-8859-1 X-MIME-Autoconverted: from quoted-printable to 8bit by optimus.ietf.org id LAA05518 Sender: diffserv-admin@ietf.org Errors-To: diffserv-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Diffserv Discussion List X-BeenThere: diffserv@ietf.org X-MIME-Autoconverted: from 8bit to quoted-printable by optimus.ietf.org id LAA05546 Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by ietf.org id MAA06216 Well, not having made a tape, I can't prove it, but I think the first question was "how many would accept 2 PHBs" and the final question was "how many would prefer only one", and it was the final question that got the more convincing response. Since people started leaving the room, I couldn't put the question one more time to be sure. Brian > Gary Kenward wrote: > > No, sorry. With all due respect to the wg chair, the phrasing of the questions > was illogical. > > The first question was "how many support two PHBs", for which there was > moderate response. The second question was "how many would not accept two PHBs", > for which there was a weaker response. > > The votes were not exclusive. The correct phrasing for the second question > should have been "how many support having only one PHB". > > While I many or many not support two PHBs, I *may* accept two PHBs when > faced with a less desirable alternative. > > Cheers, > Gary > > ========================================================================== > Gary W. Kenward gkenward@nortelnetworks.com > Advisor, Wireless Architecture (613) 765-1437 > Advanced Technology Labs ESN 395-1437 > Wireless Solutions FAX: (613) 763-2686 > Nortel Networks > ========================================================================== > > Plus ça change, plus c'est la même chose. > > The contents of this email are Nortel Networks Confidential > > > -----Original Message----- > > From: Grenville Armitage [mailto:gja@research.bell-labs.com] > > Sent: Thursday, December 14, 2000 2:50 PM > > To: Jon Bennett > > Cc: 'Brian E Carpenter'; diffserv@ietf.org > > Subject: Re: [Diffserv] Yesterday's EF discussion > > > > > > > > > > Jon Bennett wrote: > > [..] > > > the room was > > > also vastly opposed to two PHBs, > > > > This is so stunningly different to my recollection as to leave me > > wondering what rooms we were in. Standing quietly at the rear > > room, I saw (with my own two beady little eyes) the question > > of "can the WG accept two PHBs" receive more 'yes' than 'no'. > > > > (The crowd was certainly with charny-compromise on the different, > > and more specific question of which text to use *if* there was to > > be only one PHB. But that *is* a different question.) > > > > cheers, > > gja > > > > _______________________________________________ > > diffserv mailing list > > diffserv@ietf.org > > http://www1.ietf.org/mailman/listinfo/diffserv > > Archive: > http://www2.ietf.org/mail-archive/working-groups/diffserv/current/maillist.html -- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - Brian E Carpenter Program Director, Internet Standards & Technology, IBM On assignment for IBM at http://www.iCAIR.org Board Chairman, Internet Society http://www.isoc.org Non-IBM email: brian@icair.org _______________________________________________ diffserv mailing list diffserv@ietf.org http://www1.ietf.org/mailman/listinfo/diffserv Archive: http://www2.ietf.org/mail-archive/working-groups/diffserv/current/maillist.html From diffserv-admin@ietf.org Fri Dec 15 12:41:54 2000 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with SMTP id MAA08770 for ; Fri, 15 Dec 2000 12:41:53 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id LAA05324; Fri, 15 Dec 2000 11:40:54 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id LAA05293 for ; Fri, 15 Dec 2000 11:40:47 -0500 (EST) Received: from sj-msg-core-2.cisco.com (sj-msg-core-2.cisco.com [171.69.43.88]) by ietf.org (8.9.1a/8.9.1a) with SMTP id LAA20495 for ; Fri, 15 Dec 2000 11:40:45 -0500 (EST) Received: from p7020-img-nt.cisco.com (sj-dial-3-200.cisco.com [171.68.180.201]) by sj-msg-core-2.cisco.com (8.9.3/8.9.1) with ESMTP id IAA06535; Fri, 15 Dec 2000 08:40:12 -0800 (PST) Message-Id: <5.0.2.1.2.20001214122954.02508dd0@flipper.cisco.com> X-Sender: fred@flipper.cisco.com X-Mailer: QUALCOMM Windows Eudora Version 5.0.2 Date: Thu, 14 Dec 2000 12:30:49 -0800 To: Andrew Smith From: Fred Baker Subject: Re: [Diffserv] Counters in the classifier Cc: Kathleen Nichols , diffserv@ietf.org In-Reply-To: <3A380C45.90105@allegronetworks.com> References: <5.0.2.1.2.20001213100135.0308d050@flipper.cisco.com> <3A37F797.F49575E6@packetdesign.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: diffserv-admin@ietf.org Errors-To: diffserv-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Diffserv Discussion List X-BeenThere: diffserv@ietf.org At 03:54 PM 12/13/00 -0800, Andrew Smith wrote: >I'm also a bit confused as to whether Fred's proposal *replaces* the >existing "counter action" material in the MIB or is in addition to it. And >is this addition/change expected to be rolled back into the Model draft also? it is in addition, and it need not be in the model. it is a debug tool for the classifier; the count action is an accounting tool of sorts for the SLA. _______________________________________________ diffserv mailing list diffserv@ietf.org http://www1.ietf.org/mailman/listinfo/diffserv Archive: http://www2.ietf.org/mail-archive/working-groups/diffserv/current/maillist.html From diffserv-admin@ietf.org Fri Dec 15 13:19:41 2000 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with SMTP id NAA20906 for ; Fri, 15 Dec 2000 13:19:41 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id MAA06828; Fri, 15 Dec 2000 12:52:36 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id MAA06794 for ; Fri, 15 Dec 2000 12:52:31 -0500 (EST) Received: from diablo.cisco.com (diablo.cisco.com [171.68.224.210]) by ietf.org (8.9.1a/8.9.1a) with SMTP id MAA12100 for ; Fri, 15 Dec 2000 12:52:30 -0500 (EST) Received: from jschnizl1-pc (ssh-sj1.cisco.com [171.68.225.134]) by diablo.cisco.com (8.8.6 (PHNE_14041)/CISCO.SERVER.1.2) with SMTP id JAA14807; Fri, 15 Dec 2000 09:51:27 -0800 (PST) Message-Id: <4.1.20001215124717.00a2b960@diablo.cisco.com> X-Sender: jschnizl@localhost X-Mailer: QUALCOMM Windows Eudora Pro Version 4.1 Date: Fri, 15 Dec 2000 12:49:19 -0500 To: "Scott Brim" From: John Schnizlein Subject: Re: [Diffserv] A revised expression of the Expedited Forwarding PHB Cc: Larry Ayres , diffserv@ietf.org In-Reply-To: <14905.18001.925155.288693@localhost.localdomain> References: <4.1.20001214163942.00a15b80@diablo.cisco.com> <3.0.1.32.20001214125613.00aa2610@mail.acc.com> <4.1.20001214163942.00a15b80@diablo.cisco.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 Of course, you are right. The interpretation I (wrongly) endorsed would imply traffic rate meters where they are not intended by the diffserv architecture. John At 02:14 PM 12/14/2000 -0800, Scott Brim wrote: >On 14 Dec 2000 at 16:40 -0500, John Schnizlein apparently wrote: >> At 12:56 PM 12/14/2000 -0800, Larry Ayres wrote: >> >It seems to me that the first sentence on page 3 which reads: >> > >> >If more EF traffic arrives than is acceptable, the device is NOT REQUIRED >> >to deliver the EF behavior. >> > >> >is meant to convey: >> > >> >If more EF traffic arrives than is acceptable, the device is NOT REQUIRED >> >to deliver the EF behavior to the excess traffic. >> > >> >Am I right in this interpretation ? >> >> Yes. > >Um, except that implies to me a requirement that the forwarder >discriminate between traffic which is "excess" and traffic which is not. >The top version is better in that respect. > >...Scott _______________________________________________ diffserv mailing list diffserv@ietf.org http://www1.ietf.org/mailman/listinfo/diffserv Archive: http://www2.ietf.org/mail-archive/working-groups/diffserv/current/maillist.html From diffserv-admin@ietf.org Fri Dec 15 13:19: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 SMTP id NAA21007 for ; Fri, 15 Dec 2000 13:19:57 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id MAA06765; Fri, 15 Dec 2000 12:51:26 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id MAA06734 for ; Fri, 15 Dec 2000 12:51:21 -0500 (EST) Received: from mailhub1.almaden.ibm.com (mailhub1.almaden.ibm.com [198.4.83.44]) by ietf.org (8.9.1a/8.9.1a) with SMTP id MAA11740 for ; Fri, 15 Dec 2000 12:51:20 -0500 (EST) Received: from maui.almaden.ibm.com (maui.almaden.ibm.com [9.1.24.92]) by mailhub1.almaden.ibm.com (8.8.8/8.8.8) with ESMTP id JAA36040; Fri, 15 Dec 2000 09:47:22 -0800 Received: from hursley.ibm.com (gsine01.us.sine.ibm.com [9.14.6.41]) by maui.almaden.ibm.com (AIX4.3/8.9.3/8.7) with ESMTP id JAA22376; Fri, 15 Dec 2000 09:50:51 -0800 Message-ID: <3A3A59AA.51639AE@hursley.ibm.com> Date: Fri, 15 Dec 2000 11:49:30 -0600 From: Brian E Carpenter Organization: IBM X-Mailer: Mozilla 4.61 [en] (Win98; I) X-Accept-Language: en,fr MIME-Version: 1.0 To: Jon Bennett CC: diffserv@ietf.org Subject: Re: [Diffserv] Yesterday's EF discussion References: <7F4AC78738EAD2119D86009027626C6D889028@packetbdc.riverdelta.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: diffserv-admin@ietf.org Errors-To: diffserv-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Diffserv Discussion List X-BeenThere: diffserv@ietf.org Content-Transfer-Encoding: 7bit Jon, Jon Bennett wrote: > > Brian, > > > Jon, just an (obvious) point of clarification: RFC 2598 will not go > > away - it will stay there for ever, presumably marked in the index as > > (Obsoleted by RFCxxxx). > > Question to the chair, given that I said our intentions were "to obsolete > RFC 2598" what was it that you were clarifying? Or were you just worried I > didn't know 'to obsolete' meant? This snip from your earlier note seemed to me to suggest that you thought I might be suggesting *not* to obsolete 2598, which was not what I meant to imply: "I submit that leaving RFC 2598 unchanged as the EF PHB and introducing draft-charny as the FOO PHB besides violating the WG charter is simply to ignore the consensus of the room." Brian _______________________________________________ diffserv mailing list diffserv@ietf.org http://www1.ietf.org/mailman/listinfo/diffserv Archive: http://www2.ietf.org/mail-archive/working-groups/diffserv/current/maillist.html From diffserv-admin@ietf.org Fri Dec 15 13:33: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 SMTP id NAA25739 for ; Fri, 15 Dec 2000 13:33:15 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id MAA06962; Fri, 15 Dec 2000 12:59:05 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id MAA06934 for ; Fri, 15 Dec 2000 12:59:01 -0500 (EST) Received: from diablo.cisco.com (diablo.cisco.com [171.68.224.210]) by ietf.org (8.9.1a/8.9.1a) with SMTP id MAA14145 for ; Fri, 15 Dec 2000 12:59:00 -0500 (EST) Received: from jschnizl1-pc (ssh-sj1.cisco.com [171.68.225.134]) by diablo.cisco.com (8.8.6 (PHNE_14041)/CISCO.SERVER.1.2) with SMTP id JAA14787; Fri, 15 Dec 2000 09:51:26 -0800 (PST) Message-Id: <4.1.20001215124331.00974ad0@diablo.cisco.com> X-Sender: jschnizl@localhost X-Mailer: QUALCOMM Windows Eudora Pro Version 4.1 Date: Fri, 15 Dec 2000 12:46:21 -0500 To: "Ralph Santitoro" , diffserv@ietf.org From: John Schnizlein Subject: RE: [Diffserv] Yesterday's EF discussion In-Reply-To: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: diffserv-admin@ietf.org Errors-To: diffserv-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Diffserv Discussion List X-BeenThere: diffserv@ietf.org At 06:01 PM 12/14/2000 -0500, Ralph Santitoro wrote: >... vendors have already implemented their interpretation of >the 'EF' PHB and its associated 'EF' DSCP. >Therefore, the 'EF' term is proliferated in a variety of product >literature, whitepapers, marketing literature, engineering documentation, >training courseware and device/service configuration tools. Which vendors? What do you mean by "implemented"? Whitepapers and marketing literature should follow (not restrict) the standards language. I do not know a vendor that does otherwise. John _______________________________________________ diffserv mailing list diffserv@ietf.org http://www1.ietf.org/mailman/listinfo/diffserv Archive: http://www2.ietf.org/mail-archive/working-groups/diffserv/current/maillist.html From diffserv-admin@ietf.org Fri Dec 15 13:33:52 2000 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with SMTP id NAA25991 for ; Fri, 15 Dec 2000 13:33:52 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id NAA07144; Fri, 15 Dec 2000 13:01:00 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id NAA07112 for ; Fri, 15 Dec 2000 13:00:55 -0500 (EST) Received: from diablo.cisco.com (diablo.cisco.com [171.68.224.210]) by ietf.org (8.9.1a/8.9.1a) with SMTP id NAA14731 for ; Fri, 15 Dec 2000 13:00:54 -0500 (EST) Received: from jschnizl1-pc (ssh-sj1.cisco.com [171.68.225.134]) by diablo.cisco.com (8.8.6 (PHNE_14041)/CISCO.SERVER.1.2) with SMTP id KAA23043; Fri, 15 Dec 2000 10:00:19 -0800 (PST) Message-Id: <4.1.20001215125733.00983ba0@diablo.cisco.com> X-Sender: jschnizl@localhost X-Mailer: QUALCOMM Windows Eudora Pro Version 4.1 Date: Fri, 15 Dec 2000 13:00:17 -0500 To: Dave McDysan From: John Schnizlein Subject: RE: [Diffserv] Yesterday's EF discussion Cc: Diff Serv In-Reply-To: References: <3A3903FC.69621E7D@hursley.ibm.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: diffserv-admin@ietf.org Errors-To: diffserv-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Diffserv Discussion List X-BeenThere: diffserv@ietf.org At 07:15 PM 12/14/2000 -0500, Dave McDysan wrote: > >For me, Expedited Forwarding is an easy to explain reference to >priority queuing, which by all accounts is a viable implementation >of this PHB (with limits to protect other traffic, as stated in 2598). Yes, I suspect this interpretation of "implementation" is all there is. I begs the question of how these implementations depend on a rate guarantee over a fixed interval. Last time I looked, priority queuing just drains the high priority queue at line rate. John _______________________________________________ diffserv mailing list diffserv@ietf.org http://www1.ietf.org/mailman/listinfo/diffserv Archive: http://www2.ietf.org/mail-archive/working-groups/diffserv/current/maillist.html From diffserv-admin@ietf.org Fri Dec 15 13:35: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 SMTP id NAA26741 for ; Fri, 15 Dec 2000 13:35:40 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id MAA06910; Fri, 15 Dec 2000 12:57:32 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id MAA06873 for ; Fri, 15 Dec 2000 12:57:27 -0500 (EST) Received: from zcars04f.ca.nortel.com (h57s242a129n47.user.nortelnetworks.com [47.129.242.57]) by ietf.org (8.9.1a/8.9.1a) with SMTP id MAA13623; Fri, 15 Dec 2000 12:57:22 -0500 (EST) Message-Id: <200012151757.MAA13623@ietf.org> Received: from zcard00m.ca.nortel.com by zcars04f.ca.nortel.com; Fri, 15 Dec 2000 12:56:37 -0500 Received: from zbl6c002.corpeast.baynetworks.com ([132.245.205.52]) by zcard00m.ca.nortel.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2652.39) id YP1FG1K9; Fri, 15 Dec 2000 12:56:37 -0500 Received: from TWEEDY ([47.16.5.107]) by zbl6c002.corpeast.baynetworks.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2652.39) id YJ8X8R61; Fri, 15 Dec 2000 12:56:36 -0500 X-Sender: khchan@zbl6c002.corpeast.baynetworks.com X-Mailer: QUALCOMM Windows Eudora Pro Version 4.0 Date: Fri, 15 Dec 2000 12:55:06 -0500 To: Andy Bierman X-Sybari-Space: 00000000 00000000 00000000 From: "Kwok-Ho Chan" Subject: Re: [Diffserv] The DsCodePoint definition Cc: Andrew Smith , "Wijnen, Bert (Bert)" , Harrie Hazewinkel , "Kwok-Ho Chan" , rmonmib@ietf.org, diffserv@ietf.org In-Reply-To: <3A37BCCA.7901C1F@cisco.com> References: <2413FED0DFE6D111B3F90008C7FA61FB0A6E0DFC@nl0006exch002u.nl.lucent.com> <3A3711A1.7060202@allegronetworks.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" X-Orig: Sender: diffserv-admin@ietf.org Errors-To: diffserv-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Diffserv Discussion List X-BeenThere: diffserv@ietf.org Andy: I have created a new module in the Diff Serv MIB to hold the 2 new DSCP TCs. You don't need to reference the whole Diff Serv MIB, just the DSCP TC Module. I hope this help for you to reference the DSCP TC definition from the DiffServ WG. Right now the 2 TCs in DSMIB-07 are Dscp (0..63) and DscpOrAny (-1 | 0..63). This will be published this coming weekend in Diff Serv MIB -07. Other than requiring an import in the RMON MIB to get the DSCP TC, is there any technical issue in using a common DSCP TC definition? Would like to do what I can to resolve this. Thanks! -- Kwok -- At 10:15 AM 12/13/00 -0800, Andy Bierman wrote: >Andrew Smith wrote: >> >> 2 TCs defined in the same MIB module, to be precise. >> > >I disagree. >There is no need for the DSMON MIB to have a normative >reference to the DIFFSERV MIB. > >The primary focus of RMON is collect statistics based on >observable characteristics of network traffic. RFC 2474 >specifies the observable attributes of a packet containing >a DSCP field. The REFERENCE clause in the DsCodePoint TC >properly identifies RFC 2474, and no additional coupling to >any other documents is required. > >BTW, SMIv2 does not allow a TC to be defined as a variant of >another TC, so Harrie's suggestion won't work. > >> Andrew > >Andy > >> >> Wijnen, Bert (Bert) wrote: >> >> > Comments inline >> > >> > >> >> ---------- >> >> From: Andy Bierman[SMTP:abierman@cisco.com] >> >> Sent: Tuesday, December 12, 2000 9:07 PM >> >> To: Harrie Hazewinkel >> >> Cc: rmonmib@ietf.org; diffserv@ietf.org >> >> Subject: Re: [Diffserv] The DsCodePoint definition >> >> >> >> Harrie Hazewinkel wrote: >> >> >> >>> HI, >> >>> >> >>> I was wondering why there is a difference between >> >>> 2 definitions of the DiffServ CodePoint in different >> >>> MIB modules. The two different MIMB modules are >> >>> the DIFFSERV-MIB (of diffserv) and the DSMON-MIB (of RMON). >> >>> >> >>> I beleive these 2 TCs should be the same and taken from the >> >>> DIFFSERV-MIB, because that is from the diffserv WG. >> >>> >> >>> ----------- From the DIFFSERV-MIB (draft 05) ----------------- >> >>> Dscp ::= TEXTUAL-CONVENTION >> >>> DISPLAY-HINT "d" >> >>> STATUS current >> >>> DESCRIPTION >> >>> "The IP header Diffserv Code-Point that may be used >> >>> for discriminating or marking a traffic stream. The >> >>> value -1 ( 4294967295 for Integer32 ) is used to >> >>> indicate a wildcard i.e. any value." >> >>> SYNTAX Integer32 (4294967295 | 0..63) >> >> >> >> just noticed how broken this TC is... >> >> 1) an Integer32 object cannot contain the value 4294967295 >> > >> > I have made that comments to the Diffserv list already, and they >> > will need to fix it with using -1 >> > >> >> 2) missing REFERENCE clause >> >> (where exactly in 2474 is the 'wildcard' DSCP value discussed?) >> > >> > Yep, this one was raised by someone else (was it Andrew?) >> > >> > But the important thing, we need a fixed TC that is usable by both >> > MIBs I think. Or maybe 2 TCs as I also suggested on the diffserv >> > list. >> > >> > Bert >> > >> > >> >> Andy >> >> >> >> >> >>> -------------------------------------------------------------- >> >>> >> >>> ------------ From the DSMON-MIB (draft 03) ------------------- >> >>> DsmonDSCodePoint ::= TEXTUAL-CONVENTION >> >>> STATUS current >> >>> DESCRIPTION >> >>> "This TC describes an object which identifies the >> >>> Differentiated Services Codepoint (DSCP) value found within >> >>> the DS field in a network layer packet header (e.g., IPv4 >> >>> and IPv6)." >> >>> REFERENCE >> >>> "Definition of the Differentiated Services Field (DS Field) >> >>> in the IPv4 and IPv6 Headers [RFC2474]." >> >>> SYNTAX Integer32 (0..63) >> >>> -------------------------------------------------------------- >> >>> >> >>> OK, I will admit the definition of the DiffServ-MIB is currently >> >>> broken, but that will be fixed (this week at the IETF, I hope). >> >>> >> >>> Harrie > >_______________________________________________ >diffserv mailing list >diffserv@ietf.org >http://www1.ietf.org/mailman/listinfo/diffserv >Archive: http://www2.ietf.org/mail-archive/working-groups/diffserv/current/maillist.h tml > _______________________________________________ diffserv mailing list diffserv@ietf.org http://www1.ietf.org/mailman/listinfo/diffserv Archive: http://www2.ietf.org/mail-archive/working-groups/diffserv/current/maillist.html From diffserv-admin@ietf.org Fri Dec 15 13:36:51 2000 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with SMTP id NAA27199 for ; Fri, 15 Dec 2000 13:36:46 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id NAA07207; Fri, 15 Dec 2000 13:02:37 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id NAA07175 for ; Fri, 15 Dec 2000 13:02:31 -0500 (EST) Received: from packetbdc.packettech.com (packetbdc.riverdelta.com [198.112.190.11]) by ietf.org (8.9.1a/8.9.1a) with SMTP id NAA15193 for ; Fri, 15 Dec 2000 13:02:29 -0500 (EST) Received: by packetbdc.riverdelta.com with Internet Mail Service (5.5.2650.21) id ; Fri, 15 Dec 2000 13:03:54 -0500 Message-ID: <7F4AC78738EAD2119D86009027626C6D88902F@packetbdc.riverdelta.com> From: Jon Bennett To: "'Brian E Carpenter'" , Jon Bennett Cc: diffserv@ietf.org Subject: RE: [Diffserv] Yesterday's EF discussion Date: Fri, 15 Dec 2000 13:03:49 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: text/plain; charset="iso-8859-1" Sender: diffserv-admin@ietf.org Errors-To: diffserv-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Diffserv Discussion List X-BeenThere: diffserv@ietf.org Brian, > > Question to the chair, given that I said our intentions > were "to obsolete > > RFC 2598" what was it that you were clarifying? Or were > you just worried I > > didn't know 'to obsolete' meant? > > This snip from your earlier note seemed to me to suggest that > you thought > I might be suggesting *not* to obsolete 2598, which was not > what I meant to imply: > > "I submit that leaving RFC 2598 unchanged as > the EF PHB and introducing draft-charny as the FOO PHB > besides violating the > WG charter is simply to ignore the consensus of the room." Ah I see, I was using the word 'unchanged' in an ambiguous manner, I was just referring to changing the definition of EF from 2598 to the new RFC we are going to write, not with changing the text of 2598. I was confused by what you said since I assumed that given the frequency that I have been quoting RFC 2026 over the last week or so that you would have known that I knew you don't change an existing RFC....... you obsolete it. jon _______________________________________________ diffserv mailing list diffserv@ietf.org http://www1.ietf.org/mailman/listinfo/diffserv Archive: http://www2.ietf.org/mail-archive/working-groups/diffserv/current/maillist.html From diffserv-admin@ietf.org Fri Dec 15 13:44: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 SMTP id NAA00096 for ; Fri, 15 Dec 2000 13:44:32 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id NAA07338; Fri, 15 Dec 2000 13:09:55 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id NAA07308 for ; Fri, 15 Dec 2000 13:09:50 -0500 (EST) Received: from zcars04f.ca.nortel.com (h57s242a129n47.user.nortelnetworks.com [47.129.242.57]) by ietf.org (8.9.1a/8.9.1a) with SMTP id NAA17549 for ; Fri, 15 Dec 2000 13:09:49 -0500 (EST) Message-Id: <200012151809.NAA17549@ietf.org> Received: from zcard00m.ca.nortel.com by zcars04f.ca.nortel.com; Fri, 15 Dec 2000 13:03:45 -0500 Received: from zbl6c002.corpeast.baynetworks.com ([132.245.205.52]) by zcard00m.ca.nortel.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2652.39) id YP1FGFNW; Fri, 15 Dec 2000 13:03:45 -0500 Received: from TWEEDY ([47.16.5.107]) by zbl6c002.corpeast.baynetworks.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2652.39) id YJ8X8R6J; Fri, 15 Dec 2000 13:03:44 -0500 X-Sender: khchan@zbl6c002.corpeast.baynetworks.com X-Mailer: QUALCOMM Windows Eudora Pro Version 4.0 Date: Fri, 15 Dec 2000 13:02:19 -0500 To: Kathleen Nichols X-Sybari-Space: 00000000 00000000 00000000 From: "Kwok-Ho Chan" Subject: Re: [Diffserv] Counters in the classifier Cc: Fred Baker , diffserv@ietf.org In-Reply-To: <3A37F797.F49575E6@packetdesign.com> References: <5.0.2.1.2.20001213100135.0308d050@flipper.cisco.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" X-Orig: Sender: diffserv-admin@ietf.org Errors-To: diffserv-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Diffserv Discussion List X-BeenThere: diffserv@ietf.org This is in DSMIB-07 right now, containing only the packet counter as we agreed, in diffServClfrElementTable entry. Speak now or hold your peace :). -- Kwok -- At 02:26 PM 12/13/00 -0800, Kathleen Nichols wrote: > > >Fred Baker wrote: >... >> >> So this is my proposal. Kwok and I are editing the MIB this morning, with a >> view to this outcome, Andrew's comments, and some comments from Bert >> relating to TCs (want to pull them together into a separate module and do >> some minor tweaks). We will put in a packet counter in the classifier, and >> the chairs can tell us we did it wrong. >> >> Your comments, please. >> > >Fred, I think what you are saying reflects what we talked >about before Monday's meeting: you have to set up a classifier >if you want to count (a particular DSCP for example). If >this is so, I certainly support that and thought we emerged >from that meeting with out any real case made for anything >else. > > Kathie > >_______________________________________________ >diffserv mailing list >diffserv@ietf.org >http://www1.ietf.org/mailman/listinfo/diffserv >Archive: http://www2.ietf.org/mail-archive/working-groups/diffserv/current/maillist.h tml > _______________________________________________ diffserv mailing list diffserv@ietf.org http://www1.ietf.org/mailman/listinfo/diffserv Archive: http://www2.ietf.org/mail-archive/working-groups/diffserv/current/maillist.html From diffserv-admin@ietf.org Fri Dec 15 13:50: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 SMTP id NAA02023 for ; Fri, 15 Dec 2000 13:50:13 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id NAA07569; Fri, 15 Dec 2000 13:18:20 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id NAA07537 for ; Fri, 15 Dec 2000 13:18:16 -0500 (EST) Received: from ertpg14e1.nortelnetworks.com (ertpg14e1.nortelnetworks.com [47.234.0.35]) by ietf.org (8.9.1a/8.9.1a) with SMTP id NAA20432 for ; Fri, 15 Dec 2000 13:18:14 -0500 (EST) Message-Id: <200012151818.NAA20432@ietf.org> Received: from zbl6c016.corpeast.baynetworks.com (actually zbl6c016) by ertpg14e1.nortelnetworks.com; Fri, 15 Dec 2000 13:12:25 -0500 Received: from zbl6c002.corpeast.baynetworks.com ([132.245.205.52]) by zbl6c016.corpeast.baynetworks.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2652.39) id W8KSQJY6; Fri, 15 Dec 2000 13:12:22 -0500 Received: from TWEEDY ([47.16.5.107]) by zbl6c002.corpeast.baynetworks.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2652.39) id YJ8X8R67; Fri, 15 Dec 2000 13:12:23 -0500 X-Sender: khchan@zbl6c002.corpeast.baynetworks.com X-Mailer: QUALCOMM Windows Eudora Pro Version 4.0 Date: Fri, 15 Dec 2000 13:10:58 -0500 To: Yasusi Kanada X-Sybari-Space: 00000000 00000000 00000000 From: "Kwok-Ho Chan" Cc: diffserv , "Kwok-Ho Chan" , crl In-Reply-To: <20001214162341.27039@ff.iij4u.or.jp> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Subject: [Diffserv] Re: WIRR in Diffserv PIB Sender: diffserv-admin@ietf.org Errors-To: diffserv-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Diffserv Discussion List X-BeenThere: diffserv@ietf.org Yasusi: WIRR will NOT be in the next version of DiffServ PIB. Currently DiffServ PIB-02 maps to DiffServ MIB-05. We are planning to upgrade DiffServ PIB-03 to sync with the Last Call version of DiffServ MIB (DS MIB-07 as we see it today), which does not contain WIRR. I will be happy to talk to you on a personal basis after I get DiffServ MIB-07 out. Thanks! -- Kwok -- At 08:23 AM 12/14/00 -0800, Yasusi Kanada wrote: >In qosIfSchedulingCapsServiceDisc and qosSchedulerMethod in >diffserv-pib-02, there is a scheduling algorithm called "wirr". >(weighted interleaved roundrobin queueing (?) scheduling). >However, there is no real explanation on this. If you keep >this categorization in the next version of the draft, please >add an explanation in Section 4.6.3. I am not sure the >difference between "wrr" and "wirr", and I am not sure why >they should be distinguished. Thanks. > >--- >Yasusi Kanada, Ph.D, WWW: http://www.kanadas.com/ >Email: kanada@crl.hitachi.co.jp (day), yasusi@kanadas.com (night) >Network SE/SI Research Dept., IP Network Research Center., Hitachi Ltd. >Totsuka-ku Yoshida-cho 292, Yokohama, 244-0817, Japan >--- > _______________________________________________ diffserv mailing list diffserv@ietf.org http://www1.ietf.org/mailman/listinfo/diffserv Archive: http://www2.ietf.org/mail-archive/working-groups/diffserv/current/maillist.html From diffserv-admin@ietf.org Fri Dec 15 15:41:24 2000 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with SMTP id PAA07191 for ; Fri, 15 Dec 2000 15:41:24 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id PAA09327; Fri, 15 Dec 2000 15:01:41 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id PAA09298 for ; Fri, 15 Dec 2000 15:01:37 -0500 (EST) Received: from sj-msg-core-4.cisco.com (sj-msg-core-4.cisco.com [171.71.163.10]) by ietf.org (8.9.1a/8.9.1a) with SMTP id PAA24589 for ; Fri, 15 Dec 2000 15:01:35 -0500 (EST) Received: from bdaviepc.cisco.com (dhcp-10-34-54-156.cisco.com [10.34.54.156]) by sj-msg-core-4.cisco.com (8.9.3/8.9.1) with SMTP id MAA13967 for ; Fri, 15 Dec 2000 12:01:03 -0800 (PST) From: "Bruce Davie" To: "Diffserv@Ietf. Org" Subject: Re: [Diffserv] Yesterday's EF discussion Date: Fri, 15 Dec 2000 15:01:24 -0500 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2910.0) Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2314.1300 Content-Transfer-Encoding: 7bit Sender: diffserv-admin@ietf.org Errors-To: diffserv-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Diffserv Discussion List X-BeenThere: diffserv@ietf.org Content-Transfer-Encoding: 7bit One observation that I might make about the current debate on re-naming EF is that it resembles the debate in front of the WG on Tuesday. Proponents of EFRESOLVE are basically saying "draft-charny is a fine PHB definition, it just isn't EF" which is exactly what they said on Tuesday. I believe the WG voted to reject that position when it voted in favor of adopting draft-charny as the basis for a replacement for RFC 2598. So we seem to be simply rehashing an argument that was settled on Tuesday, with the same proponents on both sides. As has already been said, this is simply ignoring the WG consensus. Bruce _______________________________________________ diffserv mailing list diffserv@ietf.org http://www1.ietf.org/mailman/listinfo/diffserv Archive: http://www2.ietf.org/mail-archive/working-groups/diffserv/current/maillist.html From diffserv-admin@ietf.org Fri Dec 15 16:42:54 2000 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with SMTP id QAA26767 for ; Fri, 15 Dec 2000 16:42:54 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id QAA10186; Fri, 15 Dec 2000 16:07:17 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id QAA10159 for ; Fri, 15 Dec 2000 16:07:13 -0500 (EST) Received: from packetbdc.packettech.com (packetbdc.riverdelta.com [198.112.190.11]) by ietf.org (8.9.1a/8.9.1a) with SMTP id QAA15275 for ; Fri, 15 Dec 2000 16:07:10 -0500 (EST) Received: by packetbdc.riverdelta.com with Internet Mail Service (5.5.2650.21) id ; Fri, 15 Dec 2000 16:08:37 -0500 Message-ID: <7F4AC78738EAD2119D86009027626C6D889031@packetbdc.riverdelta.com> From: Jon Bennett To: "'John Schnizlein'" , Dave McDysan Cc: Diff Serv Subject: RE: [Diffserv] Yesterday's EF discussion Date: Fri, 15 Dec 2000 16:08:35 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: text/plain; charset="iso-8859-1" Sender: diffserv-admin@ietf.org Errors-To: diffserv-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Diffserv Discussion List X-BeenThere: diffserv@ietf.org John, > >For me, Expedited Forwarding is an easy to explain reference to > >priority queuing, which by all accounts is a viable implementation > >of this PHB (with limits to protect other traffic, as stated > in 2598). > > Yes, I suspect this interpretation of "implementation" is all > there is. I begs the question of how these implementations depend > on a rate guarantee over a fixed interval. Last time I looked, > priority queuing just drains the high priority queue at line rate. Ok, let me explain to you why EF or any other PHB can't be "just priority queueing" at least not if you want to build equipment that does anything else beyond just doing EF. Consider the following issues, all of which are considerations for me in the equipment I am building. A) If you are building equipment to support "open access" i.e. multiple ISPs sharing the same box, then you will have say 16 ISPs sharing the uplink back to the network, each of these ISPs will want its own EF PHB, they are not going to want to share a single EF PHB, and you can't service one ISP at higher priority than another, so your service for the EF PHB will be based on a bandwidth share of the output link and not based on priority access to it. B) If you are building equipment to support more than one instance of the EF PHB at a time (within a single ISP's traffic) as you might want to do to support different rate EF traffic or you have some EF traffic which is low bandwidth/low jitter EF and some which is high bandwidth/moderate jitter EF. In order to prevent the low jitter EF from making all other EF traffic into high jitter traffic, the scheduling between the different EF PHBs can not be done by strict priority but has to be by bandwidth shares. C) If you are building equipment to support both Diffserv EF and Intserv GS in the same device, and have many ports and/or channelized ports with EF traffic you can not service the EF traffic with strict priority over the GS traffic without impacting the delay/error bounds of the GS traffic. In particular without route pinning for the EF traffic it would be impossible to make any guarantees to the GS traffic because variations in the EF routing could reduce the capacity below that needed to support existing GS reservations unless rate based scheduling was used instead of priority scheduling. I could go on listing items, but the basic point is that in an actual multi-service operated under real requirements, you can't go and say "EF has the highest priority of all traffic", you can say "EF has the highest priority of all traffic, within a given slice of the link bandwidth", and that means we are talking about a rate based behavior and not a priority behavior. jon _______________________________________________ diffserv mailing list diffserv@ietf.org http://www1.ietf.org/mailman/listinfo/diffserv Archive: http://www2.ietf.org/mail-archive/working-groups/diffserv/current/maillist.html From diffserv-admin@ietf.org Fri Dec 15 16:55: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 SMTP id QAA01011 for ; Fri, 15 Dec 2000 16:55:36 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id QAA10413; Fri, 15 Dec 2000 16:26:03 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id QAA10355 for ; Fri, 15 Dec 2000 16:25:58 -0500 (EST) Received: from sj-msg-core-2.cisco.com (sj-msg-core-2.cisco.com [171.69.43.88]) by ietf.org (8.9.1a/8.9.1a) with SMTP id QAA21728; Fri, 15 Dec 2000 16:25:55 -0500 (EST) Received: from sj-msg-av-1.cisco.com (sj-msg-av-1.cisco.com [171.69.11.130]) by sj-msg-core-2.cisco.com (8.9.3/8.9.1) with ESMTP id NAA02406; Fri, 15 Dec 2000 13:24:51 -0800 (PST) Received: from mailman.cisco.com (localhost [127.0.0.1]) by sj-msg-av-1.cisco.com (8.10.1/8.10.1) with ESMTP id eBFLP2N03079; Fri, 15 Dec 2000 13:25:02 -0800 (PST) Received: from cisco.com (ssh-sj1.cisco.com [171.68.225.134]) by mailman.cisco.com (8.9.3/8.9.1) with ESMTP id NAA02382; Fri, 15 Dec 2000 13:24:47 -0800 (PST) Message-ID: <3A3A8C64.17C9E9CD@cisco.com> Date: Fri, 15 Dec 2000 13:25:56 -0800 From: Andy Bierman Organization: Cisco Systems, Inc. X-Mailer: Mozilla 4.73 [en] (Win98; U) X-Accept-Language: en MIME-Version: 1.0 To: Kwok-Ho Chan CC: Andrew Smith , "Wijnen, Bert (Bert)" , Harrie Hazewinkel , rmonmib@ietf.org, diffserv@ietf.org Subject: Re: [Diffserv] The DsCodePoint definition References: <2413FED0DFE6D111B3F90008C7FA61FB0A6E0DFC@nl0006exch002u.nl.lucent.com> <3A3711A1.7060202@allegronetworks.com> <200012151755.JAA00454@proxy2.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 Kwok-Ho Chan wrote: > > Andy: > I have created a new module in the Diff Serv MIB to hold the 2 new DSCP TCs. > You don't need to reference the whole Diff Serv MIB, just the DSCP TC Module. > I hope this help for you to reference the DSCP TC definition from the > DiffServ WG. > Right now the 2 TCs in DSMIB-07 are Dscp (0..63) and DscpOrAny (-1 | 0..63). > This will be published this coming weekend in Diff Serv MIB -07. > Other than requiring an import in the RMON MIB to get the DSCP TC, > is there any technical issue in using a common DSCP TC definition? > Would like to do what I can to resolve this. I did not agree to this change. I don't think it's a good idea to couple the progress of the DSMON MIB RFC to the DIFFSERV MIB RFC. The DSMON MIB module will (potentially) be held up at each level of publication, waiting for any or all of the MIB modules in the DIFFSERV MIB RFC. If you publish a DIFFSERV-TC MIB module in its own RFC, I'll change the DSMON MIB. > Thanks! > -- Kwok -- Andy > > At 10:15 AM 12/13/00 -0800, Andy Bierman wrote: > >Andrew Smith wrote: > >> > >> 2 TCs defined in the same MIB module, to be precise. > >> > > > >I disagree. > > >There is no need for the DSMON MIB to have a normative > >reference to the DIFFSERV MIB. > > > >The primary focus of RMON is collect statistics based on > >observable characteristics of network traffic. RFC 2474 > >specifies the observable attributes of a packet containing > >a DSCP field. The REFERENCE clause in the DsCodePoint TC > >properly identifies RFC 2474, and no additional coupling to > >any other documents is required. > > > >BTW, SMIv2 does not allow a TC to be defined as a variant of > >another TC, so Harrie's suggestion won't work. > > > >> Andrew > > > >Andy > > > >> > >> Wijnen, Bert (Bert) wrote: > >> > >> > Comments inline > >> > > >> > > >> >> ---------- > >> >> From: Andy Bierman[SMTP:abierman@cisco.com] > >> >> Sent: Tuesday, December 12, 2000 9:07 PM > >> >> To: Harrie Hazewinkel > >> >> Cc: rmonmib@ietf.org; diffserv@ietf.org > >> >> Subject: Re: [Diffserv] The DsCodePoint definition > >> >> > >> >> Harrie Hazewinkel wrote: > >> >> > >> >>> HI, > >> >>> > >> >>> I was wondering why there is a difference between > >> >>> 2 definitions of the DiffServ CodePoint in different > >> >>> MIB modules. The two different MIMB modules are > >> >>> the DIFFSERV-MIB (of diffserv) and the DSMON-MIB (of RMON). > >> >>> > >> >>> I beleive these 2 TCs should be the same and taken from the > >> >>> DIFFSERV-MIB, because that is from the diffserv WG. > >> >>> > >> >>> ----------- From the DIFFSERV-MIB (draft 05) ----------------- > >> >>> Dscp ::= TEXTUAL-CONVENTION > >> >>> DISPLAY-HINT "d" > >> >>> STATUS current > >> >>> DESCRIPTION > >> >>> "The IP header Diffserv Code-Point that may be used > >> >>> for discriminating or marking a traffic stream. The > >> >>> value -1 ( 4294967295 for Integer32 ) is used to > >> >>> indicate a wildcard i.e. any value." > >> >>> SYNTAX Integer32 (4294967295 | 0..63) > >> >> > >> >> just noticed how broken this TC is... > >> >> 1) an Integer32 object cannot contain the value 4294967295 > >> > > >> > I have made that comments to the Diffserv list already, and they > >> > will need to fix it with using -1 > >> > > >> >> 2) missing REFERENCE clause > >> >> (where exactly in 2474 is the 'wildcard' DSCP value discussed?) > >> > > >> > Yep, this one was raised by someone else (was it Andrew?) > >> > > >> > But the important thing, we need a fixed TC that is usable by both > >> > MIBs I think. Or maybe 2 TCs as I also suggested on the diffserv > >> > list. > >> > > >> > Bert > >> > > >> > > >> >> Andy > >> >> > >> >> > >> >>> -------------------------------------------------------------- > >> >>> > >> >>> ------------ From the DSMON-MIB (draft 03) ------------------- > >> >>> DsmonDSCodePoint ::= TEXTUAL-CONVENTION > >> >>> STATUS current > >> >>> DESCRIPTION > >> >>> "This TC describes an object which identifies the > >> >>> Differentiated Services Codepoint (DSCP) value found within > >> >>> the DS field in a network layer packet header (e.g., IPv4 > >> >>> and IPv6)." > >> >>> REFERENCE > > >> >>> "Definition of the Differentiated Services Field (DS > Field) > >> >>> in the IPv4 and IPv6 Headers [RFC2474]." > >> >>> SYNTAX Integer32 (0..63) > >> >>> -------------------------------------------------------------- > >> >>> > >> >>> OK, I will admit the definition of the DiffServ-MIB is currently > >> >>> broken, but that will be fixed (this week at the IETF, I hope). > >> >>> > >> >>> Harrie > > > >_______________________________________________ > >diffserv mailing list > >diffserv@ietf.org > >http://www1.ietf.org/mailman/listinfo/diffserv > >Archive: > http://www2.ietf.org/mail-archive/working-groups/diffserv/current/maillist.h > tml > > _______________________________________________ diffserv mailing list diffserv@ietf.org http://www1.ietf.org/mailman/listinfo/diffserv Archive: http://www2.ietf.org/mail-archive/working-groups/diffserv/current/maillist.html From diffserv-admin@ietf.org Fri Dec 15 16: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 SMTP id QAA01294 for ; Fri, 15 Dec 2000 16:56:16 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id QAA10466; Fri, 15 Dec 2000 16:26:59 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id QAA10435 for ; Fri, 15 Dec 2000 16:26:55 -0500 (EST) Received: from mx4.tellabs.com (mx4.tellabs.com [204.68.180.54]) by ietf.org (8.9.1a/8.9.1a) with SMTP id QAA22014 for ; Fri, 15 Dec 2000 16:26:49 -0500 (EST) From: john.kenney@tellabs.com Received: from mailw02.hq.tellabs.com (mailw02.bb.tellabs.com [138.111.51.101]) by mx4.tellabs.com (Mirapoint) with ESMTP id AAJ46628; Fri, 15 Dec 2000 15:25:06 -0600 (CST) Received: from localhost (root@localhost) by mailw02.hq.tellabs.com with ESMTP (8.8.6 (PHNE_17190)/8.7.1) id PAA13255; Fri, 15 Dec 2000 15:25:01 -0600 (CST) X-OpenMail-Hops: 1 Date: Fri, 15 Dec 2000 15:25:00 -0600 Message-Id: Subject: RE: [Diffserv] A revised expression of the Expedited Forwarding PH B MIME-Version: 1.0 TO: jschnizl@cisco.com, sbrim@cisco.com CC: diffserv@ietf.org, layres@acc.com Content-Type: text/plain; charset=US-ASCII Content-Disposition: inline ;Creation-Date="Fri, 15 Dec 2000 15:25:00 -0600" Sender: diffserv-admin@ietf.org Errors-To: diffserv-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Diffserv Discussion List X-BeenThere: diffserv@ietf.org Scott and John, I don't have a strong preference here, but is this really the way we want to interpret the words? If I understand Scott's conclusion, it is that one excess EF packet removes all EF behavior requirements (for how long?). That might be fine if its easy to make it so that 100% of the EF traffic is conforming. Otherwise it might be too rigorous an interpretation. I also don't agree that the alternate interpretation ("NOT REQUIRED to deliver the EF behavior to the excess traffic") requires metering. The discrimination could be implicit. For example, it could be that the excess traffic is discarded because it doesn't fit in a buffer. You don't have to discard it, but if you do its ok, and meanwhile you still provide the required treatment to the traffic that didn't overflow the buffer. My inclination is toward the less rigorous interpretation. My apologies if I'm off on the wrong track here. John Kenney > -----Original Message----- > From: jschnizl@cisco.com [mailto:jschnizl@cisco.com] > Sent: Friday, December 15, 2000 12:49 PM > To: sbrim@cisco.com > Cc: jschnizl@cisco.com; layres@acc.com; diffserv@ietf.org > Subject: Re: [Diffserv] A revised expression of the Expedited > Forwarding > PHB > > > Of course, you are right. > The interpretation I (wrongly) endorsed would imply traffic rate > meters where they are not intended by the diffserv architecture. > > John > > At 02:14 PM 12/14/2000 -0800, Scott Brim wrote: > >On 14 Dec 2000 at 16:40 -0500, John Schnizlein apparently wrote: > >> At 12:56 PM 12/14/2000 -0800, Larry Ayres wrote: > >> >It seems to me that the first sentence on page 3 which reads: > >> > > >> >If more EF traffic arrives than is acceptable, the device > is NOT REQUIRED > >> >to deliver the EF behavior. > >> > > >> >is meant to convey: > >> > > >> >If more EF traffic arrives than is acceptable, the device > is NOT REQUIRED > >> >to deliver the EF behavior to the excess traffic. > >> > > >> >Am I right in this interpretation ? > >> > >> Yes. > > > >Um, except that implies to me a requirement that the forwarder > >discriminate between traffic which is "excess" and traffic > which is not. > >The top version is better in that respect. > > > >...Scott > > > _______________________________________________ > diffserv mailing list > diffserv@ietf.org > http://www1.ietf.org/mailman/listinfo/diffserv > Archive: http://www2.ietf.org/mail-archive/working-groups/diffserv/current/mailli st.html _______________________________________________ diffserv mailing list diffserv@ietf.org http://www1.ietf.org/mailman/listinfo/diffserv Archive: http://www2.ietf.org/mail-archive/working-groups/diffserv/current/maillist.html From diffserv-admin@ietf.org Fri Dec 15 17:26:40 2000 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with SMTP id RAA10865 for ; Fri, 15 Dec 2000 17:26:40 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id QAA10899; Fri, 15 Dec 2000 16:53:19 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id QAA10868 for ; Fri, 15 Dec 2000 16:53:15 -0500 (EST) Received: from crufty.research.bell-labs.com (crufty.research.bell-labs.com [204.178.16.49]) by ietf.org (8.9.1a/8.9.1a) with SMTP id QAA29907 for ; Fri, 15 Dec 2000 16:53:13 -0500 (EST) Received: from scummy.research.bell-labs.com ([135.104.2.10]) by crufty; Fri Dec 15 16:51:02 EST 2000 Received: from mail1.pa.bell-labs.com ([135.250.8.11]) by scummy; Fri Dec 15 16:52:02 EST 2000 Received: from research.bell-labs.com (dhcp-6-173.pa.bell-labs.com [135.250.6.173]) by mail1.pa.bell-labs.com (Mirapoint) with ESMTP id AAW22952 (AUTH gja); Fri, 15 Dec 2000 13:52:01 -0800 (PST) Message-ID: <3A3A924B.8BAADA5@research.bell-labs.com> Date: Fri, 15 Dec 2000 13:51:07 -0800 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: "Diffserv@Ietf. Org" Subject: Re: [Diffserv] Yesterday's EF discussion References: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: diffserv-admin@ietf.org Errors-To: diffserv-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Diffserv Discussion List X-BeenThere: diffserv@ietf.org Content-Transfer-Encoding: 7bit Bruce Davie wrote: > > One observation that I might make about the current debate on re-naming EF > is that it resembles the debate in front of the WG on Tuesday. Proponents of > EFRESOLVE are basically saying "draft-charny is a fine PHB definition, it > just isn't EF" which is exactly what they said on Tuesday. Not at all. "Expedited Forwarding" per se was never a very helpful name. Given the goal of clarifying the intent and role of the successor to RFC2598, a name change is reasonable to propose and just as reasonable to oppose. This would be equally true if the efresolve defn was the succesor to RFC2598. But you know that. gja _______________________________________________ diffserv mailing list diffserv@ietf.org http://www1.ietf.org/mailman/listinfo/diffserv Archive: http://www2.ietf.org/mail-archive/working-groups/diffserv/current/maillist.html From diffserv-admin@ietf.org Fri Dec 15 17: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 SMTP id RAA12203 for ; Fri, 15 Dec 2000 17:30:54 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id RAA11275; Fri, 15 Dec 2000 17:03:56 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id RAA11176 for ; Fri, 15 Dec 2000 17:03:46 -0500 (EST) Received: from zcars04f.ca.nortel.com (h57s242a129n47.user.nortelnetworks.com [47.129.242.57]) by ietf.org (8.9.1a/8.9.1a) with SMTP id RAA03894 for ; Fri, 15 Dec 2000 17:03:44 -0500 (EST) Received: from zcard015.ca.nortel.com by zcars04f.ca.nortel.com; Fri, 15 Dec 2000 17:02:31 -0500 Received: by zcard015.ca.nortel.com with Internet Mail Service (5.5.2652.35) id ; Fri, 15 Dec 2000 17:02:20 -0500 Message-ID: <353093573B82D411889E0000F80821662E4B73@zcard00q.ca.nortel.com> From: "Fulu Li" To: "'jschnizl@cisco.com'" Cc: "'diffserv@ietf.org'" Date: Fri, 15 Dec 2000 17:02:11 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2652.35) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C066E2.AD1E73B0" X-Orig: Subject: [Diffserv] RE: Yesterday's EF discussion Sender: diffserv-admin@ietf.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_01C066E2.AD1E73B0 Content-Type: text/plain; charset="iso-8859-1" Did you miss this email? http://www2.ietf.org/mail-archive/working-groups/diffserv/current/msg02677.h tml Regards, Fulu Li At 06:01 PM 12/14/2000 -0500, Ralph Santitoro wrote: >... vendors have already implemented their interpretation of >the 'EF' PHB and its associated 'EF' DSCP. >Therefore, the 'EF' term is proliferated in a variety of product >literature, whitepapers, marketing literature, engineering documentation, >training courseware and device/service configuration tools. >Which vendors? >What do you mean by "implemented"? >Whitepapers and marketing literature should follow (not restrict) >the standards language. I do not know a vendor that does otherwise. > >John ------_=_NextPart_001_01C066E2.AD1E73B0 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable RE: Yesterday's EF discussion

 Did you miss this email?
      =
http://www2.ietf.org/mail-archive/working-groups/diffs= erv/current/msg02677.html

 Regards,

Fulu Li

At 06:01 PM 12/14/2000 -0500, Ralph = Santitoro wrote:
>... vendors have already = implemented their interpretation of 
>the 'EF' PHB and its associated = 'EF' DSCP. 
>Therefore, the 'EF' term is = proliferated in a variety of product
>literature, whitepapers, = marketing literature, engineering documentation,
>training courseware and = device/service configuration tools.

>Which vendors?
>What do you mean by = "implemented"?
>Whitepapers and marketing = literature should follow (not restrict)
>the standards language. I do not = know a vendor that does otherwise.
>
>John

------_=_NextPart_001_01C066E2.AD1E73B0-- _______________________________________________ diffserv mailing list diffserv@ietf.org http://www1.ietf.org/mailman/listinfo/diffserv Archive: http://www2.ietf.org/mail-archive/working-groups/diffserv/current/maillist.html From diffserv-admin@ietf.org Fri Dec 15 20:14: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 SMTP id UAA29411 for ; Fri, 15 Dec 2000 20:14:17 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id TAA12433; Fri, 15 Dec 2000 19:00:12 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id TAA12365 for ; Fri, 15 Dec 2000 19:00:06 -0500 (EST) Received: from mailhost.iprg.nokia.com (mailhost.iprg.nokia.com [205.226.5.12]) by ietf.org (8.9.1a/8.9.1a) with SMTP id TAA05708 for ; Fri, 15 Dec 2000 19:00:06 -0500 (EST) Received: from darkstar.iprg.nokia.com (darkstar.iprg.nokia.com [205.226.5.69]) by mailhost.iprg.nokia.com (8.9.3/8.9.3-GLGS) with ESMTP id PAA17385; Fri, 15 Dec 2000 15:59:31 -0800 (PST) Received: (from root@localhost) by darkstar.iprg.nokia.com (8.11.0/8.11.0-DARKSTAR) id eBFNxSK24807; Fri, 15 Dec 2000 15:59:28 -0800 X-Virus-Scanned: Fri, 15 Dec 2000 15:59:28 -0800 Nokia Silicon Valley Email Exploit Scanner Received: from manray.iprg.nokia.com (205.226.11.135, claiming to be "iprg.nokia.com") by darkstar.iprg.nokia.com(WTS.12.69) smtpdNyEgA1; Fri, 15 Dec 2000 15:15:27 PST Message-ID: <3A3AA610.E527AD83@iprg.nokia.com> Date: Fri, 15 Dec 2000 15:15:28 -0800 From: Martha Zimet Organization: Nokia IP Routing X-Mailer: Mozilla 4.7 [en] (X11; I; FreeBSD 3.4-RELEASE i386) X-Accept-Language: en MIME-Version: 1.0 To: diffserv@ietf.org Subject: RE: [Diffserv] Yesterday's EF discussion Content-Type: text/plain; charset=us-ascii Sender: diffserv-admin@ietf.org Errors-To: diffserv-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Diffserv Discussion List X-BeenThere: diffserv@ietf.org I wish to add my vote to keeping the 'EF' name for the following reasons: 1. A new name will imply a new PHB, which is contrary to what I thought the recent WG goals were (e.g. fix and not re-create). 2. Since the 'EF' PHB (RFC 2598) was a proposed standard for a length of time, like other vendors, we have already implemented our version of the 'EF' PHB and its corresponding DSCP based on our understanding of the RFC. This is realized in our current Nokia IPRG products, network management infrastructure, documentation, training classes, etc. 3. Changing the name will be the most confusing to the those who are not well versed in the underlying semantics in the first place. In addition, it will cause added overhead to those of us who are involved in explaining and socializing diffserv in our respective corporate environments. Regards, /martha _______________________________________________ diffserv mailing list diffserv@ietf.org http://www1.ietf.org/mailman/listinfo/diffserv Archive: http://www2.ietf.org/mail-archive/working-groups/diffserv/current/maillist.html From diffserv-admin@ietf.org Fri Dec 15 21:57: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 SMTP id VAA04719 for ; Fri, 15 Dec 2000 21:57:44 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id VAA13534; Fri, 15 Dec 2000 21:27:16 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id VAA13495 for ; Fri, 15 Dec 2000 21:27:10 -0500 (EST) Received: from mta5.snfc21.pbi.net (mta5.snfc21.pbi.net [206.13.28.241]) by ietf.org (8.9.1a/8.9.1a) with SMTP id VAA23710 for ; Fri, 15 Dec 2000 21:27:07 -0500 (EST) Received: from allegronetworks.com ([206.170.1.250]) by mta5.snfc21.pbi.net (Sun Internet Mail Server sims.3.5.2000.01.05.12.18.p9) with ESMTP id <0G5N000Z82PAM6@mta5.snfc21.pbi.net> for diffserv@ietf.org; Fri, 15 Dec 2000 18:24:48 -0800 (PST) Date: Fri, 15 Dec 2000 18:32:49 -0800 From: Andrew Smith Subject: Re: [Diffserv] Counters in the classifier To: Fred Baker Cc: diffserv@ietf.org Message-id: <3A3AD451.8010202@allegronetworks.com> Organization: Allegro Networks MIME-version: 1.0 Content-type: text/plain; charset=us-ascii; format=flowed Content-transfer-encoding: 7bit User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; m18) Gecko/20001108 Netscape6/6.0 X-Accept-Language: en References: <5.0.2.1.2.20001213100135.0308d050@flipper.cisco.com> <3A37F797.F49575E6@packetdesign.com> <5.0.2.1.2.20001214122954.02508dd0@flipper.cisco.com> Content-Transfer-Encoding: 7bit Sender: diffserv-admin@ietf.org Errors-To: diffserv-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Diffserv Discussion List X-BeenThere: diffserv@ietf.org Content-Transfer-Encoding: 7bit And the intent is for implementation to be optional for RFC conformance/compliance purposes, correct? (of course it might become mandatory for commercial compliance :-)) Andrew Fred Baker wrote: > At 03:54 PM 12/13/00 -0800, Andrew Smith wrote: > >> I'm also a bit confused as to whether Fred's proposal *replaces* the >> existing "counter action" material in the MIB or is in addition to it. >> And is this addition/change expected to be rolled back into the Model >> draft also? > > > it is in addition, and it need not be in the model. it is a debug tool > for the classifier; the count action is an accounting tool of sorts for > the SLA. > > > _______________________________________________ > diffserv mailing list > diffserv@ietf.org > http://www1.ietf.org/mailman/listinfo/diffserv > Archive: > http://www2.ietf.org/mail-archive/working-groups/diffserv/current/maillist.html _______________________________________________ diffserv mailing list diffserv@ietf.org http://www1.ietf.org/mailman/listinfo/diffserv Archive: http://www2.ietf.org/mail-archive/working-groups/diffserv/current/maillist.html From diffserv-admin@ietf.org Fri Dec 15 22:35:58 2000 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with SMTP id WAA17804 for ; Fri, 15 Dec 2000 22:35:58 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id VAA13561; Fri, 15 Dec 2000 21:27:21 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id VAA13500 for ; Fri, 15 Dec 2000 21:27:10 -0500 (EST) Received: from mta5.snfc21.pbi.net (mta5.snfc21.pbi.net [206.13.28.241]) by ietf.org (8.9.1a/8.9.1a) with SMTP id VAA23712 for ; Fri, 15 Dec 2000 21:27:08 -0500 (EST) Received: from allegronetworks.com ([206.170.1.250]) by mta5.snfc21.pbi.net (Sun Internet Mail Server sims.3.5.2000.01.05.12.18.p9) with ESMTP id <0G5N009Z92N6OZ@mta5.snfc21.pbi.net> for diffserv@ietf.org; Fri, 15 Dec 2000 18:23:32 -0800 (PST) Date: Fri, 15 Dec 2000 18:31:32 -0800 From: Andrew Smith Subject: Re: [Diffserv] MIB - technical comments (part 1) To: Fred Baker Cc: diffserv Message-id: <3A3AD404.9080505@allegronetworks.com> Organization: Allegro Networks MIME-version: 1.0 Content-type: text/plain; charset=us-ascii; format=flowed Content-transfer-encoding: 7bit User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; m18) Gecko/20001108 Netscape6/6.0 X-Accept-Language: en References: <5.0.2.1.2.20001214154513.03a02ec0@flipper.cisco.com> Content-Transfer-Encoding: 7bit Sender: diffserv-admin@ietf.org Errors-To: diffserv-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Diffserv Discussion List X-BeenThere: diffserv@ietf.org Content-Transfer-Encoding: 7bit Fred, Fred Baker wrote: > Andrew: > > Kwok and I applied many to most of your comments; I'll let you see that > when the diffs and new draft are posted over the weekend. We have a few > more substantive comments, which I will call out, leaving out the "OK... > OK..." stuff. > > > At 01:24 AM 12/11/00 -0800, Andrew Smith wrote: > >> 1. 2.1 (This comment is somewhat related to the ongoing discussion >> with Bob Moore on the mailing list). A term is introduced here, "Data >> Path", which is somewhat different to the "Datapath" idea used in the >> Model draft. From [MODEL]: >> "Datapath A conceptual path taken by packets with particular >> characteristics through a Diffserv router. Decisions >> as to the path taken by a packet are made by functional >> datapath elements such as Classifiers and Meters." >> >> The usage in the MIB document is different to this i.e. it is single >> interface, single direction. The last paragraph of 2.1 could also use >> some clarification: e.g. >> "The notion of a Datapath introduced in [MODEL] is used in this MIB to >> indicate the DiffServ processing that a packet experiences as it >> travels in a given direction ("in" or "out") of a given interface of a >> Diffserv device. A diffServDataPathTable contains entries that >> indicate the first of possibly multiple functional datapath elements >> that will apply DiffServ treatment to the packet." >> >> That's closer to consistency. But then there's a comment down in the MIB: >> "Each entry of the diffServQTable belongs to one and only one datapath." >> >> This is a more specific usage of "datapath" than up in 2.1: Is this >> supposed to be saying that a datapath is the complete collection of >> functional datapath elements that exist for a given >> {interface,direction} combination? That would conflict with the usage >> in [MODEL] where it means just a single potential path (and thus would >> allow multiple such paths to merge into the same queue). > > > As I understand your comment, I think it brings up a shortcoming in the > model more than it does in the MIB. > > Example: > > ---> classifier ---> meter --> succeed actions --> queue > | A > | | > +----> failure actions -----+ > > I believe that you just told me that the sequence including the "succeed > actions" is one datapath, Yes > and the sequence including the "failure > actions" is another data path, Yes > and that it is inappropriate to ever > refer to the treatment of the entire class of traffic, including both > succeed and failure actions and winding up in the same queue, as a > single data path. That's going further than I intended although it would be a viable definition. The term "datapath" was introduced in the Model draft as a fairly general term to describe Diffserv sorts of things things that happen in the data plane - we could of course make the term more precise if there are cases that warrant it. > I will argue that while the first two are obviously > atomic data paths, the two together is an example of applying a PHB to a > class of traffic, and constitutes an aggregate datapath. Personally, I'd > rather widen the definition in the model than try to hobble the MIB. Didn't intend any hobbling, just clarification. I'm not sure what you're saying here: I think I agree with you if you are saying that a new "aggregate datapath" term is not needed. By "widen", do you mean that the term datapath should refer to both atomic and aggregate? I think I'd rather stick to just the atomic cases and use "applying a PHB to a class of traffic" rather than "aggregate datapath" wherever needed. > That said, I would be willing to remove the controversial sentence from > the document. We did not, but if the working group wants to do that, fine. The problem in the MIB document is the sentence "Each entry of the diffServQTable belongs to one and only one datapath." which is obviously not true for the example you gave which has two separate datapaths (by your "atomic datapath" definition) feeding into a single queue. >> 9. 3 "DiffServ treatment parameterization" is used in several places: >> see comment 3 above, but suggest we use some other existing terms e.g. >> "paramterisation of DiffServ functional datapath elements". > > > The word "treatment" has been used quite a bit to describe what we do to > packets. I think this mostly adds to wordiness and therefore obfuscation > without really clarifying anything. In a number of places, we swapped > the word for "functional datapath", but by no means all. I think changing it in some places and not others, or even using the two interchangably, doesn't usually help with clarity. I guess I should wait to see where you've changed it and then provide detailed comments on that. >> 12. 3.1 "Given some basic information, e.g. >> ifIndex and interface direction, the first DiffServ Functional Element >> is determined." >> Define "first". > > > Done, I think. "first" usually refers to the one that happens "before > all the rest", and is fairly common in English... However, we stuck in > "the first Diffserv Functional Datapath Element applied to a given > packet on a given interface is determined." > > In another note, if you like, I could define "is"... I'm sorry, that was a serious comment that warranted a more mature response than that. Your proposed addition helps but is not sufficient - the scope of "first", I think, should be interface+direction, not just interface. Andrew _______________________________________________ diffserv mailing list diffserv@ietf.org http://www1.ietf.org/mailman/listinfo/diffserv Archive: http://www2.ietf.org/mail-archive/working-groups/diffserv/current/maillist.html From diffserv-admin@ietf.org Fri Dec 15 22:36:43 2000 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with SMTP id WAA18125 for ; Fri, 15 Dec 2000 22:36:43 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id VAA13486; Fri, 15 Dec 2000 21:25:39 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id VAA13457 for ; Fri, 15 Dec 2000 21:25:34 -0500 (EST) Received: from auemlsrv.firewall.lucent.com (auemail1.lucent.com [192.11.223.161]) by ietf.org (8.9.1a/8.9.1a) with SMTP id VAA23370 for ; Fri, 15 Dec 2000 21:25:31 -0500 (EST) Received: from auemlsrv.firewall.lucent.com (localhost [127.0.0.1]) by auemlsrv.firewall.lucent.com (Pro-8.9.3/8.9.3) with ESMTP id VAA14606 for ; Fri, 15 Dec 2000 21:25:33 -0500 (EST) Received: from uk0006exch001h.wins.lucent.com (h135-86-160-150.lucent.com [135.86.160.150]) by auemlsrv.firewall.lucent.com (Pro-8.9.3/8.9.3) with ESMTP id VAA14596 for ; Fri, 15 Dec 2000 21:25:32 -0500 (EST) Received: by uk0006exch001h.uk.lucent.com with Internet Mail Service (5.5.2650.21) id ; Sat, 16 Dec 2000 02:07:47 -0000 Message-ID: <976F7C55E3B2D111A0720008C728549C0487762B@en0060exch001u.uk.lucent.com> From: "Casati, Alessio (Alessio)" To: diffserv@ietf.org, "'Martha Zimet'" Subject: RE: [Diffserv] Yesterday's EF discussion Date: Sat, 16 Dec 2000 02:07:46 -0000 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: text/plain Sender: diffserv-admin@ietf.org Errors-To: diffserv-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Diffserv Discussion List X-BeenThere: diffserv@ietf.org Couple of quick comments. > I wish to add my vote to keeping the 'EF' name for the following > reasons: > > 1. A new name will imply a new PHB, which is contrary to what I > thought the recent WG goals were (e.g. fix and not re-create). > It appears that we do have a new PHB (or a couple of them sold in the guise of one). At least this is the conclusion the author of the PHB itself came to, as faced with the proposal in the charny and its "compromise ". > 2. Since the 'EF' PHB (RFC 2598) was a proposed standard for a length > of time, like other vendors, we have already implemented our version > of the 'EF' PHB and its corresponding DSCP based on our understanding > of the RFC. This is realized in our current Nokia IPRG products, > network management infrastructure, documentation, training classes, > etc. > Implementing the EF DSCP must have been quite a deed :). Now, ideally you should comply with what PHBs diffserv WG define. If names change this should not matter if you comply with the definition. The definition has changed. Your implementation may or may not comply with it (or display or not good values of E_a nd E_p). Effectively, you may have designed your box without caring about E_a or E_p as currently defined. Good luck :). > 3. Changing the name will be the most confusing to the those who are > not well versed in the underlying semantics in the first place. > The relation between the PHB name and its semantics happens to be quite vague (what would you guess if somebody teels you "assured forwarding"?) > In > addition, it will cause added overhead to those of us who are involved > in explaining and socializing diffserv in our respective corporate > environments. > well, this will really be the challenge that the thing from the group of twelve will come with :). It will first require putting folks thru some discrete math classes. This opens up a whole new market on its own :). alessio > Regards, > > /martha > > _______________________________________________ > diffserv mailing list > diffserv@ietf.org > http://www1.ietf.org/mailman/listinfo/diffserv > Archive: > http://www2.ietf.org/mail-archive/working-groups/diffserv/current/maillist > .html > _______________________________________________ diffserv mailing list diffserv@ietf.org http://www1.ietf.org/mailman/listinfo/diffserv Archive: http://www2.ietf.org/mail-archive/working-groups/diffserv/current/maillist.html From diffserv-admin@ietf.org Fri Dec 15 23:06: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 SMTP id XAA28688 for ; Fri, 15 Dec 2000 23:06:26 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id VAA14020; Fri, 15 Dec 2000 21:56:27 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id VAA13990 for ; Fri, 15 Dec 2000 21:56:22 -0500 (EST) Received: from auemlsrv.firewall.lucent.com (auemail1.lucent.com [192.11.223.161]) by ietf.org (8.9.1a/8.9.1a) with SMTP id VAA04267 for ; Fri, 15 Dec 2000 21:56:19 -0500 (EST) Received: from auemlsrv.firewall.lucent.com (localhost [127.0.0.1]) by auemlsrv.firewall.lucent.com (Pro-8.9.3/8.9.3) with ESMTP id VAA23112 for ; Fri, 15 Dec 2000 21:56:21 -0500 (EST) Received: from uk0006exch001h.wins.lucent.com (h135-86-160-150.lucent.com [135.86.160.150]) by auemlsrv.firewall.lucent.com (Pro-8.9.3/8.9.3) with ESMTP id VAA23103 for ; Fri, 15 Dec 2000 21:56:21 -0500 (EST) Received: by uk0006exch001h.uk.lucent.com with Internet Mail Service (5.5.2650.21) id ; Sat, 16 Dec 2000 02:56:20 -0000 Message-ID: <976F7C55E3B2D111A0720008C728549C0487762D@en0060exch001u.uk.lucent.com> From: "Casati, Alessio (Alessio)" To: "Diffserv@Ietf. Org" , "'Bruce Davie'" Subject: RE: [Diffserv] Yesterday's EF discussion Date: Sat, 16 Dec 2000 02:56:19 -0000 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: text/plain Sender: diffserv-admin@ietf.org Errors-To: diffserv-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Diffserv Discussion List X-BeenThere: diffserv@ietf.org Bruce, The consensus in the meeting-room was clear. On the other hand this needs to be evaluated thouroughly by the list (which is what the WG is, not the meeting-room). As such, some discussion can still take place without you be entitled to call this "ignoring WG consensus". WG consensus is now being evaluated. This according to the IETF rules we (and you as well)know. In the process of generating the replacement of 2598, a name that best fits the behaviour may be used. Practical considerations may suggest keeping EF. Precision may not. alessio > ---------- > From: Bruce Davie[SMTP:bdavie@cisco.com] > > > One observation that I might make about the current debate on re-naming EF > is that it resembles the debate in front of the WG on Tuesday. Proponents > of > EFRESOLVE are basically saying "draft-charny is a fine PHB definition, it > just isn't EF" which is exactly what they said on Tuesday. I believe the > WG > voted to reject that position when it voted in favor of adopting > draft-charny as the basis for a replacement for RFC 2598. So we seem to be > simply rehashing an argument that was settled on Tuesday, with the same > proponents on both sides. As has already been said, this is simply > ignoring > the WG consensus. > > Bruce > > > _______________________________________________ diffserv mailing list diffserv@ietf.org http://www1.ietf.org/mailman/listinfo/diffserv Archive: http://www2.ietf.org/mail-archive/working-groups/diffserv/current/maillist.html From diffserv-admin@ietf.org Sat Dec 16 01:21: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 SMTP id BAA25679 for ; Sat, 16 Dec 2000 01:21:47 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id AAA15670; Sat, 16 Dec 2000 00:39:54 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id AAA15639 for ; Sat, 16 Dec 2000 00:39:50 -0500 (EST) Received: from hoemail2.firewall.lucent.com (hoemail2.lucent.com [192.11.226.163]) by ietf.org (8.9.1a/8.9.1a) with SMTP id AAA06182 for ; Sat, 16 Dec 2000 00:39:51 -0500 (EST) Received: from hoemail2.firewall.lucent.com (localhost [127.0.0.1]) by hoemail2.firewall.lucent.com (Pro-8.9.3/8.9.3) with ESMTP id AAA29398 for ; Sat, 16 Dec 2000 00:39:50 -0500 (EST) Received: from uk0006exch001h.wins.lucent.com (h135-86-160-150.lucent.com [135.86.160.150]) by hoemail2.firewall.lucent.com (Pro-8.9.3/8.9.3) with ESMTP id AAA29389 for ; Sat, 16 Dec 2000 00:39:49 -0500 (EST) Received: by uk0006exch001h.uk.lucent.com with Internet Mail Service (5.5.2650.21) id ; Sat, 16 Dec 2000 05:39:49 -0000 Message-ID: <976F7C55E3B2D111A0720008C728549C0487762F@en0060exch001u.uk.lucent.com> From: "Casati, Alessio (Alessio)" To: diffserv@ietf.org, "'Bruce Davie'" Subject: RE: [Diffserv] Possible compromise between EFRESOLVE and draft-ch arny Date: Sat, 16 Dec 2000 05:39:47 -0000 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: text/plain Sender: diffserv-admin@ietf.org Errors-To: diffserv-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Diffserv Discussion List X-BeenThere: diffserv@ietf.org Bruce, I would like to discuss the merits of your proposal ("compromise"), to form the WG consensus on the list: in fact we may have not completely understood the proposal so far, due to tight schedule and the little time given to the group to think and discuss about it. In all fairness, this proposal should have been submitted around the draft_00 deadline :). > under our "color-aware" definition when the offered > load to an output is bounded by rate R and burst size B, the maximum > per-packet delay is B/R + E_p. Clearly both definitions provide bounded > delay under well-defined operating conditions. The second part of our > definition addresses the intent of EFRESOLVE, but differs from EFRESOLVE > in > that it provides well-defined behavior for arbitrary inputs. > How? could you elaborate on this? What is the intended behaviour when the burst is exceeded? and what is the behaviour when the input rate is exceeded? > In addition > while EFRESOLVE gives a fixed delay within a specified operating region, > I thought we were giving a bound on the delay variation, not a fixed delay... clarification from you is expected. > our new definition allows an operator to achieve different performance > goals > by specifying different ranges of B and R that achieve the desired delay > bounds. > I thought that we where not preventing an operator from doing so. Where in the definition you detect this? > The first part of the definition allows existing and operational > rate-based > implementations and deployments of the EF PHB to continue to be deployed > and operated (e.g EF implementation in Internet 2 managed by Bandwidth > Brokers). > do you mean that delay variation is not a goal that the first part of your definition is aiming at? what are the equations you associate to the first part? > The second part of the definition provides the machinery for > computing the delay bound as a function of the operating conditions. > > > ---------- > Equations for those who care: > I care: > The original colorblind equations from draft-charny-...-01 are eq_1a and > eq_2a. The new ones that achieve the compromise are eq_1b and eq_2b. > Although the latter equations are not in draft-charny...01, the intuitive > description of the equations in that draft may still be helpful in > understanding the equations. > > D(j) <= F(j) + E_a (eq_1a) > > the need to keep this equation (eq_1a) is unclear to me. 1b should suffice, isn't it? what makes 1a compelling in the definition? Let's now consider > d(j) <= f(j) + E_p (eq_1b) > and > under our "color-aware" definition when the offered > load to an output is bounded by rate R and burst size B, the maximum per-packet delay is B/R + E_p It occurs to me that Ep is dependent on the relative distribution over the input interfaces of the input rate (which you correctly state is assumed to be up to R) and the scheduler weight settings / router config. So, E_p is not a parameter that can be used to evaluate the goodness of a scheduler or router since it depends on the configuration of the scheduler and the router, and also from network dependent aspects (the distribution of the input rate, which in turn influences or may influence the router configuration). As such what is the usefulness of this equation (1_b), and what makes this more appropriate than saying that the delay variation must be bounded, as per EFRESOLVE? kind regards alessio _______________________________________________ diffserv mailing list diffserv@ietf.org http://www1.ietf.org/mailman/listinfo/diffserv Archive: http://www2.ietf.org/mail-archive/working-groups/diffserv/current/maillist.html From diffserv-admin@ietf.org Sat Dec 16 01:34: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 SMTP id BAA02267 for ; Sat, 16 Dec 2000 01:34:59 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id AAA15795; Sat, 16 Dec 2000 00:58:31 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id AAA15764 for ; Sat, 16 Dec 2000 00:58:27 -0500 (EST) Received: from pilgrim.cisco.com (pilgrim.cisco.com [171.69.204.12]) by ietf.org (8.9.1a/8.9.1a) with SMTP id AAA14724 for ; Sat, 16 Dec 2000 00:58:28 -0500 (EST) Received: from acharny-nt.cisco.com ([161.44.189.106]) by pilgrim.cisco.com (8.8.8-Cisco List Logging/8.8.8) with ESMTP id AAA27322; Sat, 16 Dec 2000 00:57:55 -0500 (EST) Message-Id: <4.3.2.7.2.20001215235255.00bea100@pilgrim.cisco.com> X-Sender: acharny@pilgrim.cisco.com X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Sat, 16 Dec 2000 01:03:40 -0500 To: "Casati, Alessio (Alessio)" , diffserv@ietf.org From: Anna Charny Subject: RE: [Diffserv] Yesterday's EF discussion In-Reply-To: <976F7C55E3B2D111A0720008C728549C0487762B@en0060exch001u.uk .lucent.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: diffserv-admin@ietf.org Errors-To: diffserv-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Diffserv Discussion List X-BeenThere: diffserv@ietf.org Alessio, At 02:07 AM 12/16/00 +0000, Casati, Alessio (Alessio) wrote: >Couple of quick comments. > > > > I wish to add my vote to keeping the 'EF' name for the following > > reasons: > > > > 1. A new name will imply a new PHB, which is contrary to what I > > thought the recent WG goals were (e.g. fix and not re-create). > > >It appears that we do have a new PHB (or a couple >of them sold in the guise of one). At least this >is the conclusion the author of the PHB itself >came to, as faced with the proposal in the >charny and its "compromise ". We have argued in SD that the definition we propose describes two different *aspects* of the same behavior, rather than two different behaviors. Both aspects of the behavior are useful in evaluating the quality of EF implementations. In particular if you are interested in knowing just what time scale your scheduler is providing the configured rate to the EF aggregate (as RFC 2598 implied), E_a is of interest, while if you ask the question about the delay of delay-variation bound for a given packet given the constraints on the input traffic (as desired in EFRESOLVE), the parameter of interest is E_p. These are simply two *measurements* of a device, not two different devices. The fact that you may want two parameters to describe the same behavior does not mean that you have two different behaviors. > > 2. Since the 'EF' PHB (RFC 2598) was a proposed standard for a length > > of time, like other vendors, we have already implemented our version > > of the 'EF' PHB and its corresponding DSCP based on our understanding > > of the RFC. This is realized in our current Nokia IPRG products, > > network management infrastructure, documentation, training classes, > > etc. > > >Implementing the EF DSCP must have been quite a >deed :). Now, ideally you should comply with what >PHBs diffserv WG define. If names change >this should not matter if you comply with the >definition. The definition has changed. Your >implementation may or may not comply with it >(or display or not good values of E_a nd E_p). >Effectively, you may have designed your box >without caring about E_a or E_p as currently >defined. Good luck :). I must tell you that whether or not one designed the box with E_a and E_p in mind, the box, once built, will have some values of these parameters. If you want to use this device to build a service which is quantifiable in terms of its worst case behavior, (as the working group decided it wants the service to be described), then you'd better know how to reason about your device quantitatively. The knowledge of the two parameters E_a and E_p will enable you to do exactly that: reason quantitatively about exactly what service you can actually provide. To the best of my understanding, the parameter S in EFRESOLVE definition had a rather similar purpose. As far as evaluating the values of these parameters for a given device, we have already given a catalogue of schedulers and their E_a terms for a large number of commonly used output schedulers in draft-charny. For strict FIFO schedulers E_p is strictly equal to E_a and so the compromise definition does not add any extra complexity in that case. We intend to provide additional implementation guidance for non-FIFO devices as we write the text of the replacement RFC. > > 3. Changing the name will be the most confusing to the those who are > > not well versed in the underlying semantics in the first place. > > >The relation between the PHB name and its semantics happens to >be quite vague (what would you guess if somebody teels you >"assured forwarding"?) > > > In > > addition, it will cause added overhead to those of us who are involved > > in explaining and socializing diffserv in our respective corporate > > environments. > > >well, this will really be the challenge that the >thing from the group of twelve will come with :). >It will first require putting folks thru some >discrete math classes. This opens up a whole new market >on its own :). I think the difficulty of mathematics involved in our definition does not exceed the level of mathematics involved in a leaky bucket policer, or any of the rate-based schedulers which are well understood in the industry. So I truly think you are giving far less credit to the people in the WG than they deserve. On the other hand, a certain minimal level of mathematical precision seems unavoidable if any quantifiable worst case guarantees are desired at all - and the working group clearly stated its interest in such worst case guarantees. It seems somewhat contradictory to me to desire to provide the tremendously tight jitter bound guarantees as claimed by the VW draft, and at the same time bemoan the fact that you might actually need some math to at least reason whether it is possible. Best regards, Anna >alessio > > > > > > Regards, > > > > /martha > > > > _______________________________________________ > > diffserv mailing list > > diffserv@ietf.org > > http://www1.ietf.org/mailman/listinfo/diffserv > > Archive: > > http://www2.ietf.org/mail-archive/working-groups/diffserv/current/maillist > > .html > > > >_______________________________________________ >diffserv mailing list >diffserv@ietf.org >http://www1.ietf.org/mailman/listinfo/diffserv >Archive: >http://www2.ietf.org/mail-archive/working-groups/diffserv/current/maillist.html --------------------------------------- Anna Charny Cisco Systems, Inc 300 Apollo Drive Chelmsford, MA 01824 Tel. (978)-244-8172 Fax (978)-244-8126 _______________________________________________ diffserv mailing list diffserv@ietf.org http://www1.ietf.org/mailman/listinfo/diffserv Archive: http://www2.ietf.org/mail-archive/working-groups/diffserv/current/maillist.html From diffserv-admin@ietf.org Sat Dec 16 03:31: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 SMTP id DAA21926 for ; Sat, 16 Dec 2000 03:31:54 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id CAA22641; Sat, 16 Dec 2000 02:13:42 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id CAA22610 for ; Sat, 16 Dec 2000 02:13:38 -0500 (EST) Received: from ihemail1.firewall.lucent.com (ihemail1.lucent.com [192.11.222.161]) by ietf.org (8.9.1a/8.9.1a) with SMTP id CAA26204 for ; Sat, 16 Dec 2000 02:13:38 -0500 (EST) Received: from ihemail1.firewall.lucent.com (localhost [127.0.0.1]) by ihemail1.firewall.lucent.com (Pro-8.9.3/8.9.3) with ESMTP id CAA12971 for ; Sat, 16 Dec 2000 02:13:38 -0500 (EST) Received: from uk0006exch001h.wins.lucent.com (h135-86-160-150.lucent.com [135.86.160.150]) by ihemail1.firewall.lucent.com (Pro-8.9.3/8.9.3) with ESMTP id CAA12963 for ; Sat, 16 Dec 2000 02:13:38 -0500 (EST) Received: by uk0006exch001h.uk.lucent.com with Internet Mail Service (5.5.2650.21) id ; Sat, 16 Dec 2000 07:10:21 -0000 Message-ID: <976F7C55E3B2D111A0720008C728549C04877630@en0060exch001u.uk.lucent.com> From: "Casati, Alessio (Alessio)" To: "Casati, Alessio (Alessio)" , diffserv@ietf.org, "'Anna Charny'" Subject: RE: [Diffserv] Yesterday's EF discussion Date: Sat, 16 Dec 2000 07:08:47 -0000 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 > We have argued in SD that the definition we propose describes two > different > *aspects* of the same behavior, rather than two different behaviors. Both > aspects of the behavior are useful in evaluating the quality of EF > implementations. In particular if you are interested in knowing just what > time scale your scheduler is providing the configured rate to the EF > aggregate (as RFC 2598 implied), E_a is of interest, while if you ask the > question about the delay of delay-variation bound for a given packet given > > the constraints on the input traffic (as desired in EFRESOLVE), the > parameter of interest is E_p. These are simply two *measurements* of a > device, not two different devices. The fact that you may want two > parameters to describe the same behavior does not mean that you have two > different behaviors. > To my understanding, since Bruce stated: > under our "color-aware" definition when the offered > load to an output is bounded by rate R and burst size B, the maximum > per-packet delay is B/R + E_p the only interesting parameter is E_p, since this is giving the timescale up to the crossover rate R (above R we don't mind, since we are outside any conceivable EF use). > > > 2. Since the 'EF' PHB (RFC 2598) was a proposed standard for a length > > > of time, like other vendors, we have already implemented our version > > > of the 'EF' PHB and its corresponding DSCP based on our understanding > > > of the RFC. This is realized in our current Nokia IPRG products, > > > network management infrastructure, documentation, training classes, > > > etc. > > > > >Implementing the EF DSCP must have been quite a > >deed :). Now, ideally you should comply with what > >PHBs diffserv WG define. If names change > >this should not matter if you comply with the > >definition. The definition has changed. Your > >implementation may or may not comply with it > >(or display or not good values of E_a nd E_p). > >Effectively, you may have designed your box > >without caring about E_a or E_p as currently > >defined. Good luck :). > > I must tell you that whether or not one designed the box with E_a and E_p > in mind, the box, once built, will have > some values of these parameters. > This is obvious, an axiom :), but a vendor may spend time and care to go on the market with stuff that better fit the new def, isn't it? > If you want to use this device to build a > service which is quantifiable in terms of its worst case behavior, (as the > > working group decided it wants the service to be described), then you'd > better know how to reason about your device quantitatively. The knowledge > of the two parameters E_a and E_p will enable you to do exactly that: > reason quantitatively about exactly what service you can actually > provide. To the best of my understanding, the parameter S in EFRESOLVE > definition had a rather similar purpose. > S simply tells you how many packet times at the expected input rate the delay variation bound is. A very different purpose. If the expected rate changes, S changes. the goal is to keep S*MTU/R at or below the desired value. I already stated my opinion on S many times. > For strict > FIFO schedulers E_p is strictly equal to E_a and so the compromise > definition does not add any extra complexity in that case. We intend to > provide additional implementation guidance for non-FIFO devices as we > write > the text of the replacement RFC. > Implementation guidance? Probably you didn't want to say so :). I would be reluctant to suggest you add implementation guidance. > > > 3. Changing the name will be the most confusing to the those who are > > > not well versed in the underlying semantics in the first place. > > > > >The relation between the PHB name and its semantics happens to > >be quite vague (what would you guess if somebody teels you > >"assured forwarding"?) > > > > > In > > > addition, it will cause added overhead to those of us who are involved > > > in explaining and socializing diffserv in our respective corporate > > > environments. > > > > >well, this will really be the challenge that the > >thing from the group of twelve will come with :). > >It will first require putting folks thru some > >discrete math classes. This opens up a whole new market > >on its own :). > > I think the difficulty of mathematics involved in our definition does not > exceed the level of mathematics involved in a leaky bucket policer, or any > > of the rate-based schedulers which are well understood in the > industry. So I truly think you are giving far less credit to the people > in > the WG than they deserve. > On the other hand, just for politeness, I would please ask if you could refrain from personal comments on my respect on the individuals of this WG. The humor underlying my statement on supposed corporate environments math hardhips was clear (as it was in Bruce's message). > On the other hand, a certain minimal level of > mathematical precision seems unavoidable if any quantifiable worst case > guarantees are desired at all > I think we can/should come up with simpler, smaller, definition. > - and the working group clearly stated its > interest in such worst case guarantees. > I Agree, but a worst case bound on delay variation does not require a system of discrete time equations to be defined, nor a catalogue of E_a for some possible schedulers to be disseminated in the industry as part of this PHB def. Laudable, yet unnecessary, exercise. It should be an informational thing only, to be published distinctly from this PHB definition. regards alessio _______________________________________________ diffserv mailing list diffserv@ietf.org http://www1.ietf.org/mailman/listinfo/diffserv Archive: http://www2.ietf.org/mail-archive/working-groups/diffserv/current/maillist.html From diffserv-admin@ietf.org Sat Dec 16 08:33: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 SMTP id IAA08034 for ; Sat, 16 Dec 2000 08:33:20 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id HAA25155; Sat, 16 Dec 2000 07:58:50 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id HAA25058 for ; Sat, 16 Dec 2000 07:58:43 -0500 (EST) Received: from pilgrim.cisco.com (pilgrim.cisco.com [171.69.204.12]) by ietf.org (8.9.1a/8.9.1a) with SMTP id HAA00571 for ; Sat, 16 Dec 2000 07:58:36 -0500 (EST) Received: from acharny-nt.cisco.com ([161.44.189.106]) by pilgrim.cisco.com (8.8.8-Cisco List Logging/8.8.8) with ESMTP id HAA08451; Sat, 16 Dec 2000 07:57:57 -0500 (EST) Message-Id: <4.3.2.7.2.20001216010358.00bc0680@pilgrim.cisco.com> X-Sender: acharny@pilgrim.cisco.com X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Sat, 16 Dec 2000 08:03:42 -0500 To: "Casati, Alessio (Alessio)" , diffserv@ietf.org, "'Bruce Davie'" From: Anna Charny Subject: RE: [Diffserv] Possible compromise between EFRESOLVE and draft-charny In-Reply-To: <976F7C55E3B2D111A0720008C728549C0487762F@en0060exch001u.uk .lucent.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: diffserv-admin@ietf.org Errors-To: diffserv-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Diffserv Discussion List X-BeenThere: diffserv@ietf.org Alessio, Here are some responses. > > under our "color-aware" definition when the offered > > load to an output is bounded by rate R and burst size B, the maximum > > per-packet delay is B/R + E_p. Clearly both definitions provide bounded > > delay under well-defined operating conditions. The second part of our > > definition addresses the intent of EFRESOLVE, but differs from EFRESOLVE > > in > > that it provides well-defined behavior for arbitrary inputs. > > >How? could you elaborate on this? What is the intended behaviour when the >burst is exceeded? and what is the behaviour when the input rate is >exceeded? First, there is no limit on the burst or input rate that our definition works with - the input rate and the burst is whatever it happens to be. Clearly, for some input patterns there will be some loss, but the definition of exactly which packets should or should not be dropped is outside the scope of the definition of EF PHB. For the lossless case, the behavior is fully defined for all packets for arbitrary inputs which cause no loss. For the case when there is loss, the behavior is fully defined *for all those packets that were not dropped* (for the purposes of the conformance test, the lost packets are simply taken out of the input stream, and the definition is then applied only to packets that were not lost). > > In addition > > while EFRESOLVE gives a fixed delay within a specified operating region, > > >I thought we were giving a bound on the delay variation, not a fixed >delay... >clarification from you is expected. Quite true, this was a typo. It does not really matter though, since as long as you know the minimal propagation time through the device (which is quite easy to specify), you can immediately compute the delay bound from the bound on delay variation. We feel that knowing the fixed propagation time in addition to delay variation is quite useful since otherwise a definition based entirely on delay variation bound allows devices with infinite internal delay to be conformant. > > our new definition allows an operator to achieve different performance > > goals > > by specifying different ranges of B and R that achieve the desired delay > > bounds. > > >I thought that we where not preventing an operator from doing so. Where in >the >definition you detect this? If you know S for a given B and R in EFRESOLVE, this does not tell you the relationship between these parameters for some other B and R. So you would either need to give the worst case S for all B and R within the operating region, or give different S for different regions. In the case of our definition, once you know a bound on E_p, you can compute the delay bound for any B and R you choose, and conversely for a delay bound you can explicitly choose B and R that may give you that bound D from D=B/R + E_p. > > The first part of the definition allows existing and operational > > rate-based > > implementations and deployments of the EF PHB to continue to be deployed > > and operated (e.g EF implementation in Internet 2 managed by Bandwidth > > Brokers). > > >do you mean that delay variation is not a goal that the >first part of your definition is aiming at? >what are the equations you associate to the first part? The first part is the color-blind definition (the one with E_a). The color-blind version of the definition defines the timescale at which the aggregate is given its configured rate. The color-aware definition is the one that is used to compute the delay (or delay variation) bound. > > The second part of the definition provides the machinery for > > computing the delay bound as a function of the operating conditions. > > > > > > ---------- > > Equations for those who care: > > >I care: > > > The original colorblind equations from draft-charny-...-01 are eq_1a and > > eq_2a. The new ones that achieve the compromise are eq_1b and eq_2b. > > Although the latter equations are not in draft-charny...01, the intuitive > > description of the equations in that draft may still be helpful in > > understanding the equations. > > > > D(j) <= F(j) + E_a (eq_1a) > > > > >the need to keep this equation (eq_1a) is unclear to me. >1b should suffice, isn't it? what makes 1a compelling in the definition? If your service is strict FIFO, then indeed 1a and 1b are redundant. However, in practice there is no such thing as a FIFO device - even minimal internal jitter makes a box non-FIFO. So in practice 1a and 1b are always different. You can have very smooth rate service given to an aggregate (small E_a), but within the aggregate some packets may be served quite a bit later than they would have been in a FIFO server (large E_p). This means that your aggregate service may be very accurate, while per-packet delay may still be large. >Let's now consider > > > d(j) <= f(j) + E_p (eq_1b) > > >and > > > under our "color-aware" definition when the offered > > load to an output is bounded by rate R and burst size B, the maximum > per-packet delay is B/R + E_p > >It occurs to me that Ep is dependent on the relative distribution >over the input interfaces of the input rate (which you correctly state is >assumed to be up to >R) > and the scheduler weight settings / router config. So, E_p is not a >parameter >that can be used to evaluate the goodness of a scheduler or router since it >depends on >the configuration of the scheduler and the router, and also from network >dependent aspects (the distribution of the input rate, which in turn >influences >or may influence the router configuration). This is entirely true - E_p is not a parameter that can be used to evaluate the goodness of the the device. That is why we actually decided against having E_p in our original version of the draft and chose the color-blind definition. E_p has many of the same problems as S in EFRESOLVE and is provided in the compromise definition to enable those who want a bound on per packet delay (or its deviation) to enable the same functionality as was intended by EFRESOLVE within its operating region. One other benefit of having some E_p, even if very large, is to address the concern that a scheduler with small E_a may silently hide a very large per-packet delay. In the compromise definition such a device will have a small E_a and large E_p, and thus will no longer hide the fact that per-packet delay is large. Just as is the case with S of EFRESOLVE, for some schedulers E_p will be large, for others it may be small. In some cases large (or even infinite) E_p will mean a good scheduler, and for some schedulers large E_p will mean a bad scheduler. Note that we do NOT intend to use E_p as a figure-of-merit. Evaluating the meaning of the magnitude of E_p will require knowledge of the details of a particular scheduler, exactly as in the case with S of EFRESOLVE. In contrast, we continue using E_a as a figure of merit, since small E_a always means that the configured rate is provided to the aggregate at a small timescale, and large E_a always means a bursty scheduler. >As such what is the usefulness of this equation (1_b), and what makes this >more appropriate than saying that the delay variation must be bounded, as >per EFRESOLVE? I trust I have answered this question. To reiterate: we believe that 1_a, defines the timescale of a rate guarantee, which we believe is quite important for quantifying the services built on top of EF, and can also be used by those who rely on the rate-based nature of RFC 2598. In contrast, for any device but strict FIFO, 1_b does not necessarily give a good idea how well the aggregate is served at its configured rate. However, 1_b provides the means for computing a bound on delay (or delay variation) as a function of the input rate and burstiness, which in particular allows to satisfy the goal of EFRESOLVE of providing a delay bound within a given operating region. Anna >kind regards > >alessio > > >_______________________________________________ >diffserv mailing list >diffserv@ietf.org >http://www1.ietf.org/mailman/listinfo/diffserv >Archive: >http://www2.ietf.org/mail-archive/working-groups/diffserv/current/maillist.html --------------------------------------- Anna Charny Cisco Systems, Inc 300 Apollo Drive Chelmsford, MA 01824 Tel. (978)-244-8172 Fax (978)-244-8126 _______________________________________________ diffserv mailing list diffserv@ietf.org http://www1.ietf.org/mailman/listinfo/diffserv Archive: http://www2.ietf.org/mail-archive/working-groups/diffserv/current/maillist.html From diffserv-admin@ietf.org Sat Dec 16 10:49: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 SMTP id KAA07143 for ; Sat, 16 Dec 2000 10:49:26 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id KAA26247; Sat, 16 Dec 2000 10:21:00 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id KAA26216 for ; Sat, 16 Dec 2000 10:20:56 -0500 (EST) Received: from usc.edu (root@usc.edu [128.125.253.136]) by ietf.org (8.9.1a/8.9.1a) with SMTP id KAA00889 for ; Sat, 16 Dec 2000 10:20:53 -0500 (EST) Received: from aludra.usc.edu (demir@aludra.usc.edu [128.125.253.184]) by usc.edu (8.9.3.1/8.9.3/usc) with ESMTP id HAA00637; Sat, 16 Dec 2000 07:20:53 -0800 (PST) Received: from localhost (demir@localhost) by aludra.usc.edu (8.9.3.1/8.9.3/usc) with ESMTP id HAA13268; Sat, 16 Dec 2000 07:20:52 -0800 (PST) Date: Sat, 16 Dec 2000 07:20:51 -0800 (PST) From: demir To: Anna Charny cc: "Casati, Alessio (Alessio)" , diffserv@ietf.org Subject: RE: [Diffserv] Yesterday's EF discussion In-Reply-To: <4.3.2.7.2.20001215235255.00bea100@pilgrim.cisco.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: diffserv-admin@ietf.org Errors-To: diffserv-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Diffserv Discussion List X-BeenThere: diffserv@ietf.org Anna, > We have argued in SD that the definition we propose describes two different > *aspects* of the same behavior, rather than two different behaviors. Both > aspects of the behavior are useful in evaluating the quality of EF Two different aspects of the same behavior is not the same behavior. It is a new bahavior. A = {x,y}, B={x}, C={y} B != A, C != A, A == A. I hope this helps. > implementations. In particular if you are interested in knowing just what > time scale your scheduler is providing the configured rate to the EF And your time-scale is "packet scale", your rate aproach is MAX-MIN. Is there any other "scales" and rate "approaches"? > I must tell you that whether or not one designed the box with E_a and E_p > in mind, the box, once built, will have > some values of these parameters. If you want to use this device to build a > service which is quantifiable in terms of its worst case behavior, (as the > working group decided it wants the service to be described), then you'd > better know how to reason about your device quantitatively. The knowledge > of the two parameters E_a and E_p will enable you to do exactly that: > reason quantitatively about exactly what service you can actually > provide. To the best of my understanding, the parameter S in EFRESOLVE > definition had a rather similar purpose. How I see E_a and E_p is that they are device-dependent. No problem. You have already evaluated them. Isn't B/R is more important for "loss rate"? Alper K. Demir _______________________________________________ diffserv mailing list diffserv@ietf.org http://www1.ietf.org/mailman/listinfo/diffserv Archive: http://www2.ietf.org/mail-archive/working-groups/diffserv/current/maillist.html From diffserv-admin@ietf.org Sat Dec 16 11: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 SMTP id LAA16345 for ; Sat, 16 Dec 2000 11:27:32 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id KAA26506; Sat, 16 Dec 2000 10:49:31 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id KAA26470 for ; Sat, 16 Dec 2000 10:49:27 -0500 (EST) Received: from usc.edu (root@usc.edu [128.125.253.136]) by ietf.org (8.9.1a/8.9.1a) with SMTP id KAA07126 for ; Sat, 16 Dec 2000 10:49:24 -0500 (EST) Received: from aludra.usc.edu (demir@aludra.usc.edu [128.125.253.184]) by usc.edu (8.9.3.1/8.9.3/usc) with ESMTP id HAA05302; Sat, 16 Dec 2000 07:49:24 -0800 (PST) Received: from localhost (demir@localhost) by aludra.usc.edu (8.9.3.1/8.9.3/usc) with ESMTP id HAA16139; Sat, 16 Dec 2000 07:49:22 -0800 (PST) Date: Sat, 16 Dec 2000 07:49:22 -0800 (PST) From: demir To: Anna Charny cc: "Casati, Alessio (Alessio)" , diffserv@ietf.org, "'Bruce Davie'" Subject: RE: [Diffserv] Possible compromise between EFRESOLVE and draft-charny In-Reply-To: <4.3.2.7.2.20001216010358.00bc0680@pilgrim.cisco.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: diffserv-admin@ietf.org Errors-To: diffserv-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Diffserv Discussion List X-BeenThere: diffserv@ietf.org Anna, > If you know S for a given B and R in EFRESOLVE, this does not tell you the > relationship between these parameters for some other B and R. So you would > either need to give the worst case S for all B and R within the operating > region, or give different S for different regions. In the case of our > definition, once you know a bound on E_p, you can compute the delay bound > for any B and R you choose, and conversely for a delay bound you can > explicitly choose B and R that may give you that bound D from D=B/R + E_p. 100% agreed. > The first part is the color-blind definition (the one with E_a). The > color-blind version of the definition defines the timescale at which the > aggregate is given its configured rate. The color-aware definition is the > one that is used to compute the delay (or delay variation) bound. Depends how "accurate" you are defining "delay variation" meaning what is "low jitter", "low delay-variation". > In contrast, we continue using E_a as a figure of merit, since small E_a > always means that the configured rate is provided to the aggregate at a > small timescale, and large E_a always means a bursty scheduler. I would recommend using different name for E_p in the next version of the draft in order to eliminate "letter-wise" confusion :) > I trust I have answered this question. To reiterate: we believe that 1_a, > defines the timescale of a rate guarantee, which we believe is quite > important for quantifying the services built on top of EF, and can also be > used by those who rely on the rate-based nature of RFC 2598. In contrast, RFC-2598 doesn't have only "rate-based" nature. It has "small time-scale" rate based nature. To me, you have "specified" this time scale at "packet" level using MAX-MIN rate constraint approach. > for any device but strict FIFO, 1_b does not necessarily give a good idea > how well the aggregate is served at its configured rate. However, 1_b > provides the means for computing a bound on delay (or delay variation) as a > function of the input rate and burstiness, which in particular allows to > satisfy the goal of EFRESOLVE of providing a delay bound within a given > operating region. The goal of EFRESOLVE is different and fits RFC-2598 (having problem of S:) What is "low delay-variation"? D(i) < a_constant is also "delay-variation". Alper K. Demir _______________________________________________ diffserv mailing list diffserv@ietf.org http://www1.ietf.org/mailman/listinfo/diffserv Archive: http://www2.ietf.org/mail-archive/working-groups/diffserv/current/maillist.html From diffserv-admin@ietf.org Sat Dec 16 12:19: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 SMTP id MAA00054 for ; Sat, 16 Dec 2000 12:19:26 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id LAA27070; Sat, 16 Dec 2000 11:38:15 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id LAA27039 for ; Sat, 16 Dec 2000 11:38:11 -0500 (EST) Received: from packetbdc.packettech.com (packetbdc.riverdelta.com [198.112.190.11]) by ietf.org (8.9.1a/8.9.1a) with SMTP id LAA19575 for ; Sat, 16 Dec 2000 11:38:09 -0500 (EST) Received: by packetbdc.riverdelta.com with Internet Mail Service (5.5.2650.21) id ; Sat, 16 Dec 2000 11:39:36 -0500 Message-ID: <7F4AC78738EAD2119D86009027626C6D889033@packetbdc.riverdelta.com> From: Jon Bennett To: "'demir'" Cc: "Casati, Alessio (Alessio)" , diffserv@ietf.org Subject: RE: [Diffserv] Yesterday's EF discussion Date: Sat, 16 Dec 2000 11:39:26 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: text/plain; charset="iso-8859-1" Sender: diffserv-admin@ietf.org Errors-To: diffserv-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Diffserv Discussion List X-BeenThere: diffserv@ietf.org Alper, > > We have argued in SD that the definition we propose > > describes two different *aspects* of the same behavior, > > rather than two different behaviors. Both > > aspects of the behavior are useful in evaluating the quality of EF > > Two different aspects of the same behavior is not the same > behavior. It is a new bahavior. > A = {x,y}, B={x}, C={y} B != A, C != A, A == A. I hope this helps. I am afraid it does not help, two different aspects of the same behavior IS the same behavior. Let me make this clear the BEHAVIOR that draft-chary specifies is the same as RFC 2598, that is the device "shall provide a service to the EF aggregate at a configured EF rate over as small a time scale as possible", a device will attempt to do so and however it does will define the BEHAVIOR of the device. The same device could declare the EFRESOLVE tuple of R,B,S or the draft-charny E_a, these would just be methods of MEASURING the behavior, they do not DEFINE the behavior. And our view has been all along that the best way to measure (not define) the behavior is through E_a. This misconception that the either E or S somehow are the definition of the behavior is being repeatedly made and I believe that it is very damaging to the process of understanding the issue. Let me make this point one last time that what we are proposing will define the identical behavior as the current definition of the EF PHB, RFC 2598 by asking you to compare the text of RFC 2598 and the compromise text that we sent to the EFRESOLVE team before the meeting. It is now apparent that we should have sent our entire new text to the list and not just the new equation given the fixation that some people seem to have with this issue. I will assume that from now on it will be clear that we are proposing the identical behavior as RFC 2598. jon ------------------------------------------------ RFC 2598 2. Description of EF per-hop behavior The EF PHB is defined as a forwarding treatment for a particular diffserv aggregate where the departure rate of the aggregate's packets from any diffserv node must equal or exceed a configurable rate. ............ The EF traffic SHOULD receive this rate independent of the intensity of any other traffic attempting to transit the node. It SHOULD average at least the configured rate when measured over any time interval equal to or longer than the time it takes to send an output link MTU sized packet at the configured rate. (Behavior at time scales shorter than a packet time at the configured rate is deliberately not specified.) The configured minimum rate MUST be settable by a network administrator (using whatever mechanism the node supports for non-volatile configuration). --------------------------------------------- OUR COMPROMISE TEXT (as sent to the EFRESOLVE TEAM) 2. The Formal Definition of 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. An EF compliant device MUST specify two error terms that characterize its maximum deviation from ideal behavior. E_a represents the maximum deviation of its actual service rate for the EF aggregate from the ideal service at the configured rate. E_p represents the maximum time a packet can be delayed beyond its ideal departure time in an ideal FIFO server at the configured rate. _______________________________________________ diffserv mailing list diffserv@ietf.org http://www1.ietf.org/mailman/listinfo/diffserv Archive: http://www2.ietf.org/mail-archive/working-groups/diffserv/current/maillist.html From diffserv-admin@ietf.org Sat Dec 16 12:50:54 2000 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with SMTP id MAA07057 for ; Sat, 16 Dec 2000 12:50:49 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id MAA27645; Sat, 16 Dec 2000 12:14:24 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id MAA27620 for ; Sat, 16 Dec 2000 12:14:20 -0500 (EST) Received: from usc.edu (root@usc.edu [128.125.253.136]) by ietf.org (8.9.1a/8.9.1a) with SMTP id MAA28957 for ; Sat, 16 Dec 2000 12:14:18 -0500 (EST) Received: from aludra.usc.edu (demir@aludra.usc.edu [128.125.253.184]) by usc.edu (8.9.3.1/8.9.3/usc) with ESMTP id JAA23926; Sat, 16 Dec 2000 09:14:19 -0800 (PST) Received: from localhost (demir@localhost) by aludra.usc.edu (8.9.3.1/8.9.3/usc) with ESMTP id JAA00439; Sat, 16 Dec 2000 09:14:18 -0800 (PST) Date: Sat, 16 Dec 2000 09:14:17 -0800 (PST) From: demir To: Jon Bennett cc: "Casati, Alessio (Alessio)" , diffserv@ietf.org Subject: RE: [Diffserv] Yesterday's EF discussion In-Reply-To: <7F4AC78738EAD2119D86009027626C6D889033@packetbdc.riverdelta.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 Jon, To me, what I am stating on EF BEHAVIOR and what you are stating on EF BEHAVIOR is that how we "perceive" "EF PHB-RFC 2598" individually. I assume, the authors of EF PHB-2598 are the "right" people who can make "right" decision on our "perception" (please note that I am not saying "only" and you might be among "right"). > I am afraid it does not help, two different aspects of the same behavior IS > the same behavior. Let me make this clear the BEHAVIOR that draft-chary > specifies is the same as RFC 2598, that is the device "shall provide a > service to the EF aggregate at a configured EF rate over as small a time > scale as possible", a device will attempt to do so and however it does will > define the BEHAVIOR of the device. The same device could declare the > EFRESOLVE tuple of R,B,S or the draft-charny E_a, these would just be > methods of MEASURING the behavior, they do not DEFINE the behavior. And our > view has been all along that the best way to measure (not define) the > behavior is through E_a. I am agree with the last part. They are "parameters" for "measurements". I have never intented to use them in my "set" example. It is wrong. Here is how I see the problem (Note: elements are not parameters to define a BEHAVIOR) EF={?}, ? is "unknown element(s)", let's assume for this example EFRESOLVE = {D, DV} U {R}, where {R} is not explicitly stated, and needs clarification, I might be wrong CHARNY = {D, R} U {dv}, again that's how I see, I might be wrong Note 1: R is what you stated above about rate Note 2: For short, "BEHAVIOR" word is omitted Question 1: is DV == dv ? (a simple question) Question 2: is EFRSOLVE == EF ? Question 3: is CHARNY == EF ? These are the 3 questions that we are trying to address (the exam will over in an hour :) > This misconception that the either E or S somehow are the definition of the > behavior is being repeatedly made and I believe that it is very damaging to > the process of understanding the issue. 100% agreed. I hope I am not one of them. > Let me make this point one last time that what we are proposing will define > the identical behavior as the current definition of the EF PHB, RFC 2598 by > asking you to compare the text of RFC 2598 and the compromise text that we > sent to the EFRESOLVE team before the meeting. Last time :) > It is now apparent that we should have sent our entire new text to the list > and not just the new equation given the fixation that some people seem to > have with this issue. I will assume that from now on it will be clear that > we are proposing the identical behavior as RFC 2598. If you are refereing to me when I posted some "equations", They were not intended for "BEHAVIOR" discussion. they were intended for particular "compromise ... draft-charny". The "identical" is a very "critical" term here :) some more criticals: "same","equivalent",... Needs clarificifation. Alper K. Demir _______________________________________________ diffserv mailing list diffserv@ietf.org http://www1.ietf.org/mailman/listinfo/diffserv Archive: http://www2.ietf.org/mail-archive/working-groups/diffserv/current/maillist.html From diffserv-admin@ietf.org Sat Dec 16 14:27: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 SMTP id OAA29259 for ; Sat, 16 Dec 2000 14:27:55 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id NAA28559; Sat, 16 Dec 2000 13:42:28 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id NAA28533 for ; Sat, 16 Dec 2000 13:42:24 -0500 (EST) Received: from ihemail2.firewall.lucent.com (ihemail2.lucent.com [192.11.222.163]) by ietf.org (8.9.1a/8.9.1a) with SMTP id NAA18630 for ; Sat, 16 Dec 2000 13:42:23 -0500 (EST) Received: from ihemail2.firewall.lucent.com (localhost [127.0.0.1]) by ihemail2.firewall.lucent.com (Pro-8.9.3/8.9.3) with ESMTP id NAA06808 for ; Sat, 16 Dec 2000 13:42:23 -0500 (EST) Received: from uk0006exch001h.wins.lucent.com (h135-86-160-150.lucent.com [135.86.160.150]) by ihemail2.firewall.lucent.com (Pro-8.9.3/8.9.3) with ESMTP id NAA06799 for ; Sat, 16 Dec 2000 13:42:22 -0500 (EST) Received: by uk0006exch001h.uk.lucent.com with Internet Mail Service (5.5.2650.21) id ; Sat, 16 Dec 2000 18:42:22 -0000 Message-ID: <976F7C55E3B2D111A0720008C728549C04877631@en0060exch001u.uk.lucent.com> From: "Casati, Alessio (Alessio)" To: diffserv@ietf.org, "'Bruce Davie'" , "'Anna Charny'" Date: Sat, 16 Dec 2000 18:42:20 -0000 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: text/plain; charset="iso-8859-1" Subject: [Diffserv] The compromise is actually 2 PHBs as per Anna 's message. Sender: diffserv-admin@ietf.org Errors-To: diffserv-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Diffserv Discussion List X-BeenThere: diffserv@ietf.org Anna, > Alessio, > > Here are some responses. > > > > under our "color-aware" definition when the offered > > > load to an output is bounded by rate R and burst size B, the maximum > > > per-packet delay is B/R + E_p. Clearly both definitions provide > bounded > > > delay under well-defined operating conditions. The second part of our > > > definition addresses the intent of EFRESOLVE, but differs from > EFRESOLVE > > > in > > > that it provides well-defined behavior for arbitrary inputs. > > > > >How? could you elaborate on this? What is the intended behaviour when the > >burst is exceeded? and what is the behaviour when the input rate is > >exceeded? > > > First, there is no limit on the burst or input rate that our definition > works with - the input rate and the burst is whatever it happens to > be. Clearly, for some input patterns there will be some loss, but the > definition of exactly which packets should or should not be dropped is > outside the scope of the definition of EF PHB. > this exactly is a statement confirming you don't specify the behaviour outside an operating region, which proves Bruce's claim FALSE. > For the lossless case, the behavior is fully defined for all packets for > arbitrary inputs which cause no loss. > For the case when there is loss, the behavior is fully defined *for all > those packets that were not dropped* (for the purposes of the conformance > test, the lost packets are simply taken out of the input stream, and the > definition is then applied only to packets that were not lost). > OK, but your statement equals to saying that if a packet is not dropped it gets delivered. We are interested in the behaviour within the operating region, outside of it is not EF, and you don't provide any better clue than we do. Let's face it, your position is a bit stretched... > > > In addition > > > while EFRESOLVE gives a fixed delay within a specified operating > region, > > > > >I thought we were giving a bound on the delay variation, not a fixed > >delay... > >clarification from you is expected. > > Quite true, this was a typo. > I would say a mistake. > It does not really matter though, since as > long as you know the minimal propagation time through the device (which is > > quite easy to specify), you can immediately compute the delay bound from > the bound on delay variation. > We feel that knowing the fixed propagation > time in addition to delay variation is quite useful since otherwise a > definition based entirely on delay variation bound allows devices with > infinite internal delay to be conformant. > this is unrelated to bruce's statement. And the fixed delay bound is service and operator choice. You cannot specify it (and in fact you don't in the draft). Again A WRONG STATEMENT HAS BEEN SUPPORTED BY A FALSE STATEMENT (the E_* terms allow for unspecified fixed delay) > > > our new definition allows an operator to achieve different performance > > > goals > > > by specifying different ranges of B and R that achieve the desired > delay > > > bounds. > > > > >I thought that we where not preventing an operator from doing so. Where > in > >the > >definition you detect this? > > If you know S for a given B and R in EFRESOLVE, this does not tell you the > > relationship between these parameters for some other B and R. > WRONG STATEMENT. You would use another S. Note that your E_a nad E_p could change too:). > So you would > either need to give the worst case S for all B and R within the operating > region, or give different S for different regions. > Why do you use a OR? We do both, in fact. We do an AND :). > In the case of our > definition, once you know a bound on E_p, you can compute the delay bound > for any B and R you choose, and conversely for a delay bound you can > explicitly choose B and R that may give you that bound D from D=B/R + E_p. > We state that S*MTU/R is a delay variation bound associated to a router config and burstiness. So we are doing pretty much the same ;). > > > The first part of the definition allows existing and operational > > > rate-based > > > implementations and deployments of the EF PHB to continue to be > deployed > > > and operated (e.g EF implementation in Internet 2 managed by Bandwidth > > > Brokers). > > > > >do you mean that delay variation is not a goal that the > >first part of your definition is aiming at? > >what are the equations you associate to the first part? > > The first part is the color-blind definition (the one with E_a). The > color-blind version of the definition defines the timescale at which the > aggregate is given its configured rate. The color-aware definition is the > one that is used to compute the delay (or delay variation) bound. > Well, this then makes really clear that you actually have two PHBs, since you are stating that the color blind definition allows compliance of existing implementations, so an acceptable PHB would comply with the first part, and the other would be irrelevant. THIS PROVES YOU HAVE DEFINED 2 PHBs and SOLD THEM AS ONE. > > > The second part of the definition provides the machinery for > > > computing the delay bound as a function of the operating conditions. > > > > > > > > > ---------- > > > Equations for those who care: > > > > >I care: > > > > > The original colorblind equations from draft-charny-...-01 are eq_1a > and > > > eq_2a. The new ones that achieve the compromise are eq_1b and eq_2b. > > > Although the latter equations are not in draft-charny...01, the > intuitive > > > description of the equations in that draft may still be helpful in > > > understanding the equations. > > > > > > D(j) <= F(j) + E_a > (eq_1a) > > > > > > > >the need to keep this equation (eq_1a) is unclear to me. > >1b should suffice, isn't it? what makes 1a compelling in the definition? > > If your service is strict FIFO, then indeed 1a and 1b are > redundant. However, in practice there is no such thing as a FIFO device - > > even minimal internal jitter makes a box non-FIFO. So in practice 1a > and > 1b are always different. > 1-a nad 1-b are always different independent of the minimal internal jitter in a router :). SO, let's move on... > You can have very smooth rate service given to an > aggregate (small E_a), but within the aggregate some packets may be served > > quite a bit later than they would have been in a FIFO server (large > E_p). This means that your aggregate service may be very accurate, while > per-packet delay may still be large. > Exactly. So, for EF purposes we care only about 1_b. I WOULD SUPPORT 1-a is UNNECESSARY FOR EF DEFINITION. To me 1-a is there just to justify your draft as COMPROMISE:). > >Let's now consider > > > > > d(j) <= f(j) + E_p > (eq_1b) > > > > >and > > > > > under our "color-aware" definition when the offered > > > load to an output is bounded by rate R and burst size B, the maximum > > per-packet delay is B/R + E_p > > > >It occurs to me that Ep is dependent on the relative distribution > >over the input interfaces of the input rate (which you correctly state is > >assumed to be up to > >R) > > and the scheduler weight settings / router config. So, E_p is not a > >parameter > >that can be used to evaluate the goodness of a scheduler or router since > it > >depends on > >the configuration of the scheduler and the router, and also from network > >dependent aspects (the distribution of the input rate, which in turn > >influences > >or may influence the router configuration). > > This is entirely true - E_p is not a parameter that can be used to > evaluate > the goodness of the the device. That is why we actually decided against > having E_p in our original version of the draft and chose the color-blind > definition. E_p has many of the same problems as S in EFRESOLVE and is > provided in the compromise definition to enable those who want a bound on > per packet delay (or its deviation) to enable the same functionality as > was > intended by EFRESOLVE within its operating region. One other benefit of > having some E_p, even if very large, is to address the concern that a > scheduler with small E_a may silently hide a very large per-packet delay. > In the compromise definition such a device will have a small E_a and > large > E_p, and thus will no longer hide the fact that per-packet delay is large. > So, THIS STATES: "EFRESOLVE IS JUST FINE: WE ADDED THIS TO FIX OUR (BUGGY) DEFINITION, WHICH WAS NOT REALLY EF". SO, decency would call for the group of twelve to concede, at this point in time that the only meaningful part for EF is what has been added in the compromise (1-b) and I trust you to verify that using EFRESOLVE would have not been any worse. > Just as is the case with S of EFRESOLVE, for some schedulers E_p will be > large, for others it may be small. In some cases large (or even infinite) > > E_p will mean a good scheduler, and for some schedulers large E_p will > mean > a bad scheduler. > There is no relationship between S and E_p. FALSE STATEMENT. > Note that we do NOT intend to use E_p as a > figure-of-merit. Evaluating the meaning of the magnitude of E_p will > require knowledge of the details of a particular scheduler, exactly as in > the case with S of EFRESOLVE. > With the difference EFRESOLVE does this with less ROCKET SCIENCE haze around it. > In contrast, we continue using E_a as a figure of merit, since small E_a > always means that the configured rate is provided to the aggregate at a > small timescale, and large E_a always means a bursty scheduler. > But, this is part of a benchmarking exercise outside the SCOPE OF EF. An informational RFC would be more appropriate for this. > >As such what is the usefulness of this equation (1_b), and what makes > this > >more appropriate than saying that the delay variation must be bounded, as > >per EFRESOLVE? > > I trust I have answered this question. > I'm satisfied with your answers, that confirm my fears. > To reiterate: we believe that 1_a, > defines the timescale of a rate guarantee, which we believe is quite > important for quantifying the services built on top of EF, and can also be > > used by those who rely on the rate-based nature of RFC 2598. > The benchmarking aspect should be part of an info RFC, the rate based only compliance is unacceptable, and should be rejected by the WG, I hope. > In contrast, > for any device but strict FIFO, 1_b does not necessarily give a good idea > > how well the aggregate is served at its configured rate. > But this is of no interest for EF. EF cares of per packet delay variation, not aggregate service rate per se. > However, 1_b > provides the means for computing a bound on delay (or delay variation) as > a > function of the input rate and burstiness, which in particular allows to > satisfy the goal of EFRESOLVE of providing a delay bound within a given > operating region. > So, the useful part of the compromise matches EFRESOLVE. THE WG NOW HAS A CLEAR PICTURE. alessio _______________________________________________ diffserv mailing list diffserv@ietf.org http://www1.ietf.org/mailman/listinfo/diffserv Archive: http://www2.ietf.org/mail-archive/working-groups/diffserv/current/maillist.html From diffserv-admin@ietf.org Sat Dec 16 17:39: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 SMTP id RAA03004 for ; Sat, 16 Dec 2000 17:39:07 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id QAA29745; Sat, 16 Dec 2000 16:27:31 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id QAA29714 for ; Sat, 16 Dec 2000 16:27:27 -0500 (EST) Received: from usc.edu (root@usc.edu [128.125.253.136]) by ietf.org (8.9.1a/8.9.1a) with SMTP id QAA25087 for ; Sat, 16 Dec 2000 16:27:24 -0500 (EST) Received: from aludra.usc.edu (demir@aludra.usc.edu [128.125.253.184]) by usc.edu (8.9.3.1/8.9.3/usc) with ESMTP id NAA28389; Sat, 16 Dec 2000 13:27:24 -0800 (PST) Received: from localhost (demir@localhost) by aludra.usc.edu (8.9.3.1/8.9.3/usc) with ESMTP id NAA01721; Sat, 16 Dec 2000 13:27:24 -0800 (PST) Date: Sat, 16 Dec 2000 13:27:24 -0800 (PST) From: demir To: "Casati, Alessio (Alessio)" cc: diffserv@ietf.org, "'Bruce Davie'" , "'Anna Charny'" Subject: Re: [Diffserv] The compromise is actually 2 PHBs as per Anna 's message. In-Reply-To: <976F7C55E3B2D111A0720008C728549C04877631@en0060exch001u.uk.lucent.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 Alessio, > OK, but your statement equals to saying that > if a packet is not dropped it gets delivered. > We are interested in the behaviour within the operating region, > outside of it is not EF, and you don't provide > any better clue than we do. > Let's face it, your position is a bit > stretched... Exactly. I agree with you 100%. I have made above point along time ago. I told RFC-2598 is fine. Kathleen told me that it is required to "RESOLVE" it. I don't have any problem with accepting this. Let's "evaluate" the situation. Two solutions has been proposed. As you are stating above they have "clue" problem. I agree. I have said this before and saying this again: What two solution is trying to do is that trying to "embed" specific "algorithms" into the EF. The problem is: D(i) < delay_bound_function(input_parameters) (low delay) D(i) - E(i) < delay_variance_function(input_parameters) (low-jitter) "low delay" and "low jitter" statements are already in the RFC-2598. The problem is that is it ever "possible" to "embed" a specific "algorithm" into EF (I mentioned that AF is not doing this. I agree they are intended for different puposes). I got the respose that it is "okay". No problem. So what is the way to achieve this? i) "Embed something" "immature" into the EF? ii) Express this in words? iii) Leave it to a PDB/and/or an EF "implementation"? RFC-2598 doesn't specify any specific "algorithm" regarding to "input output rate v.s. small time-scale". Charny draft has solved this with "packet level MAX-MIN" approach. I give alot of credit for that. However, this is "only" a "specific" algorithm. If you are familiar with "fair queuing", similar approaches are valid for FQ, too. These are "implementation" issues as if in the case of "low-delay", "low-jitter". It would be nice to clarify them in RFC-2598. However, the way of clarification is "important". Alper K. Demir _______________________________________________ diffserv mailing list diffserv@ietf.org http://www1.ietf.org/mailman/listinfo/diffserv Archive: http://www2.ietf.org/mail-archive/working-groups/diffserv/current/maillist.html From diffserv-admin@ietf.org Sun Dec 17 11:55: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 SMTP id LAA02697 for ; Sun, 17 Dec 2000 11:55:50 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id LAA13516; Sun, 17 Dec 2000 11:18:11 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id LAA13493 for ; Sun, 17 Dec 2000 11:18:08 -0500 (EST) Received: from bells.cs.ucl.ac.uk (bells.cs.ucl.ac.uk [128.16.5.31]) by ietf.org (8.9.1a/8.9.1a) with SMTP id LAA26111 for ; Sun, 17 Dec 2000 11:18:05 -0500 (EST) Received: from sonic.cs.ucl.ac.uk by bells.cs.ucl.ac.uk with local SMTP id ; Sun, 17 Dec 2000 16:17:55 +0000 to: diffserv@ietf.org Subject: Re: [Diffserv] The compromise is actually 2 PHBs as per Anna 's message. In-reply-to: Your message of "Sat, 16 Dec 2000 13:27:24 PST." Date: Sun, 17 Dec 2000 16:17:55 +0000 Message-ID: <2368.977069875@cs.ucl.ac.uk> From: Jon Crowcroft Sender: diffserv-admin@ietf.org Errors-To: diffserv-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Diffserv Discussion List X-BeenThere: diffserv@ietf.org whatever van wanted, whatever we thugh the RFC said whatever the history, i accept that we now have a useful PHB specification - whatever its name and i guess people are mostly going to be on the same side on the list as were in the face2face meeting however, it has two modes of application - color aware and color blind - so we could have 1 PHB but with 2 different services - i..e the debate should move on (soon) to what we really want out of VW... and whether there could be two PDBs made from one PHB - it seems to me that one useful PDB is certainly the one documented and on hold and intended to be supported in a parsimoniuous way by the old PHB - this can stil be suported by the new PHB in color aware mode....there's also a service (oops, sory PDB) that seems to be wanted which has more parameters - (will be visible in the SLA) which is a rate with optinal delay distribution or bound....this is also a candidate for a "wet wire".... next... cheers jon _______________________________________________ diffserv mailing list diffserv@ietf.org http://www1.ietf.org/mailman/listinfo/diffserv Archive: http://www2.ietf.org/mail-archive/working-groups/diffserv/current/maillist.html From diffserv-admin@ietf.org Sun Dec 17 14:40: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 SMTP id OAA27678 for ; Sun, 17 Dec 2000 14:40:30 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id NAA14681; Sun, 17 Dec 2000 13:28:04 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id NAA14653 for ; Sun, 17 Dec 2000 13:28:00 -0500 (EST) Received: from smtppop1pub.verizon.net (smtppop1pub.gte.net [206.46.170.20]) by ietf.org (8.9.1a/8.9.1a) with SMTP id NAA17291 for ; Sun, 17 Dec 2000 13:27:57 -0500 (EST) Received: from PROXIM (lsanca1-ar5-217-030.dsl.gtei.net [4.33.217.30]) by smtppop1pub.verizon.net with SMTP ; id MAA37123954 Sun, 17 Dec 2000 12:22:04 -0600 (CST) Message-ID: <000701c06857$16d9f480$2ed4e00a@vz.dsl.genuity.net> From: "Bill Courtney" To: , "Jon Crowcroft" References: <2368.977069875@cs.ucl.ac.uk> Subject: Re: [Diffserv] The compromise is actually 2 PHBs as per Anna 's message. Date: Sun, 17 Dec 2000 10:28:00 -0800 MIME-Version: 1.0 Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.50.4133.2400 X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4133.2400 Content-Transfer-Encoding: 7bit Sender: diffserv-admin@ietf.org Errors-To: diffserv-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Diffserv Discussion List X-BeenThere: diffserv@ietf.org Content-Transfer-Encoding: 7bit Hi Jon, What is a "wet wire?" Cheers, Bill > - so we could have 1 PHB but with 2 different services - i..e the > debate should move on (soon) to what we really want out of VW... > and whether there could be two PDBs made from one PHB - it seems to > me that one useful PDB is certainly the one documented and on hold and > intended to be supported in a parsimoniuous way by the old PHB - this > can stil be suported by the new PHB in color aware mode....there's > also a service (oops, sory PDB) that seems to be wanted which has more > parameters - (will be visible in the SLA) which is a rate with optinal > delay distribution or bound....this is also a candidate for a "wet > wire".... _______________________________________________ diffserv mailing list diffserv@ietf.org http://www1.ietf.org/mailman/listinfo/diffserv Archive: http://www2.ietf.org/mail-archive/working-groups/diffserv/current/maillist.html From diffserv-admin@ietf.org Sun Dec 17 18:53: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 SMTP id SAA04868 for ; Sun, 17 Dec 2000 18:53:32 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id SAA17131; Sun, 17 Dec 2000 18:22:18 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id SAA17098 for ; Sun, 17 Dec 2000 18:22:14 -0500 (EST) Received: from ihemail1.firewall.lucent.com (ihemail1.lucent.com [192.11.222.161]) by ietf.org (8.9.1a/8.9.1a) with SMTP id SAA29464 for ; Sun, 17 Dec 2000 18:22:12 -0500 (EST) Received: from ihemail1.firewall.lucent.com (localhost [127.0.0.1]) by ihemail1.firewall.lucent.com (Pro-8.9.3/8.9.3) with ESMTP id SAA18928 for ; Sun, 17 Dec 2000 18:22:14 -0500 (EST) Received: from uk0006exch001h.wins.lucent.com (h135-86-160-150.lucent.com [135.86.160.150]) by ihemail1.firewall.lucent.com (Pro-8.9.3/8.9.3) with ESMTP id SAA18919 for ; Sun, 17 Dec 2000 18:22:14 -0500 (EST) Received: by uk0006exch001h.uk.lucent.com with Internet Mail Service (5.5.2650.21) id ; Sun, 17 Dec 2000 23:22:13 -0000 Message-ID: <976F7C55E3B2D111A0720008C728549C04877632@en0060exch001u.uk.lucent.com> From: "Casati, Alessio (Alessio)" To: diffserv@ietf.org, "'Jon Crowcroft'" Subject: RE: [Diffserv] The compromise is actually 2 PHBs as per Anna 's message. Date: Sun, 17 Dec 2000 23:22:12 -0000 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: text/plain Sender: diffserv-admin@ietf.org Errors-To: diffserv-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Diffserv Discussion List X-BeenThere: diffserv@ietf.org > whatever van wanted, whatever we thugh the RFC said > whatever the history, i accept that > we now have a useful PHB specification - > however, it has two modes of application - color aware and color > blind > > This implies two PHBs in diffserv terms. alessio _______________________________________________ diffserv mailing list diffserv@ietf.org http://www1.ietf.org/mailman/listinfo/diffserv Archive: http://www2.ietf.org/mail-archive/working-groups/diffserv/current/maillist.html From diffserv-admin@ietf.org Mon Dec 18 03:51:41 2000 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with SMTP id DAA06609 for ; Mon, 18 Dec 2000 03:51:41 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id DAA27840; Mon, 18 Dec 2000 03:24:30 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id DAA27813 for ; Mon, 18 Dec 2000 03:24:26 -0500 (EST) Received: from bells.cs.ucl.ac.uk (bells.cs.ucl.ac.uk [128.16.5.31]) by ietf.org (8.9.1a/8.9.1a) with SMTP id DAA06408 for ; Mon, 18 Dec 2000 03:24:25 -0500 (EST) Received: from hocus.cs.ucl.ac.uk by bells.cs.ucl.ac.uk with local SMTP id ; Mon, 18 Dec 2000 08:24:02 +0000 To: "Casati, Alessio (Alessio)" cc: diffserv@ietf.org Subject: Re: [Diffserv] The compromise is actually 2 PHBs as per Anna 's message. In-reply-to: Your message of "Sun, 17 Dec 2000 23:22:12 GMT." <976F7C55E3B2D111A0720008C728549C04877632@en0060exch001u.uk.lucent.com> Date: Mon, 18 Dec 2000 08:24:01 +0000 Message-ID: <725.977127841@cs.ucl.ac.uk> From: Jon Crowcroft Sender: diffserv-admin@ietf.org Errors-To: diffserv-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Diffserv Discussion List X-BeenThere: diffserv@ietf.org In message <976F7C55E3B2D111A0720008C728549C04877632@en0060exch001u.uk.lucent.c om>, "Casati, Alessio (Alessio)" typed: >>> whatever van wanted, whatever we thugh the RFC said >>> whatever the history, i accept that >>> we now have a useful PHB specification - >>> however, it has two modes of application - color aware and color >>> blind >>This implies two PHBs in diffserv terms. alessio i was afraid you'd say that! i think you're prob. right. thats ok though - at least we understand both of them! cheers jon _______________________________________________ diffserv mailing list diffserv@ietf.org http://www1.ietf.org/mailman/listinfo/diffserv Archive: http://www2.ietf.org/mail-archive/working-groups/diffserv/current/maillist.html From diffserv-admin@ietf.org Mon Dec 18 10:23:29 2000 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with SMTP id KAA09682 for ; Mon, 18 Dec 2000 10:23:25 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id JAA01308; Mon, 18 Dec 2000 09:38:05 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id JAA01277 for ; Mon, 18 Dec 2000 09:38:01 -0500 (EST) Received: from pmesmtp02.wcom.com (pmesmtp02.wcom.com [199.249.20.2]) by ietf.org (8.9.1a/8.9.1a) with SMTP id JAA09077 for ; Mon, 18 Dec 2000 09:37:59 -0500 (EST) Received: from CONVERSION-DAEMON by firewall.mcit.com (PMDF V5.2-32 #42257) id <0G5R00701PYG75@firewall.mcit.com> for diffserv@ietf.org; Mon, 18 Dec 2000 14:37:28 +0000 (GMT) Received: from pmismtp03.wcomnet.com ([166.38.62.38]) by firewall.mcit.com (PMDF V5.2-32 #42257) with ESMTP id <0G5R00673PYGJ6@firewall.mcit.com>; Mon, 18 Dec 2000 14:37:28 +0000 (GMT) Received: from CONVERSION-DAEMON by pmismtp03.wcomnet.com (PMDF V5.2-33 #42258) id <0G5R00501PYFUA@pmismtp03.wcomnet.com>; Mon, 18 Dec 2000 14:37:27 +0000 (GMT) Received: from pmismtp03.wcomnet.com by pmismtp03.wcomnet.com (PMDF V5.2-33 #42258) with SMTP id <0G5R00501PYFU8@pmismtp03.wcomnet.com>; Mon, 18 Dec 2000 14:37:27 +0000 (GMT) Received: from pc007978875 ([166.60.2.13]) by pmismtp03.wcomnet.com (PMDF V5.2-33 #42258) with SMTP id <0G5R004A9PXXDN@pmismtp03.wcomnet.com>; Mon, 18 Dec 2000 14:37:09 +0000 (GMT) Date: Mon, 18 Dec 2000 09:37:04 -0500 From: Dave McDysan Subject: RE: [Diffserv] Yesterday's EF discussion In-reply-to: <4.1.20001215125733.00983ba0@diablo.cisco.com> To: John Schnizlein Cc: Diff Serv Message-id: MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V5.00.2314.1300 X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2910.0) Content-type: text/plain; charset=iso-8859-1 Content-transfer-encoding: 7bit Importance: Normal X-Priority: 3 (Normal) X-MSMail-priority: 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 This was the text in RFC 2598 that I was referring to: If the EF PHB is implemented by a mechanism that allows unlimited preemption of other traffic (e.g., a priority queue), the implementation MUST include some means to limit the damage EF traffic could inflict on other traffic (e.g., a token bucket rate limiter). Traffic that exceeds this limit MUST be discarded. This maximum EF rate, and burst size if appropriate, MUST be settable by a network administrator (using whatever mechanism the node supports for non- volatile configuration). The minimum and maximum rates may be the same and configured by a single parameter. Dave > -----Original Message----- > From: John Schnizlein [mailto:jschnizl@cisco.com] > Sent: Friday, December 15, 2000 1:00 PM > To: Dave McDysan > Cc: Diff Serv > Subject: RE: [Diffserv] Yesterday's EF discussion > > > At 07:15 PM 12/14/2000 -0500, Dave McDysan wrote: > > > >For me, Expedited Forwarding is an easy to explain reference to > >priority queuing, which by all accounts is a viable implementation > >of this PHB (with limits to protect other traffic, as stated in 2598). > > Yes, I suspect this interpretation of "implementation" is all there is. > I begs the question of how these implementations depend on a rate > guarantee over a fixed interval. Last time I looked, priority queuing > just drains the high priority queue at line rate. > > John _______________________________________________ diffserv mailing list diffserv@ietf.org http://www1.ietf.org/mailman/listinfo/diffserv Archive: http://www2.ietf.org/mail-archive/working-groups/diffserv/current/maillist.html From diffserv-admin@ietf.org Mon Dec 18 11:46:31 2000 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with SMTP id LAA10847 for ; Mon, 18 Dec 2000 11:46:27 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id KAA02209; Mon, 18 Dec 2000 10:52:23 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id KAA02187 for ; Mon, 18 Dec 2000 10:52:19 -0500 (EST) Received: from diablo.cisco.com (diablo.cisco.com [171.68.224.210]) by ietf.org (8.9.1a/8.9.1a) with SMTP id KAA09971 for ; Mon, 18 Dec 2000 10:52:18 -0500 (EST) Received: from jschnizl1-pc (jschnizl-isdn1.cisco.com [171.68.12.74]) by diablo.cisco.com (8.8.6 (PHNE_14041)/CISCO.SERVER.1.2) with SMTP id HAA24786; Mon, 18 Dec 2000 07:50:14 -0800 (PST) Message-Id: <4.1.20001218101730.00911e20@diablo.cisco.com> X-Sender: jschnizl@diablo.cisco.com X-Mailer: QUALCOMM Windows Eudora Pro Version 4.1 Date: Mon, 18 Dec 2000 10:25:25 -0500 To: "Fulu Li" From: John Schnizlein Cc: diffserv@ietf.org In-Reply-To: <353093573B82D411889E0000F80821662E4B73@zcard00q.ca.nortel. com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Subject: [Diffserv] RE: Yesterday's EF discussion Sender: diffserv-admin@ietf.org Errors-To: diffserv-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Diffserv Discussion List X-BeenThere: diffserv@ietf.org At 05:02 PM 12/15/2000 -0500, Fulu Li wrote: > > Did you miss this email? > >http://www2.ietf.org/mail-archive/working groups/diffserv/current/msg02677.html No, I did not miss it. I am familiar with how Cisco supports the deployment of EF. I am familiar with the diffserv testbed in Internet-2. I do not see any dependence on the particular (mis)interprestation of of Van's intended bound on delay variance in either. My question seeks implementations that require a rate bound. John _______________________________________________ diffserv mailing list diffserv@ietf.org http://www1.ietf.org/mailman/listinfo/diffserv Archive: http://www2.ietf.org/mail-archive/working-groups/diffserv/current/maillist.html From diffserv-admin@ietf.org Mon Dec 18 12:55: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 SMTP id MAA11990 for ; Mon, 18 Dec 2000 12:55:47 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id MAA03493; Mon, 18 Dec 2000 12:05:33 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id MAA03464 for ; Mon, 18 Dec 2000 12:05:29 -0500 (EST) Received: from packetbdc.packettech.com (packetbdc.riverdelta.com [198.112.190.11]) by ietf.org (8.9.1a/8.9.1a) with SMTP id MAA11342 for ; Mon, 18 Dec 2000 12:05:29 -0500 (EST) Received: by packetbdc.riverdelta.com with Internet Mail Service (5.5.2650.21) id ; Mon, 18 Dec 2000 12:07:00 -0500 Message-ID: <7F4AC78738EAD2119D86009027626C6D889036@packetbdc.riverdelta.com> From: Jon Bennett To: "'John Schnizlein'" , Fulu Li Cc: diffserv@ietf.org Subject: RE: [Diffserv] RE: Yesterday's EF discussion Date: Mon, 18 Dec 2000 12:06:59 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: text/plain; charset="iso-8859-1" Sender: diffserv-admin@ietf.org Errors-To: diffserv-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Diffserv Discussion List X-BeenThere: diffserv@ietf.org John, > At 05:02 PM 12/15/2000 -0500, Fulu Li wrote: > > > > Did you miss this email? > > > >http://www2.ietf.org/mail-archive/working > groups/diffserv/current/msg02677.html > > No, I did not miss it. And? you just didn't feel like responding to it? > I am familiar with how Cisco supports the deployment of EF. > I am familiar with the diffserv testbed in Internet-2. > I do not see any dependence on the particular (mis)interprestation > of of Van's intended bound on delay variance in either. Its funny, I am also familiar with those things as well, and having actually heard Van explain the operation of the BANDWIDTH brokers in Internet2 I do see the dependence on the rate bound. But you know something, it doesn't really matter what Van thinks since the RFC is a product of the WG and not his personal property. If you wish I can start posting references to all the Internet2 project documentation that specifies the BANDWIDTH broker operation and the SLA guarantees in terms of RATES and not in terms of jitter, would you like me to do that? Or perhaps could we agree that low jitter is a by-product of a tight rate guarantee instead of continuing to pretend that somehow the words "departure rate of the aggregate" actually mean "jitter bound of the individual packets". > My question seeks implementations that require a rate bound. I answered that question in my message http://www2.ietf.org/mail-archive/working-groups/diffserv/current/msg02696.h tml but again for some reason you did not respond to it. jon _______________________________________________ diffserv mailing list diffserv@ietf.org http://www1.ietf.org/mailman/listinfo/diffserv Archive: http://www2.ietf.org/mail-archive/working-groups/diffserv/current/maillist.html From diffserv-admin@ietf.org Mon Dec 18 14:25: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 SMTP id OAA13595 for ; Mon, 18 Dec 2000 14:25:13 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id NAA04851; Mon, 18 Dec 2000 13:38:28 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id NAA04821 for ; Mon, 18 Dec 2000 13:38:24 -0500 (EST) Received: from hoemail2.firewall.lucent.com (hoemail2.lucent.com [192.11.226.163]) by ietf.org (8.9.1a/8.9.1a) with SMTP id NAA12756 for ; Mon, 18 Dec 2000 13:38:24 -0500 (EST) Received: from hoemail2.firewall.lucent.com (localhost [127.0.0.1]) by hoemail2.firewall.lucent.com (Pro-8.9.3/8.9.3) with ESMTP id NAA17724 for ; Mon, 18 Dec 2000 13:38:24 -0500 (EST) Received: from uk0006exch001h.wins.lucent.com (h135-86-160-150.lucent.com [135.86.160.150]) by hoemail2.firewall.lucent.com (Pro-8.9.3/8.9.3) with ESMTP id NAA17703 for ; Mon, 18 Dec 2000 13:38:23 -0500 (EST) Received: by uk0006exch001h.uk.lucent.com with Internet Mail Service (5.5.2650.21) id ; Mon, 18 Dec 2000 18:38:23 -0000 Message-ID: <976F7C55E3B2D111A0720008C728549C04877646@en0060exch001u.uk.lucent.com> From: "Casati, Alessio (Alessio)" To: "'Jon Bennett'" Cc: diffserv@ietf.org Subject: RE: [Diffserv] RE: Yesterday's EF discussion Date: Mon, 18 Dec 2000 18:38:21 -0000 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: text/plain Sender: diffserv-admin@ietf.org Errors-To: diffserv-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Diffserv Discussion List X-BeenThere: diffserv@ietf.org > Its funny, I am also familiar with those things as well, and having > actually > heard Van explain the operation of the BANDWIDTH brokers in Internet2 I do > see the dependence on the rate bound. But you know something, it doesn't > really matter what Van thinks since the RFC is a product of the WG and not > his personal property. If you wish I can start posting references to all > the > Internet2 project documentation that specifies the BANDWIDTH broker > operation and the SLA guarantees in terms of RATES and not in terms of > jitter, would you like me to do that? > No, thanks. We can try and discuss anyway. The SLA is a service level specification stipulated between two diffserv domains. Rate is a service level parameter, valid at the edge. Nothing can be said about the rate configured (if no PQ is used) within the domain, and that the rate guarantee per se is what is needed within the domain. The diffserv domain guarantees that EF traffic delivered at that edge from a foreign domain with specified bounds on burstiness (close to zero) and rate (the virtual wire rate), gets delivered at the egress as if sent over a wire (or approximate that ideal behaviour). The way this is possible is via PHB that allows aggregation of a number of customer networks in a way that they do not affect one another. This is possible via a PHB that provides strict guarantees in terms of delay variation across a hop. This is the only way that allows aggregation without uncontrolled burst accumulation, that would result in the service not being delivered end to end to the customer network asking for a "virtual wire". So, back to our issue, the per hop guarantee is a delay variation guarantee. Whether that is achieved via a color aware configured rate, priority Queuing with non EF traffic starvation protection, this is entirely dependent on the router instance selected by the operator. There are a lot of other knobs that may be used to deliver a delay variation bound, and it would not be wise to specify all of them. So, output Rate is one of the knobs to achieve the per hop delay variation guarantee, if we like. But not what should be used to describe the PHB. By the way, it is clear that low per hop fixed delay values are desirable, but the virtual wire per se does not specify a universally acceptable delay value (that is, the length of the virtual wire is not going to be mandated by the standard:). Are we on the same page now? This is what Van meant, what EFRESOLVE is, and what I suggest the WG should ask the spec to specify. The fact that Van in the original version stated that the output rate (delivered with some tight constrains) on an interface cannot be lower than the input is a truism, but not what the PHB is in essence. alessio _______________________________________________ diffserv mailing list diffserv@ietf.org http://www1.ietf.org/mailman/listinfo/diffserv Archive: http://www2.ietf.org/mail-archive/working-groups/diffserv/current/maillist.html From diffserv-admin@ietf.org Mon Dec 18 15:02: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 SMTP id PAA14284 for ; Mon, 18 Dec 2000 15:02:00 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id OAA05486; Mon, 18 Dec 2000 14:22:42 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id OAA05458 for ; Mon, 18 Dec 2000 14:22:38 -0500 (EST) Received: from packetbdc.packettech.com (packetbdc.riverdelta.com [198.112.190.11]) by ietf.org (8.9.1a/8.9.1a) with SMTP id OAA13543 for ; Mon, 18 Dec 2000 14:22:39 -0500 (EST) Received: by packetbdc.riverdelta.com with Internet Mail Service (5.5.2650.21) id ; Mon, 18 Dec 2000 14:24:09 -0500 Message-ID: <7F4AC78738EAD2119D86009027626C6D889037@packetbdc.riverdelta.com> From: Jon Bennett To: "'Casati, Alessio (Alessio)'" , Jon Bennett Cc: diffserv@ietf.org Subject: RE: [Diffserv] RE: Yesterday's EF discussion Date: Mon, 18 Dec 2000 14:24:07 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: text/plain; charset="iso-8859-1" Sender: diffserv-admin@ietf.org Errors-To: diffserv-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Diffserv Discussion List X-BeenThere: diffserv@ietf.org Alessio, > > Its funny, I am also familiar with those things as well, and having > > actually heard Van explain the operation of the BANDWIDTH brokers in > > Internet2 I do see the dependence on the rate bound. But you know > > something, it doesn't really matter what Van thinks since the RFC is a product of > > the WG and not his personal property. If you wish I can start posting > > references to allthe Internet2 project documentation that specifies the BANDWIDTH broker > > operation and the SLA guarantees in terms of RATES and not > > in terms of jitter, would you like me to do that? > > > No, thanks. We can try and discuss anyway. That's odd, why is it that you would not want me to do so? It always seems to be better to have a discussion based on facts, rather than assertions. If you want to continue to support your argument through unsupported assertions and opinions, I will just start posting documents till it becomes clear that I am presenting factually true statements and you are making unsupported, and unsupportable claims. > The SLA is a service level specification > stipulated between two diffserv domains. > Rate is a service level parameter, valid at > the edge. Nothing can be said about the rate > configured (if no PQ is used) within the domain, and that the rate > guarantee per se is what is needed within the domain. Now if rate is a service level parameter valid at the edge, then in a one node network the edge is the network, hence rate is a parameter valid at a single hop. As for nothing being able to be said about rate unless PQ is used, this is a most unusual statement, particularly if you want to support more than one instance of the EF service the only way to insure the provisioning of a configured rate would be to use something other than PQ. > The way this is possible is via PHB that allows > aggregation of a number of customer networks > in a way that they do not affect one another. > This is possible via a PHB > that provides strict guarantees in terms > of delay variation across a hop. > This is the only way that allows aggregation > without uncontrolled burst accumulation, > that would result in the service not being delivered > end to end to the customer network > asking for a "virtual wire". Your argument is both circular and untrue. It has been shown that with FIFO/PQ service that you do not have control over the burst accumulation on a local level , and that only through network level controls can you achieve such control. So a PHB can not make the guarantees that you want, this is a proven fact. Repeated assertions by you to the contrary can not change this. I know very well how to build a device which will aggregate traffic together in such a way that there is no burst accumulation, but to do that requires NON-FIFO/NON-PQ service, and a huge S, which gets us back to why you can not specify what you think you want to specify. > Are we on the same page now? I am afraid that we are not even reading from the same book. > This is what Van meant, > what EFRESOLVE is, and what I suggest the WG should > ask the spec to specify. The fact that Van in the > original version stated that the output rate > (delivered with some tight constrains) on an interface > cannot be lower than the input is a truism, but not > what the PHB is in essence. No, the low jitter is an end-to-end SERVICE, the provisioning of an output rate IS the essence of the PHB as the RFC says. Creating such a service has two parts: 1) Configuring nodes so that the aggregate has a well-defined minimum departure rate. ("Well-defined" means independent of the dynamic state of the node. In particular, independent of the intensity of other traffic at the node.) 2) Conditioning the aggregate (via policing and shaping) so that its arrival rate at any node is always less than that node's configured minimum departure rate. The EF PHB provides the first part of the service. The network boundary traffic conditioners described in [RFC2475] provide the second part. I fail to see where in part 1) it mentions any concept of what the EF PHB is other that a RATE guarantee. The lack of jitter accumulation is a result of the second part, which as I said before falls to the network level controls and is therefore the property one might find in a PDB but not in a PHB, which is why we decided not to put it in the PHB, because it does not belong there. jon _______________________________________________ diffserv mailing list diffserv@ietf.org http://www1.ietf.org/mailman/listinfo/diffserv Archive: http://www2.ietf.org/mail-archive/working-groups/diffserv/current/maillist.html From diffserv-admin@ietf.org Mon Dec 18 15:03:08 2000 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with SMTP id PAA14301 for ; Mon, 18 Dec 2000 15:03:03 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id OAA05431; Mon, 18 Dec 2000 14:20:48 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id OAA05400 for ; Mon, 18 Dec 2000 14:20:44 -0500 (EST) Received: from mail.internet2.edu (mail.internet2.edu [209.211.239.218]) by ietf.org (8.9.1a/8.9.1a) with SMTP id OAA13509 for ; Mon, 18 Dec 2000 14:20:44 -0500 (EST) Received: from cain.internet2.edu (localhost [127.0.0.1]) by mail.internet2.edu (8.9.3/8.9.1) with ESMTP id OAA14805; Mon, 18 Dec 2000 14:20:35 -0500 (EST) Received: by cain.internet2.edu (Postfix, from userid 1000) id 1CC027D5; Mon, 18 Dec 2000 14:20:33 -0500 (EST) To: Jon Bennett Cc: "'John Schnizlein'" , Fulu Li , diffserv@ietf.org Subject: Re: [Diffserv] RE: Yesterday's EF discussion References: <7F4AC78738EAD2119D86009027626C6D889036@packetbdc.riverdelta.com> From: stanislav shalunov Date: 18 Dec 2000 14:20:32 -0500 In-Reply-To: <7F4AC78738EAD2119D86009027626C6D889036@packetbdc.riverdelta.com> Message-ID: <87n1dtk03j.fsf@cain.internet2.edu> Lines: 25 X-Mailer: Gnus v5.7/Emacs 20.4 Sender: diffserv-admin@ietf.org Errors-To: diffserv-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Diffserv Discussion List X-BeenThere: diffserv@ietf.org Jon Bennett writes: > Its funny, I am also familiar with those things as well, and having > actually heard Van explain the operation of the BANDWIDTH brokers in > Internet2 I do see the dependence on the rate bound. But you know > something, it doesn't really matter what Van thinks since the RFC is > a product of the WG and not his personal property. If you wish I can > start posting references to all the Internet2 project documentation > that specifies the BANDWIDTH broker operation and the SLA guarantees > in terms of RATES and not in terms of jitter, would you like me to > do that? Jon, Internet2 implementation experience probably should not influence the standartization process. But in case there's any interest in it, it's our understanding of EF that you provide all of bandwidth, minimal jitter (but not necessarily bounded in a formal way by a constant user can easily learn), and virtually no loss. -- Stanislav Shalunov Internet Engineer, Internet2 Clothes make the man. Naked people have little or no influence on society. -- Mark Twain _______________________________________________ diffserv mailing list diffserv@ietf.org http://www1.ietf.org/mailman/listinfo/diffserv Archive: http://www2.ietf.org/mail-archive/working-groups/diffserv/current/maillist.html From diffserv-admin@ietf.org Mon Dec 18 15: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 SMTP id PAA14503 for ; Mon, 18 Dec 2000 15:17:57 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id OAA05806; Mon, 18 Dec 2000 14:34:30 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id OAA05777 for ; Mon, 18 Dec 2000 14:34:26 -0500 (EST) Received: from packetbdc.packettech.com (packetbdc.riverdelta.com [198.112.190.11]) by ietf.org (8.9.1a/8.9.1a) with SMTP id OAA13896 for ; Mon, 18 Dec 2000 14:34:27 -0500 (EST) Received: by packetbdc.riverdelta.com with Internet Mail Service (5.5.2650.21) id ; Mon, 18 Dec 2000 14:35:57 -0500 Message-ID: <7F4AC78738EAD2119D86009027626C6D889038@packetbdc.riverdelta.com> From: Jon Bennett To: "'stanislav shalunov'" , Jon Bennett Cc: "'John Schnizlein'" , Fulu Li , diffserv@ietf.org Subject: RE: [Diffserv] RE: Yesterday's EF discussion Date: Mon, 18 Dec 2000 14:35:56 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: text/plain; charset="iso-8859-1" Sender: diffserv-admin@ietf.org Errors-To: diffserv-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Diffserv Discussion List X-BeenThere: diffserv@ietf.org Stanislav, > Internet2 implementation experience probably should not influence the > standartization process. Sorry Internet2 was the most convenient example at hand, so I used it rather that making claims based on proprietarily network deployments whose details can not be discussed in public. Is there some reason why you don't think the Internet2 experience is useful for us to examine? > But in case there's any interest in it, it's > our understanding of EF that you provide all of bandwidth, minimal > jitter (but not necessarily bounded in a formal way by a constant user > can easily learn), and virtually no loss. Yes I would agree entirely that is why we put measurements of both bandwidth and jitter into our proposal, and not just jitter. jon _______________________________________________ diffserv mailing list diffserv@ietf.org http://www1.ietf.org/mailman/listinfo/diffserv Archive: http://www2.ietf.org/mail-archive/working-groups/diffserv/current/maillist.html From diffserv-admin@ietf.org Mon Dec 18 15:31:54 2000 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with SMTP id PAA14751 for ; Mon, 18 Dec 2000 15:31:54 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id OAA06174; Mon, 18 Dec 2000 14:57:27 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id OAA06142 for ; Mon, 18 Dec 2000 14:57:23 -0500 (EST) Received: from mail.internet2.edu (mail.internet2.edu [209.211.239.218]) by ietf.org (8.9.1a/8.9.1a) with SMTP id OAA14217 for ; Mon, 18 Dec 2000 14:57:22 -0500 (EST) Received: from cain.internet2.edu (localhost [127.0.0.1]) by mail.internet2.edu (8.9.3/8.9.1) with ESMTP id OAA15954; Mon, 18 Dec 2000 14:57:20 -0500 (EST) Received: by cain.internet2.edu (Postfix, from userid 1000) id B03137D5; Mon, 18 Dec 2000 14:57:18 -0500 (EST) To: Jon Bennett Cc: "'John Schnizlein'" , Fulu Li , diffserv@ietf.org Subject: Re: [Diffserv] RE: Yesterday's EF discussion References: <7F4AC78738EAD2119D86009027626C6D889038@packetbdc.riverdelta.com> From: stanislav shalunov Date: 18 Dec 2000 14:57:18 -0500 In-Reply-To: <7F4AC78738EAD2119D86009027626C6D889038@packetbdc.riverdelta.com> Message-ID: <87hf41jye9.fsf@cain.internet2.edu> Lines: 33 X-Mailer: Gnus v5.7/Emacs 20.4 Sender: diffserv-admin@ietf.org Errors-To: diffserv-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Diffserv Discussion List X-BeenThere: diffserv@ietf.org Jon Bennett writes: > Sorry Internet2 was the most convenient example at hand, so I used > it rather that making claims based on proprietarily network > deployments whose details can not be discussed in public. Is there > some reason why you don't think the Internet2 experience is useful > for us to examine? Jon, All Internet2 work is completely open, including philosophy and actual deployment details. However, the implementation of Abilene Premium Service (based on vendor-specific implementations [note plural] of PHB that we understand is close to EF) is still incomplete. More or less current status and plans are outlined in my talk given during Internet2 Atlanta Member Meeting this fall: http://www.internet2.edu/abilene/qos/apsAtlanta.pdf (QBone architecture referenced within can be found at http://sss.advanced.org/arch/) The incomplete implementation that we have can surely be examined. One should keep in mind its incompleteness when referring to it within the framework of standartization. -- Stanislav Shalunov Internet Engineer, Internet2 Clothes make the man. Naked people have little or no influence on society. -- Mark Twain _______________________________________________ diffserv mailing list diffserv@ietf.org http://www1.ietf.org/mailman/listinfo/diffserv Archive: http://www2.ietf.org/mail-archive/working-groups/diffserv/current/maillist.html From diffserv-admin@ietf.org Mon Dec 18 15:41: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 SMTP id PAA15010 for ; Mon, 18 Dec 2000 15:41:29 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id PAA06515; Mon, 18 Dec 2000 15:08:20 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id PAA06474 for ; Mon, 18 Dec 2000 15:08:15 -0500 (EST) Received: from mailhub1.almaden.ibm.com (mailhub1.almaden.ibm.com [198.4.83.44]) by ietf.org (8.9.1a/8.9.1a) with SMTP id PAA14374; Mon, 18 Dec 2000 15:08:10 -0500 (EST) Received: from maui.almaden.ibm.com (maui.almaden.ibm.com [9.1.24.92]) by mailhub1.almaden.ibm.com (8.8.8/8.8.8) with ESMTP id MAA61642; Mon, 18 Dec 2000 12:03:14 -0800 Received: from hursley.ibm.com (gsine05.us.sine.ibm.com [9.14.6.45]) by maui.almaden.ibm.com (AIX4.3/8.9.3/8.7) with ESMTP id MAA20990; Mon, 18 Dec 2000 12:07:34 -0800 Message-ID: <3A3E6837.4E089066@hursley.ibm.com> Date: Mon, 18 Dec 2000 13:40:39 -0600 From: Brian E Carpenter Organization: IBM X-Mailer: Mozilla 4.61 [en] (Win98; I) X-Accept-Language: en,fr MIME-Version: 1.0 To: Andy Bierman CC: Kwok-Ho Chan , Andrew Smith , "Wijnen, Bert (Bert)" , Harrie Hazewinkel , rmonmib@ietf.org, diffserv@ietf.org Subject: Re: [Diffserv] The DsCodePoint definition References: <2413FED0DFE6D111B3F90008C7FA61FB0A6E0DFC@nl0006exch002u.nl.lucent.com> <3A3711A1.7060202@allegronetworks.com> <200012151755.JAA00454@proxy2.cisco.com> <3A3A8C64.17C9E9CD@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 Andy, My understanding was that publishing the TC in a separate RFC remains possible. We *will* publish a stand-alone diffserv MIB including this TC anyway, for the same reason that you mention - to avoid any dependencies. Brian Andy Bierman wrote: > > Kwok-Ho Chan wrote: > > > > Andy: > > I have created a new module in the Diff Serv MIB to hold the 2 new DSCP TCs. > > You don't need to reference the whole Diff Serv MIB, just the DSCP TC Module. > > I hope this help for you to reference the DSCP TC definition from the > > DiffServ WG. > > Right now the 2 TCs in DSMIB-07 are Dscp (0..63) and DscpOrAny (-1 | 0..63). > > This will be published this coming weekend in Diff Serv MIB -07. > > Other than requiring an import in the RMON MIB to get the DSCP TC, > > is there any technical issue in using a common DSCP TC definition? > > Would like to do what I can to resolve this. > > I did not agree to this change. > I don't think it's a good idea to couple the progress of the DSMON MIB RFC > to the DIFFSERV MIB RFC. The DSMON MIB module will (potentially) be > held up at each level of publication, waiting for any or all of > the MIB modules in the DIFFSERV MIB RFC. > > If you publish a DIFFSERV-TC MIB module in its own RFC, > I'll change the DSMON MIB. > > > Thanks! > > -- Kwok -- > > Andy > > > > > At 10:15 AM 12/13/00 -0800, Andy Bierman wrote: > > >Andrew Smith wrote: > > >> > > >> 2 TCs defined in the same MIB module, to be precise. > > >> > > > > > >I disagree. > > > > >There is no need for the DSMON MIB to have a normative > > >reference to the DIFFSERV MIB. > > > > > >The primary focus of RMON is collect statistics based on > > >observable characteristics of network traffic. RFC 2474 > > >specifies the observable attributes of a packet containing > > >a DSCP field. The REFERENCE clause in the DsCodePoint TC > > >properly identifies RFC 2474, and no additional coupling to > > >any other documents is required. > > > > > >BTW, SMIv2 does not allow a TC to be defined as a variant of > > >another TC, so Harrie's suggestion won't work. > > > > > >> Andrew > > > > > >Andy > > > > > >> > > >> Wijnen, Bert (Bert) wrote: > > >> > > >> > Comments inline > > >> > > > >> > > > >> >> ---------- > > >> >> From: Andy Bierman[SMTP:abierman@cisco.com] > > >> >> Sent: Tuesday, December 12, 2000 9:07 PM > > >> >> To: Harrie Hazewinkel > > >> >> Cc: rmonmib@ietf.org; diffserv@ietf.org > > >> >> Subject: Re: [Diffserv] The DsCodePoint definition > > >> >> > > >> >> Harrie Hazewinkel wrote: > > >> >> > > >> >>> HI, > > >> >>> > > >> >>> I was wondering why there is a difference between > > >> >>> 2 definitions of the DiffServ CodePoint in different > > >> >>> MIB modules. The two different MIMB modules are > > >> >>> the DIFFSERV-MIB (of diffserv) and the DSMON-MIB (of RMON). > > >> >>> > > >> >>> I beleive these 2 TCs should be the same and taken from the > > >> >>> DIFFSERV-MIB, because that is from the diffserv WG. > > >> >>> > > >> >>> ----------- From the DIFFSERV-MIB (draft 05) ----------------- > > >> >>> Dscp ::= TEXTUAL-CONVENTION > > >> >>> DISPLAY-HINT "d" > > >> >>> STATUS current > > >> >>> DESCRIPTION > > >> >>> "The IP header Diffserv Code-Point that may be used > > >> >>> for discriminating or marking a traffic stream. The > > >> >>> value -1 ( 4294967295 for Integer32 ) is used to > > >> >>> indicate a wildcard i.e. any value." > > >> >>> SYNTAX Integer32 (4294967295 | 0..63) > > >> >> > > >> >> just noticed how broken this TC is... > > >> >> 1) an Integer32 object cannot contain the value 4294967295 > > >> > > > >> > I have made that comments to the Diffserv list already, and they > > >> > will need to fix it with using -1 > > >> > > > >> >> 2) missing REFERENCE clause > > >> >> (where exactly in 2474 is the 'wildcard' DSCP value discussed?) > > >> > > > >> > Yep, this one was raised by someone else (was it Andrew?) > > >> > > > >> > But the important thing, we need a fixed TC that is usable by both > > >> > MIBs I think. Or maybe 2 TCs as I also suggested on the diffserv > > >> > list. > > >> > > > >> > Bert > > >> > > > >> > > > >> >> Andy > > >> >> > > >> >> > > >> >>> -------------------------------------------------------------- > > >> >>> > > >> >>> ------------ From the DSMON-MIB (draft 03) ------------------- > > >> >>> DsmonDSCodePoint ::= TEXTUAL-CONVENTION > > >> >>> STATUS current > > >> >>> DESCRIPTION > > >> >>> "This TC describes an object which identifies the > > >> >>> Differentiated Services Codepoint (DSCP) value found within > > >> >>> the DS field in a network layer packet header (e.g., IPv4 > > >> >>> and IPv6)." > > >> >>> REFERENCE > > > > >> >>> "Definition of the Differentiated Services Field (DS > > Field) > > >> >>> in the IPv4 and IPv6 Headers [RFC2474]." > > >> >>> SYNTAX Integer32 (0..63) > > >> >>> -------------------------------------------------------------- > > >> >>> > > >> >>> OK, I will admit the definition of the DiffServ-MIB is currently > > >> >>> broken, but that will be fixed (this week at the IETF, I hope). > > >> >>> > > >> >>> Harrie > > > > > >_______________________________________________ > > >diffserv mailing list > > >diffserv@ietf.org > > >http://www1.ietf.org/mailman/listinfo/diffserv > > >Archive: > > http://www2.ietf.org/mail-archive/working-groups/diffserv/current/maillist.h > > tml > > > > > _______________________________________________ > diffserv mailing list > diffserv@ietf.org > http://www1.ietf.org/mailman/listinfo/diffserv > Archive: http://www2.ietf.org/mail-archive/working-groups/diffserv/current/maillist.html _______________________________________________ diffserv mailing list diffserv@ietf.org http://www1.ietf.org/mailman/listinfo/diffserv Archive: http://www2.ietf.org/mail-archive/working-groups/diffserv/current/maillist.html From diffserv-admin@ietf.org Mon Dec 18 15:41: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 SMTP id PAA15021 for ; Mon, 18 Dec 2000 15:41:35 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id PAA06607; Mon, 18 Dec 2000 15:12:16 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id PAA06576 for ; Mon, 18 Dec 2000 15:12:11 -0500 (EST) Received: from mailhub1.almaden.ibm.com (mailhub1.almaden.ibm.com [198.4.83.44]) by ietf.org (8.9.1a/8.9.1a) with SMTP id PAA14428 for ; Mon, 18 Dec 2000 15:12:11 -0500 (EST) Received: from maui.almaden.ibm.com (maui.almaden.ibm.com [9.1.24.92]) by mailhub1.almaden.ibm.com (8.8.8/8.8.8) with ESMTP id MAA18254; Mon, 18 Dec 2000 12:07:14 -0800 Received: from hursley.ibm.com (gsine05.us.sine.ibm.com [9.14.6.45]) by maui.almaden.ibm.com (AIX4.3/8.9.3/8.7) with ESMTP id MAA22272; Mon, 18 Dec 2000 12:11:40 -0800 Message-ID: <3A3E6929.13C6067A@hursley.ibm.com> Date: Mon, 18 Dec 2000 13:44:41 -0600 From: Brian E Carpenter Organization: IBM X-Mailer: Mozilla 4.61 [en] (Win98; I) X-Accept-Language: en,fr MIME-Version: 1.0 To: "Casati, Alessio (Alessio)" CC: diffserv@ietf.org, "'Bruce Davie'" Subject: Re: [Diffserv] Possible compromise between EFRESOLVE and draft-charny References: <976F7C55E3B2D111A0720008C728549C0487762F@en0060exch001u.uk.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 Alessio, "Casati, Alessio (Alessio)" wrote: > > Bruce, > > I would like to discuss the merits of your proposal ("compromise"), > to form the WG consensus on the list: in fact we may have not > completely understood the proposal so far, due to tight schedule Naturally, when the proposal has been written up in the form of a PHB definition, we will be doing just that; that is how we reach WG consensus. Brian _______________________________________________ diffserv mailing list diffserv@ietf.org http://www1.ietf.org/mailman/listinfo/diffserv Archive: http://www2.ietf.org/mail-archive/working-groups/diffserv/current/maillist.html From diffserv-admin@ietf.org Mon Dec 18 15:49: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 SMTP id PAA15193 for ; Mon, 18 Dec 2000 15:49:10 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id PAA06751; Mon, 18 Dec 2000 15:18:59 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id PAA06720 for ; Mon, 18 Dec 2000 15:18:55 -0500 (EST) Received: from mailhub1.almaden.ibm.com (mailhub1.almaden.ibm.com [198.4.83.44]) by ietf.org (8.9.1a/8.9.1a) with SMTP id PAA14514 for ; Mon, 18 Dec 2000 15:18:55 -0500 (EST) Received: from maui.almaden.ibm.com (maui.almaden.ibm.com [9.1.24.92]) by mailhub1.almaden.ibm.com (8.8.8/8.8.8) with ESMTP id MAA28960; Mon, 18 Dec 2000 12:13:56 -0800 Received: from hursley.ibm.com (gsine05.us.sine.ibm.com [9.14.6.45]) by maui.almaden.ibm.com (AIX4.3/8.9.3/8.7) with ESMTP id MAA35698; Mon, 18 Dec 2000 12:18:20 -0800 Message-ID: <3A3E6A9E.6EC3477F@hursley.ibm.com> Date: Mon, 18 Dec 2000 13:50:55 -0600 From: Brian E Carpenter Organization: IBM X-Mailer: Mozilla 4.61 [en] (Win98; I) X-Accept-Language: en,fr MIME-Version: 1.0 To: "Casati, Alessio (Alessio)" CC: diffserv@ietf.org, "'Jon Crowcroft'" Subject: Re: [Diffserv] The compromise is actually 2 PHBs as per Anna 's message. References: <976F7C55E3B2D111A0720008C728549C04877632@en0060exch001u.uk.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 Alessio, It's a matter of personal taste, clearly, whether one phrases it Jon's way or your way. However, this is what the WG chose to do, so let's deal with it. Brian "Casati, Alessio (Alessio)" wrote: > > > whatever van wanted, whatever we thugh the RFC said > > whatever the history, i accept that > > we now have a useful PHB specification - > > however, it has two modes of application - color aware and color > > blind > > > > > This implies two PHBs in diffserv terms. > > alessio > > _______________________________________________ > diffserv mailing list > diffserv@ietf.org > http://www1.ietf.org/mailman/listinfo/diffserv > Archive: http://www2.ietf.org/mail-archive/working-groups/diffserv/current/maillist.html _______________________________________________ diffserv mailing list diffserv@ietf.org http://www1.ietf.org/mailman/listinfo/diffserv Archive: http://www2.ietf.org/mail-archive/working-groups/diffserv/current/maillist.html From diffserv-admin@ietf.org Mon Dec 18 16:11: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 SMTP id QAA15632 for ; Mon, 18 Dec 2000 16:11:06 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id PAA07447; Mon, 18 Dec 2000 15:42:26 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id PAA07426 for ; Mon, 18 Dec 2000 15:42:23 -0500 (EST) Received: from mailhub1.almaden.ibm.com (mailhub1.almaden.ibm.com [198.4.83.44]) by ietf.org (8.9.1a/8.9.1a) with SMTP id PAA15049 for ; Mon, 18 Dec 2000 15:42:22 -0500 (EST) Received: from maui.almaden.ibm.com (maui.almaden.ibm.com [9.1.24.92]) by mailhub1.almaden.ibm.com (8.8.8/8.8.8) with ESMTP id MAA29840 for ; Mon, 18 Dec 2000 12:37:25 -0800 Received: from hursley.ibm.com (gsine05.us.sine.ibm.com [9.14.6.45]) by maui.almaden.ibm.com (AIX4.3/8.9.3/8.7) with ESMTP id MAA22282 for ; Mon, 18 Dec 2000 12:41:51 -0800 Message-ID: <3A3E6FD0.51E74838@hursley.ibm.com> Date: Mon, 18 Dec 2000 14:13:04 -0600 From: Brian E Carpenter Organization: IBM X-Mailer: Mozilla 4.61 [en] (Win98; I) X-Accept-Language: en,fr MIME-Version: 1.0 To: diffserv@ietf.org References: <7F4AC78738EAD2119D86009027626C6D889036@packetbdc.riverdelta.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Subject: [Diffserv] Decorum Sender: diffserv-admin@ietf.org Errors-To: diffserv-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Diffserv Discussion List X-BeenThere: diffserv@ietf.org Content-Transfer-Encoding: 7bit Somebody wrote: >... But you know something, it doesn't > really matter what Van thinks since the RFC is a product of the WG and not > his personal property. I observe that it matters what *each* contributor to the debate thinks; the WG consensus is supposed to be the result of logical analysis of everybody's contribution. There have been a number of rather personal remarks (both spoken and typed) in the discussion - I only quote the one above because it came across my screen this minute - and I would ask everybody to refrain from such remarks. Regards Brian Carpenter diffserv co-chair _______________________________________________ diffserv mailing list diffserv@ietf.org http://www1.ietf.org/mailman/listinfo/diffserv Archive: http://www2.ietf.org/mail-archive/working-groups/diffserv/current/maillist.html From diffserv-admin@ietf.org Mon Dec 18 16:17:35 2000 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with SMTP id QAA15748 for ; Mon, 18 Dec 2000 16:17:34 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id PAA07554; Mon, 18 Dec 2000 15:48:31 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id PAA07527 for ; Mon, 18 Dec 2000 15:48:27 -0500 (EST) Received: from mailhub1.almaden.ibm.com (mailhub1.almaden.ibm.com [198.4.83.44]) by ietf.org (8.9.1a/8.9.1a) with SMTP id PAA15190 for ; Mon, 18 Dec 2000 15:48:26 -0500 (EST) Received: from maui.almaden.ibm.com (maui.almaden.ibm.com [9.1.24.92]) by mailhub1.almaden.ibm.com (8.8.8/8.8.8) with ESMTP id MAA49998; Mon, 18 Dec 2000 12:43:30 -0800 Received: from hursley.ibm.com (gsine05.us.sine.ibm.com [9.14.6.45]) by maui.almaden.ibm.com (AIX4.3/8.9.3/8.7) with ESMTP id MAA32302; Mon, 18 Dec 2000 12:47:55 -0800 Message-ID: <3A3E7108.8E38BB03@hursley.ibm.com> Date: Mon, 18 Dec 2000 14:18:16 -0600 From: Brian E Carpenter Organization: IBM X-Mailer: Mozilla 4.61 [en] (Win98; I) X-Accept-Language: en,fr MIME-Version: 1.0 To: stanislav shalunov CC: diffserv@ietf.org References: <7F4AC78738EAD2119D86009027626C6D889036@packetbdc.riverdelta.com> <87n1dtk03j.fsf@cain.internet2.edu> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Subject: [Diffserv] EF implementation experience Sender: diffserv-admin@ietf.org Errors-To: diffserv-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Diffserv Discussion List X-BeenThere: diffserv@ietf.org Content-Transfer-Encoding: 7bit stanislav shalunov wrote: ... > Internet2 implementation experience probably should not influence the > standartization process. But implementation experience is the most precious form of input we can have. Why do you think the i2 experience is not useful? Should we rather look at the EMERGE experience or the TF-TANT experience? What other testbeds should we look at? Brian _______________________________________________ diffserv mailing list diffserv@ietf.org http://www1.ietf.org/mailman/listinfo/diffserv Archive: http://www2.ietf.org/mail-archive/working-groups/diffserv/current/maillist.html From diffserv-admin@ietf.org Mon Dec 18 16:22:58 2000 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with SMTP id QAA15821 for ; Mon, 18 Dec 2000 16:22:53 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id PAA07663; Mon, 18 Dec 2000 15:54:05 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id PAA07634 for ; Mon, 18 Dec 2000 15:54:01 -0500 (EST) Received: from mailhub1.almaden.ibm.com (mailhub1.almaden.ibm.com [198.4.83.44]) by ietf.org (8.9.1a/8.9.1a) with SMTP id PAA15293 for ; Mon, 18 Dec 2000 15:54:00 -0500 (EST) Received: from maui.almaden.ibm.com (maui.almaden.ibm.com [9.1.24.92]) by mailhub1.almaden.ibm.com (8.8.8/8.8.8) with ESMTP id MAA52986; Mon, 18 Dec 2000 12:49:03 -0800 Received: from hursley.ibm.com (gsine05.us.sine.ibm.com [9.14.6.45]) by maui.almaden.ibm.com (AIX4.3/8.9.3/8.7) with ESMTP id MAA22288; Mon, 18 Dec 2000 12:53:28 -0800 Message-ID: <3A3E7219.FE2568D9@hursley.ibm.com> Date: Mon, 18 Dec 2000 14:22:49 -0600 From: Brian E Carpenter Organization: IBM X-Mailer: Mozilla 4.61 [en] (Win98; I) X-Accept-Language: en,fr MIME-Version: 1.0 To: Bruce Davie CC: "Diffserv@Ietf. Org" Subject: Re: [Diffserv] Yesterday's EF discussion References: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: diffserv-admin@ietf.org Errors-To: diffserv-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Diffserv Discussion List X-BeenThere: diffserv@ietf.org Content-Transfer-Encoding: 7bit Bruce, the reason I chose to put the naming question to the list is that the naming issue was very far from explicit in the discussion on Tuesday, and there wasn't time to make it explicit. My intention is to close off the naming discussion tomorrow December 19, and state what I see as the rough consensus. Brian Bruce Davie wrote: > > One observation that I might make about the current debate on re-naming EF > is that it resembles the debate in front of the WG on Tuesday. Proponents of > EFRESOLVE are basically saying "draft-charny is a fine PHB definition, it > just isn't EF" which is exactly what they said on Tuesday. I believe the WG > voted to reject that position when it voted in favor of adopting > draft-charny as the basis for a replacement for RFC 2598. So we seem to be > simply rehashing an argument that was settled on Tuesday, with the same > proponents on both sides. As has already been said, this is simply ignoring > the WG consensus. > > Bruce > > _______________________________________________ > diffserv mailing list > diffserv@ietf.org > http://www1.ietf.org/mailman/listinfo/diffserv > Archive: http://www2.ietf.org/mail-archive/working-groups/diffserv/current/maillist.html _______________________________________________ diffserv mailing list diffserv@ietf.org http://www1.ietf.org/mailman/listinfo/diffserv Archive: http://www2.ietf.org/mail-archive/working-groups/diffserv/current/maillist.html From diffserv-admin@ietf.org Mon Dec 18 17:05: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 SMTP id RAA16307 for ; Mon, 18 Dec 2000 17:05:36 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id QAA08609; Mon, 18 Dec 2000 16:31:39 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id QAA08579 for ; Mon, 18 Dec 2000 16:31:34 -0500 (EST) 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 SMTP id QAA15950 for ; Mon, 18 Dec 2000 16:31:32 -0500 (EST) 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 PAA05675 for ; Mon, 18 Dec 2000 15:31:30 -0600 (CST) Received: from stl-hub-01.boeing.com (localhost [127.0.0.1]) by stl-av-01.boeing.com (8.9.3/8.9.2) with ESMTP id PAA14615 for ; Mon, 18 Dec 2000 15:31:27 -0600 (CST) Received: from xch-phlbh-01.he.boeing.com by stl-hub-01.boeing.com with ESMTP; Mon, 18 Dec 2000 15:31:23 -0600 Received: by xch-phlbh-01.he.boeing.com with Internet Mail Service (5.5.2650.21) id ; Mon, 18 Dec 2000 16:31:23 -0500 Message-Id: <4102273CEB77D211869200805FE6F593018C5C11@xch-phl-01.he.boeing.com> From: "Manfredi, Albert E" To: "'Brian E Carpenter'" Cc: "Diffserv@Ietf. Org" Subject: RE: [Diffserv] Yesterday's EF discussion Date: Mon, 18 Dec 2000 16:31:18 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: text/plain; charset="iso-8859-1" Sender: diffserv-admin@ietf.org Errors-To: diffserv-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Diffserv Discussion List X-BeenThere: diffserv@ietf.org Brian E Carpenter: > Bruce, the reason I chose to put the naming question to the list is > that the naming issue was very far from explicit in the discussion > on Tuesday, and there wasn't time to make it explicit. > > My intention is to close off the naming discussion tomorrow > December 19, > and state what I see as the rough consensus. Sorry I didn't commit to memory all of the suggestions, but did anyone recomment something like, say, Guaranteed Frame Rate (GFR)? :)) Dunno, I just pulled that one out of the air. Bert _______________________________________________ diffserv mailing list diffserv@ietf.org http://www1.ietf.org/mailman/listinfo/diffserv Archive: http://www2.ietf.org/mail-archive/working-groups/diffserv/current/maillist.html From diffserv-admin@ietf.org Mon Dec 18 17:39: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 SMTP id RAA16826 for ; Mon, 18 Dec 2000 17:39:21 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id RAA09463; Mon, 18 Dec 2000 17:12:50 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id RAA09432 for ; Mon, 18 Dec 2000 17:12:46 -0500 (EST) Received: from diablo.cisco.com (diablo.cisco.com [171.68.224.210]) by ietf.org (8.9.1a/8.9.1a) with SMTP id RAA16452 for ; Mon, 18 Dec 2000 17:12:44 -0500 (EST) Received: from jschnizl1-pc (ssh-sj1.cisco.com [171.68.225.134]) by diablo.cisco.com (8.8.6 (PHNE_14041)/CISCO.SERVER.1.2) with SMTP id OAA01922 for ; Mon, 18 Dec 2000 14:12:11 -0800 (PST) Message-Id: <4.1.20001218170503.00c9c4b0@diablo.cisco.com> X-Sender: jschnizl@localhost (Unverified) X-Mailer: QUALCOMM Windows Eudora Pro Version 4.1 Date: Mon, 18 Dec 2000 17:11:59 -0500 To: Diff Serv From: John Schnizlein Subject: Re: What's in a name? Re: [Diffserv] Yesterday's EF discussion In-Reply-To: <3A386DBA.42F44DAA@research.bell-labs.com> References: <3A37BF28.219E231C@hursley.ibm.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: diffserv-admin@ietf.org Errors-To: diffserv-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Diffserv Discussion List X-BeenThere: diffserv@ietf.org When the RFC that replaces RFC 2598 is ready for progress to standard based on multiple interoperable implementations should the name be one of mostly historical interest (Expedited Forwarding) or something that reflects the essential nature of the per-hop behavior it defines? Is there anything besides expediting packet forwarding involved in the proposed definition? In a word or two, what is it? John >Brian E Carpenter wrote: > [..] >> What should the name of the PHB be? _______________________________________________ diffserv mailing list diffserv@ietf.org http://www1.ietf.org/mailman/listinfo/diffserv Archive: http://www2.ietf.org/mail-archive/working-groups/diffserv/current/maillist.html From diffserv-admin@ietf.org Mon Dec 18 18:17:44 2000 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with SMTP id SAA17634 for ; Mon, 18 Dec 2000 18:17:39 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id RAA10132; Mon, 18 Dec 2000 17:38:13 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id RAA10097 for ; Mon, 18 Dec 2000 17:38:06 -0500 (EST) Received: from hoemlsrv.firewall.lucent.com (hoemail1.lucent.com [192.11.226.161]) by ietf.org (8.9.1a/8.9.1a) with SMTP id RAA16815 for ; Mon, 18 Dec 2000 17:38:06 -0500 (EST) Received: from hoemlsrv.firewall.lucent.com (localhost [127.0.0.1]) by hoemlsrv.firewall.lucent.com (Pro-8.9.3/8.9.3) with ESMTP id RAA04858 for ; Mon, 18 Dec 2000 17:38:07 -0500 (EST) Received: from uk0006exch001h.wins.lucent.com (h135-86-160-150.lucent.com [135.86.160.150]) by hoemlsrv.firewall.lucent.com (Pro-8.9.3/8.9.3) with ESMTP id RAA04814 for ; Mon, 18 Dec 2000 17:38:06 -0500 (EST) Received: by uk0006exch001h.uk.lucent.com with Internet Mail Service (5.5.2650.21) id ; Mon, 18 Dec 2000 22:38:05 -0000 Message-ID: <976F7C55E3B2D111A0720008C728549C04877648@en0060exch001u.uk.lucent.com> From: "Casati, Alessio (Alessio)" To: "'Brian E Carpenter'" Cc: diffserv@ietf.org, "'Jon Crowcroft'" Subject: RE: [Diffserv] The compromise is actually 2 PHBs as per Anna 's message. Date: Mon, 18 Dec 2000 22:38:04 -0000 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: text/plain Sender: diffserv-admin@ietf.org Errors-To: diffserv-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Diffserv Discussion List X-BeenThere: diffserv@ietf.org Is personal taste becoming part of the DIFFSERV architecture? Are codepoints going to be given away based on personal taste? If not, we should really consider these 2 PHBs. alessio > ---------- > From: Brian E Carpenter[SMTP:brian@hursley.ibm.com] > Sent: 18 December 2000 19:50 > To: Casati, Alessio (Alessio) > Cc: diffserv@ietf.org; 'Jon Crowcroft' > Subject: Re: [Diffserv] The compromise is actually 2 PHBs as per Anna > 's message. > > Alessio, > > It's a matter of personal taste, clearly, whether one phrases it Jon's way > or your way. However, this is what the WG chose to do, so let's deal with > it. > > Brian > > "Casati, Alessio (Alessio)" wrote: > > > > > whatever van wanted, whatever we thugh the RFC said > > > whatever the history, i accept that > > > we now have a useful PHB specification - > > > however, it has two modes of application - color aware and color > > > blind > > > > > > > > This implies two PHBs in diffserv terms. > > > > alessio > > > > _______________________________________________ > > diffserv mailing list > > diffserv@ietf.org > > http://www1.ietf.org/mailman/listinfo/diffserv > > Archive: > http://www2.ietf.org/mail-archive/working-groups/diffserv/current/maillist > .html > _______________________________________________ diffserv mailing list diffserv@ietf.org http://www1.ietf.org/mailman/listinfo/diffserv Archive: http://www2.ietf.org/mail-archive/working-groups/diffserv/current/maillist.html From diffserv-admin@ietf.org Mon Dec 18 18:20:58 2000 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with SMTP id SAA17700 for ; Mon, 18 Dec 2000 18:20:58 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id RAA09643; Mon, 18 Dec 2000 17:24:28 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id RAA09614 for ; Mon, 18 Dec 2000 17:24:24 -0500 (EST) Received: from mailhub1.almaden.ibm.com (mailhub1.almaden.ibm.com [198.4.83.44]) by ietf.org (8.9.1a/8.9.1a) with SMTP id RAA16590 for ; Mon, 18 Dec 2000 17:24:10 -0500 (EST) Received: from maui.almaden.ibm.com (maui.almaden.ibm.com [9.1.24.92]) by mailhub1.almaden.ibm.com (8.8.8/8.8.8) with ESMTP id OAA51170; Mon, 18 Dec 2000 14:19:13 -0800 Received: from hursley.ibm.com (gsine05.us.sine.ibm.com [9.14.6.45]) by maui.almaden.ibm.com (AIX4.3/8.9.3/8.7) with ESMTP id OAA20708; Mon, 18 Dec 2000 14:23:39 -0800 Message-ID: <3A3E8E1F.2DFEF275@hursley.ibm.com> Date: Mon, 18 Dec 2000 16:22:23 -0600 From: Brian E Carpenter Organization: IBM X-Mailer: Mozilla 4.61 [en] (Win98; I) X-Accept-Language: en,fr MIME-Version: 1.0 To: "Manfredi, Albert E" CC: "Diffserv@Ietf. Org" Subject: Re: [Diffserv] Yesterday's EF discussion References: <4102273CEB77D211869200805FE6F593018C5C11@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 The current question is whether the charny-et-al-compromise specification is going to be called EF. [If not, let the games commence :-] Brian "Manfredi, Albert E" wrote: > > Brian E Carpenter: > > > Bruce, the reason I chose to put the naming question to the list is > > that the naming issue was very far from explicit in the discussion > > on Tuesday, and there wasn't time to make it explicit. > > > > My intention is to close off the naming discussion tomorrow > > December 19, > > and state what I see as the rough consensus. > > Sorry I didn't commit to memory all of the suggestions, but did anyone > recomment something like, say, Guaranteed Frame Rate (GFR)? :)) > > Dunno, I just pulled that one out of the air. > > Bert _______________________________________________ diffserv mailing list diffserv@ietf.org http://www1.ietf.org/mailman/listinfo/diffserv Archive: http://www2.ietf.org/mail-archive/working-groups/diffserv/current/maillist.html From diffserv-admin@ietf.org Mon Dec 18 18:27: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 SMTP id SAA17831 for ; Mon, 18 Dec 2000 18:27:37 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id RAA10091; Mon, 18 Dec 2000 17:38:05 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id RAA09992 for ; Mon, 18 Dec 2000 17:37:58 -0500 (EST) Received: from hoemlsrv.firewall.lucent.com (hoemail1.lucent.com [192.11.226.161]) by ietf.org (8.9.1a/8.9.1a) with SMTP id RAA16812 for ; Mon, 18 Dec 2000 17:37:58 -0500 (EST) Received: from hoemlsrv.firewall.lucent.com (localhost [127.0.0.1]) by hoemlsrv.firewall.lucent.com (Pro-8.9.3/8.9.3) with ESMTP id RAA04531 for ; Mon, 18 Dec 2000 17:37:59 -0500 (EST) Received: from uk0006exch001h.wins.lucent.com (h135-86-160-150.lucent.com [135.86.160.150]) by hoemlsrv.firewall.lucent.com (Pro-8.9.3/8.9.3) with ESMTP id RAA04506 for ; Mon, 18 Dec 2000 17:37:58 -0500 (EST) Received: by uk0006exch001h.uk.lucent.com with Internet Mail Service (5.5.2650.21) id ; Mon, 18 Dec 2000 22:37:57 -0000 Message-ID: <976F7C55E3B2D111A0720008C728549C04877647@en0060exch001u.uk.lucent.com> From: "Casati, Alessio (Alessio)" To: "'Brian E Carpenter'" Cc: diffserv@ietf.org, "'Bruce Davie'" Subject: RE: [Diffserv] Possible compromise between EFRESOLVE and draft-ch arny Date: Mon, 18 Dec 2000 22:37:56 -0000 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: text/plain Sender: diffserv-admin@ietf.org Errors-To: diffserv-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Diffserv Discussion List X-BeenThere: diffserv@ietf.org > Alessio, > > "Casati, Alessio (Alessio)" wrote: > > > > Bruce, > > > > I would like to discuss the merits of your proposal ("compromise"), > > to form the WG consensus on the list: in fact we may have not > > completely understood the proposal so far, due to tight schedule > > Naturally, when the proposal has been written up in the form of a PHB > definition, we will be doing just that; that is how we reach WG > consensus. > That's granted. But stated this way seems like the WG opted for a yet to be seen and considered PHB definition. This was not what was written in the options you asked the WG to express their view on... It would have been kinda strange. alessio _______________________________________________ diffserv mailing list diffserv@ietf.org http://www1.ietf.org/mailman/listinfo/diffserv Archive: http://www2.ietf.org/mail-archive/working-groups/diffserv/current/maillist.html From diffserv-admin@ietf.org Mon Dec 18 18:28: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 SMTP id SAA17848 for ; Mon, 18 Dec 2000 18:28:20 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id RAA10479; Mon, 18 Dec 2000 17:58:46 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id RAA10458 for ; Mon, 18 Dec 2000 17:58:43 -0500 (EST) Received: from castillo.torrentnet.com (castillo.torrentnet.com [4.18.161.34]) by ietf.org (8.9.1a/8.9.1a) with SMTP id RAA17216 for ; Mon, 18 Dec 2000 17:58:38 -0500 (EST) Received: from castillo.torrentnet.com (localhost.torrentnet.com [127.0.0.1]) by castillo.torrentnet.com (8.9.3/8.9.3) with ESMTP id RAA21223 for ; Mon, 18 Dec 2000 17:58:39 -0500 (EST) Message-Id: <200012182258.RAA21223@castillo.torrentnet.com> X-Mailer: exmh version 2.0.2 2/24/98 To: diffserv@ietf.org Subject: Re: [Diffserv] The compromise is actually 2 PHBs as per Anna 's message. In-reply-to: Your message of "Mon, 18 Dec 2000 22:38:04 GMT." <976F7C55E3B2D111A0720008C728549C04877648@en0060exch001u.uk.lucent.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Mon, 18 Dec 2000 17:58:39 -0500 From: Steve Blake Sender: diffserv-admin@ietf.org Errors-To: diffserv-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Diffserv Discussion List X-BeenThere: diffserv@ietf.org > Is personal taste becoming part of the DIFFSERV > architecture? Are codepoints going to be given away based on > personal taste? If not, we should really consider these > 2 PHBs. My personal taste would be to not have two RFCs describing the behavior of the same set of schedulers configured in the same set of ways. Regards, =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-= Steven L. Blake Ericsson IP Infrastructure (919)472-9913 _______________________________________________ diffserv mailing list diffserv@ietf.org http://www1.ietf.org/mailman/listinfo/diffserv Archive: http://www2.ietf.org/mail-archive/working-groups/diffserv/current/maillist.html From diffserv-admin@ietf.org Mon Dec 18 18:29: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 SMTP id SAA17872 for ; Mon, 18 Dec 2000 18:29:00 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id SAA10625; Mon, 18 Dec 2000 18:00:23 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id SAA10585 for ; Mon, 18 Dec 2000 18:00:17 -0500 (EST) Received: from mailhost.iprg.nokia.com (mailhost.iprg.nokia.com [205.226.5.12]) by ietf.org (8.9.1a/8.9.1a) with SMTP id SAA17287 for ; Mon, 18 Dec 2000 18:00:17 -0500 (EST) Received: from darkstar.iprg.nokia.com (darkstar.iprg.nokia.com [205.226.5.69]) by mailhost.iprg.nokia.com (8.9.3/8.9.3-GLGS) with ESMTP id OAA05834 for ; Mon, 18 Dec 2000 14:59:49 -0800 (PST) Received: (from root@localhost) by darkstar.iprg.nokia.com (8.11.0/8.11.0-DARKSTAR) id eBIMxkJ26473 for ; Mon, 18 Dec 2000 14:59:46 -0800 X-Virus-Scanned: Mon, 18 Dec 2000 14:59:46 -0800 Nokia Silicon Valley Email Exploit Scanner Received: from dhcp-3-104.iprg.nokia.com (205.226.3.104, claiming to be "iprg.nokia.com") by darkstar.iprg.nokia.com(WTS.12.69) smtpdKQdsFW; Mon, 18 Dec 2000 14:59:35 PST Message-ID: <3A3E96D9.4FCD6CBD@iprg.nokia.com> Date: Mon, 18 Dec 2000 14:59:37 -0800 From: Cedric Organization: NOKIA X-Mailer: Mozilla 4.7 [en] (Win98; U) X-Accept-Language: en MIME-Version: 1.0 To: diffserv@ietf.org Subject: [Fwd: RE: [Diffserv] Yesterday's EF discussion] Content-Type: text/plain; charset=us-ascii Sender: diffserv-admin@ietf.org Errors-To: diffserv-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Diffserv Discussion List X-BeenThere: diffserv@ietf.org I agree that the name EF should be kept. Cedric. -------- Original Message -------- Subject: RE: [Diffserv] Yesterday's EF discussion Date: Fri, 15 Dec 2000 15:15:28 -0800 From: Martha Zimet Organization: Nokia IP Routing To: diffserv@ietf.org I wish to add my vote to keeping the 'EF' name for the following reasons: 1. A new name will imply a new PHB, which is contrary to what I thought the recent WG goals were (e.g. fix and not re-create). 2. Since the 'EF' PHB (RFC 2598) was a proposed standard for a length of time, like other vendors, we have already implemented our version of the 'EF' PHB and its corresponding DSCP based on our understanding of the RFC. This is realized in our current Nokia IPRG products, network management infrastructure, documentation, training classes, etc. 3. Changing the name will be the most confusing to the those who are not well versed in the underlying semantics in the first place. In addition, it will cause added overhead to those of us who are involved in explaining and socializing diffserv in our respective corporate environments. Regards, /martha _______________________________________________ diffserv mailing list diffserv@ietf.org http://www1.ietf.org/mailman/listinfo/diffserv Archive: http://www2.ietf.org/mail-archive/working-groups/diffserv/current/maillist.html _______________________________________________ diffserv mailing list diffserv@ietf.org http://www1.ietf.org/mailman/listinfo/diffserv Archive: http://www2.ietf.org/mail-archive/working-groups/diffserv/current/maillist.html From diffserv-admin@ietf.org Mon Dec 18 18:48:06 2000 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with SMTP id SAA18233 for ; Mon, 18 Dec 2000 18:48:06 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id SAA11097; Mon, 18 Dec 2000 18:18:19 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id SAA11066 for ; Mon, 18 Dec 2000 18:18:15 -0500 (EST) Received: from ihemail1.firewall.lucent.com (ihemail1.lucent.com [192.11.222.161]) by ietf.org (8.9.1a/8.9.1a) with SMTP id SAA17647 for ; Mon, 18 Dec 2000 18:18:15 -0500 (EST) Received: from ihemail1.firewall.lucent.com (localhost [127.0.0.1]) by ihemail1.firewall.lucent.com (Pro-8.9.3/8.9.3) with ESMTP id SAA29077 for ; Mon, 18 Dec 2000 18:18:15 -0500 (EST) Received: from uk0006exch001h.wins.lucent.com (h135-86-160-150.lucent.com [135.86.160.150]) by ihemail1.firewall.lucent.com (Pro-8.9.3/8.9.3) with ESMTP id SAA29063 for ; Mon, 18 Dec 2000 18:18:15 -0500 (EST) Received: by uk0006exch001h.uk.lucent.com with Internet Mail Service (5.5.2650.21) id ; Mon, 18 Dec 2000 23:18:14 -0000 Message-ID: <976F7C55E3B2D111A0720008C728549C04877649@en0060exch001u.uk.lucent.com> From: "Casati, Alessio (Alessio)" To: "'Jon Bennett'" Cc: diffserv@ietf.org Subject: RE: [Diffserv] RE: Yesterday's EF discussion Date: Mon, 18 Dec 2000 23:18:11 -0000 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: text/plain Sender: diffserv-admin@ietf.org Errors-To: diffserv-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Diffserv Discussion List X-BeenThere: diffserv@ietf.org > . If you wish I can start posting > > > references to allthe Internet2 project documentation that specifies > the > BANDWIDTH broker > > > operation and the SLA guarantees in terms of RATES and not > > > in terms of jitter, would you like me to do that? > > > > > No, thanks. We can try and discuss anyway. > > That's odd, why is it that you would not want me to do so? > If you like it better, please post references. > > The SLA is a service level specification > > stipulated between two diffserv domains. > > Rate is a service level parameter, valid at > > the edge. Nothing can be said about the rate > > configured (if no PQ is used) within the domain, and that the rate > > guarantee per se is what is needed within the domain. > > As for nothing being able to be said about rate unless PQ is > used, > (please re-read, I said that when no PQ is used, it's hard to tell which rate will be used some hops in the net based on a rate offered at the ingress of the net) [snip] > > The way this is possible is via PHB that allows > > aggregation of a number of customer networks > > in a way that they do not affect one another. > > This is possible via a PHB > > that provides strict guarantees in terms > > of delay variation across a hop. > > This is the only way that allows aggregation > > without uncontrolled burst accumulation, > > that would result in the service not being delivered > > end to end to the customer network > > asking for a "virtual wire". > > Your argument is both circular and untrue. It has been shown that with > FIFO/PQ service that you do not have control over the burst accumulation > on > a local level , and that only through network level controls can you > achieve > such control. > the network is made of hops and boundary devices. here we are saying what is needed at the hop level. > So a PHB can not make the guarantees that you want, this is a > proven fact. > Yeah, but if you pick the wrong PHB... Gotta be careful. > Repeated assertions by you to the contrary can not change > this. > Especially If I don't make them. > No, the low jitter is an end-to-end SERVICE, the provisioning of an output > rate IS the essence of the PHB as the RFC says. > > OK, so why your Internet2 SLAs did not mention the jitter? You stated that... Go at the top of this message. This is becoming a sad story to tell. alessio > > _______________________________________________ diffserv mailing list diffserv@ietf.org http://www1.ietf.org/mailman/listinfo/diffserv Archive: http://www2.ietf.org/mail-archive/working-groups/diffserv/current/maillist.html From diffserv-admin@ietf.org Tue Dec 19 03:33: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 SMTP id DAA09423 for ; Tue, 19 Dec 2000 03:33:39 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id DAA24174; Tue, 19 Dec 2000 03:12:22 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id DAA24145 for ; Tue, 19 Dec 2000 03:12:18 -0500 (EST) Received: from icasun1.epfl.ch (root@icasun1.epfl.ch [128.178.151.148]) by ietf.org (8.9.1a/8.9.1a) with SMTP id DAA09246 for ; Tue, 19 Dec 2000 03:12:17 -0500 (EST) Received: from leboudec-ntbk (ra-epfl-011.epfl.ch [128.178.84.211]) by icasun1.epfl.ch (8.8.X/EPFL-8.1d for ICA) with SMTP id JAA14389 for ; Tue, 19 Dec 2000 09:12:16 +0100 (MET) Message-Id: <4.1.20001219090435.020ff5c0@icamail1.epfl.ch> X-Sender: leboudec@icamail1.epfl.ch X-Mailer: QUALCOMM Windows Eudora Pro Version 4.1 Date: Tue, 19 Dec 2000 09:05:44 +0100 To: Diff Serv From: Jean-Yves Le Boudec Subject: Re: What's in a name? Re: [Diffserv] Yesterday's EF discussion In-Reply-To: <5.0.2.1.0.20001214144924.02844be8@localhost> References: <3A386DBA.42F44DAA@research.bell-labs.com> <3A37BF28.219E231C@hursley.ibm.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: diffserv-admin@ietf.org Errors-To: diffserv-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Diffserv Discussion List X-BeenThere: diffserv@ietf.org I vote for keeping the old name EF. The industry has started working with that name, and we shoudl keep it. JY At 14.12.2000, Bora Akyol wrote: >Having a second name effectively allows two PHBs. This was NOT the >consensus in the meeting. > >Bora > > >At 10:50 PM 12/13/2000, Grenville Armitage wrote: > > >>Brian E Carpenter wrote: >> [..] >> > What should the name of the PHB be? >> > Chair's proposal: Defined Rate (DR). I believe that after this long >> > and confusing discussion, it would be wise to retire the previous >> name. >> >>Brian, I think this suggestion is a good one. Clearly there are differing >>opinions over what RFC2598 intended. I watched from the rear of the room >>yesterday. I too saw a crowd sentiment broadly in favor of >>draft-charny(modified) as the WG PHB to support VW and similar services. >>But given the fact that "EF" has been differently interpreted by a number >>of relatively intelligent people, I cannot see the value in anyone being >>'damn right' about owning the EF name from this point onwards. The WG needs >>a standards track PHB believed to support VW, etc, services....the name >>"Defined Rate" captures the rough consensus towards the rate-based >>interpretation of RFC2598. >> >>cheers, >>gja (not, it must be noted, speaking of behalf of EFRESOLVE) >> >>_______________________________________________ >>diffserv mailing list >>diffserv@ietf.org >>http://www1.ietf.org/mailman/listinfo/diffserv >>Archive: >>http://www2.ietf.org/mail-archive/working-groups/diffserv/current/maillist. >html >> > >Bora Akyol >Pluris >akyol@pluris.com > > >_______________________________________________ >diffserv mailing list >diffserv@ietf.org >http://www1.ietf.org/mailman/listinfo/diffserv >Archive: >http://www2.ietf.org/mail-archive/working-groups/diffserv/current/maillist. html > _______________________________________________ diffserv mailing list diffserv@ietf.org http://www1.ietf.org/mailman/listinfo/diffserv Archive: http://www2.ietf.org/mail-archive/working-groups/diffserv/current/maillist.html From diffserv-admin@ietf.org Tue Dec 19 04:02: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 SMTP id EAA09653 for ; Tue, 19 Dec 2000 04:02:50 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id DAA24555; Tue, 19 Dec 2000 03:43:59 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id DAA24511 for ; Tue, 19 Dec 2000 03:43:54 -0500 (EST) Received: from sj-msg-core-2.cisco.com (sj-msg-core-2.cisco.com [171.69.43.88]) by ietf.org (8.9.1a/8.9.1a) with SMTP id DAA09494 for ; Tue, 19 Dec 2000 03:43:54 -0500 (EST) Received: from p7020-img-nt.cisco.com (fred-hm-dhcp1.cisco.com [171.69.128.116]) by sj-msg-core-2.cisco.com (8.9.3/8.9.1) with ESMTP id AAA16948; Tue, 19 Dec 2000 00:43:28 -0800 (PST) Message-Id: <5.0.2.1.2.20001219003740.0254ae40@flipper.cisco.com> X-Sender: fred@flipper.cisco.com X-Mailer: QUALCOMM Windows Eudora Version 5.0.2 Date: Tue, 19 Dec 2000 00:38:16 -0800 To: Andrew Smith From: Fred Baker Subject: Re: [Diffserv] MIB - technical comments (part 1) Cc: diffserv In-Reply-To: <3A3AD404.9080505@allegronetworks.com> References: <5.0.2.1.2.20001214154513.03a02ec0@flipper.cisco.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: diffserv-admin@ietf.org Errors-To: diffserv-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Diffserv Discussion List X-BeenThere: diffserv@ietf.org At 06:31 PM 12/15/00 -0800, Andrew Smith wrote: >>>12. 3.1 "Given some basic information, e.g. >>>ifIndex and interface direction, the first DiffServ Functional Element >>>is determined." >>>Define "first". >> >>Done, I think. "first" usually refers to the one that happens "before all >>the rest", and is fairly common in English... However, we stuck in "the >>first Diffserv Functional Datapath Element applied to a given packet on a >>given interface is determined." >>In another note, if you like, I could define "is"... > >I'm sorry, that was a serious comment that warranted a more mature >response than that. Your proposed addition helps but is not sufficient - >the scope of "first", I think, should be interface+direction, not just >interface. thanks you for clarifying the comment enough that I could figure out what you intended to result from it. _______________________________________________ diffserv mailing list diffserv@ietf.org http://www1.ietf.org/mailman/listinfo/diffserv Archive: http://www2.ietf.org/mail-archive/working-groups/diffserv/current/maillist.html From diffserv-admin@ietf.org Tue Dec 19 04:03: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 SMTP id EAA09693 for ; Tue, 19 Dec 2000 04:03:27 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id DAA24584; Tue, 19 Dec 2000 03:44:03 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id DAA24520 for ; Tue, 19 Dec 2000 03:43:55 -0500 (EST) Received: from sj-msg-core-2.cisco.com (sj-msg-core-2.cisco.com [171.69.43.88]) by ietf.org (8.9.1a/8.9.1a) with SMTP id DAA09496 for ; Tue, 19 Dec 2000 03:43:55 -0500 (EST) Received: from p7020-img-nt.cisco.com (fred-hm-dhcp1.cisco.com [171.69.128.116]) by sj-msg-core-2.cisco.com (8.9.3/8.9.1) with ESMTP id AAA16954; Tue, 19 Dec 2000 00:43:29 -0800 (PST) Message-Id: <5.0.2.1.2.20001219003829.0254bae0@flipper.cisco.com> X-Sender: fred@flipper.cisco.com X-Mailer: QUALCOMM Windows Eudora Version 5.0.2 Date: Tue, 19 Dec 2000 00:39:07 -0800 To: Andrew Smith From: Fred Baker Subject: Re: [Diffserv] Counters in the classifier Cc: diffserv@ietf.org In-Reply-To: <3A3AD451.8010202@allegronetworks.com> References: <5.0.2.1.2.20001213100135.0308d050@flipper.cisco.com> <3A37F797.F49575E6@packetdesign.com> <5.0.2.1.2.20001214122954.02508dd0@flipper.cisco.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: diffserv-admin@ietf.org Errors-To: diffserv-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Diffserv Discussion List X-BeenThere: diffserv@ietf.org At 06:32 PM 12/15/00 -0800, Andrew Smith wrote: >And the intent is for implementation to be optional for RFC >conformance/compliance purposes, correct? (of course it might become >mandatory for commercial compliance :-)) Nope. I don't do optional variables. It just means that many current implementations (including some of mine) are not quite compliant. _______________________________________________ diffserv mailing list diffserv@ietf.org http://www1.ietf.org/mailman/listinfo/diffserv Archive: http://www2.ietf.org/mail-archive/working-groups/diffserv/current/maillist.html From diffserv-admin@ietf.org Tue Dec 19 04:32:40 2000 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with SMTP id EAA10071 for ; Tue, 19 Dec 2000 04:32:40 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id EAA25602; Tue, 19 Dec 2000 04:11:08 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id EAA25571 for ; Tue, 19 Dec 2000 04:11:03 -0500 (EST) Received: from mercury.lcs.mit.edu (mercury.lcs.mit.edu [18.26.0.122]) by ietf.org (8.9.1a/8.9.1a) with SMTP id EAA09781 for ; Tue, 19 Dec 2000 04:11:00 -0500 (EST) Received: from [192.168.0.138] (h0005025edf78.ne.mediaone.net [24.147.237.14]) by mercury.lcs.mit.edu (8.9.1/8.9.1) with ESMTP id EAA17154; Tue, 19 Dec 2000 04:10:33 -0500 (EST) Mime-Version: 1.0 X-Sender: jtw_ds@mercury.lcs.mit.edu Message-Id: In-Reply-To: <7EB7C6B62C4FD41196A80090279A2911D8AB25@exchsrv1.cosinecom.com> References: <7EB7C6B62C4FD41196A80090279A2911D8AB25@exchsrv1.cosinecom.com> Date: Tue, 19 Dec 2000 04:11:14 -0500 To: Jay Wang , "'Nabil Seddigh'" From: John Wroclawski Subject: RE: [Diffserv] Dropping Strategy in AF PHB Cc: "'Brian E Carpenter'" , diffserv@ietf.org Content-Type: multipart/alternative; boundary="============_-1234905409==_ma============" Sender: diffserv-admin@ietf.org Errors-To: diffserv-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Diffserv Discussion List X-BeenThere: diffserv@ietf.org --============_-1234905409==_ma============ Content-Type: text/plain; charset="us-ascii" ; format="flowed" Jay, At 2:38 PM -0800 12/14/00, Jay Wang wrote: I don't see the connection at all on both counts. If I allow highly bursty flows to have higher chances of being dropped than those perfectly smoothed, since they are placed under the same PSC, when RED kicks in I drop packets marked out-of-profile first. And those packets tend to be ones coming from the bursty flows. It won't be tail-dropping. Also, giving smooth traffic better treatment does not necessarily mean I do or have to discount the past history either. thanks. - Jay One intended use of AF is as a building block for services/situations that use dropped packets to indicate that a source currently needs to slow down (to stay within a numerical profile, or to get a relative share, or whatever). If the feedback signal (pkt drop) is not independent of the detailed shape of a flow's traffic it becomes hard to build systems that assure a flow some level of capacity or performance independent of the detailed shape of the traffic it is generating. (It does occur to me that we might have been a little more concrete about what "short-term" means in this paragraph - it is talking about very short-term sub-congestion-control-response-time transient bursts, not some longer short term such as "a minute or two". Hope that is apparent from the context..) There's no particular reason to think that bursty flows are more likely to have out-of-profile packets than CBR flows. One could, for example, run a CBR layered codec against a profile that gave you high assurance of the base layer getting through, but sent the higher layers opportunistically as out-of-profile packets. Cheers John > -----Original Message----- > From: Nabil Seddigh >[mailto:nseddigh@nortelnetworks.co >m] > Sent: Thursday, December 14, 2000 2:04 PM > To: Jay Wang > Cc: 'Brian E Carpenter'; diffserv@ietf.org > Subject: re:[Diffserv] Dropping Strategy in AF PHB > > > >"The dropping algorithm MUST be insensitive to the short-term > >traffic characteristics of the micro flows using AF class. > >That is, flows with different short-term burst but identical > >longer-term packets rates should have packets discarded with > >essentially equal probability." > > > >For one thing, I don't know why the authors of the RFC wanted > >to mandate this. > > There was certainly a lot of attention paid to AF. > > If I recall correctly, the intent of the quoted paragraph was > to ensure > > that drop-tail was not used for AF. It essentially mandates an AQM > mechanism that takes past history into account when making its drop > decisions. I don't think the intent of that paragraph was > to require per-micro-flow drop decisions. > > Best > Nabil > --============_-1234905409==_ma============ Content-Type: text/html; charset="us-ascii" RE: [Diffserv] Dropping Strategy in AF PHB
Jay,

At 2:38 PM -0800 12/14/00, Jay Wang wrote:
I don't see the connection at all on both counts.  If I
allow highly bursty flows to have higher chances of being
dropped than those perfectly smoothed, since they are placed
under the same PSC, when RED kicks in I drop packets marked
out-of-profile first. And those packets tend to be ones
coming from the bursty flows.  It won't be tail-dropping. 
Also, giving smooth traffic better treatment does not
necessarily mean I do or have to discount the past history either.
thanks.
- Jay


One intended use of AF is as a building block for services/situations that use dropped packets to indicate that a source currently needs to slow down (to stay within a numerical profile, or to get a relative share, or whatever). If the feedback signal (pkt drop) is not independent of the detailed shape of a flow's traffic it becomes hard to build systems that assure a flow some level of capacity or performance independent of the detailed shape of the traffic it is generating.

(It does occur to me that we might have been a little more concrete about what "short-term" means in this paragraph - it is talking about very short-term sub-congestion-control-response-time transient bursts, not some longer short term such as "a minute or two". Hope that is apparent from the context..)

There's no particular reason to think that bursty flows are more likely to have out-of-profile packets than CBR flows. One could, for example, run a CBR layered codec against a profile that gave you high assurance of the base layer getting through, but sent the higher layers opportunistically as out-of-profile packets.

Cheers
John


> -----Original Message-----
> From: Nabil Seddigh [mailto:nseddigh@nortelnetworks.com]
> Sent: Thursday, December 14, 2000 2:04 PM
> To: Jay Wang
> Cc: 'Brian E Carpenter'; diffserv@ietf.org
> Subject: re:[Diffserv] Dropping Strategy in AF PHB
>
>
> >"The dropping algorithm MUST be insensitive to the short-term
> >traffic characteristics of the micro flows using AF class.
> >That is, flows with different short-term burst but identical
> >longer-term packets rates should have packets discarded with
> >essentially equal probability."
> >
> >For one thing, I don't know why the authors of the RFC wanted
> >to mandate this.
>
> There was certainly a lot of attention paid to AF.
>
> If I recall correctly, the intent of the quoted paragraph was
> to  ensure
>
> that drop-tail was not used for AF. It essentially mandates an AQM
> mechanism that takes past history into account when making its drop
> decisions. I don't think the intent of that paragraph was
> to require per-micro-flow drop decisions.
>
> Best
> Nabil
>

--============_-1234905409==_ma============-- _______________________________________________ diffserv mailing list diffserv@ietf.org http://www1.ietf.org/mailman/listinfo/diffserv Archive: http://www2.ietf.org/mail-archive/working-groups/diffserv/current/maillist.html From diffserv-admin@ietf.org Tue Dec 19 11:39: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 SMTP id LAA17756 for ; Tue, 19 Dec 2000 11:39:41 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id LAA00338; Tue, 19 Dec 2000 11:03:26 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id LAA00305 for ; Tue, 19 Dec 2000 11:03:22 -0500 (EST) Received: from mailhub1.almaden.ibm.com (mailhub1.almaden.ibm.com [198.4.83.44]) by ietf.org (8.9.1a/8.9.1a) with SMTP id LAA16893 for ; Tue, 19 Dec 2000 11:03:18 -0500 (EST) Received: from maui.almaden.ibm.com (maui.almaden.ibm.com [9.1.24.92]) by mailhub1.almaden.ibm.com (8.8.8/8.8.8) with ESMTP id HAA39340 for ; Tue, 19 Dec 2000 07:58:08 -0800 Received: from hursley.ibm.com (gsine03.us.sine.ibm.com [9.14.6.43]) by maui.almaden.ibm.com (AIX4.3/8.9.3/8.7) with ESMTP id IAA22298 for ; Tue, 19 Dec 2000 08:02:50 -0800 Message-ID: <3A3F8659.3CC2CC7C@hursley.ibm.com> Date: Tue, 19 Dec 2000 10:01:29 -0600 From: Brian E Carpenter Organization: IBM X-Mailer: Mozilla 4.61 [en] (Win98; I) X-Accept-Language: en,fr MIME-Version: 1.0 To: Diff Serv Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Subject: [Diffserv] Enough said for now Sender: diffserv-admin@ietf.org Errors-To: diffserv-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Diffserv Discussion List X-BeenThere: diffserv@ietf.org Content-Transfer-Encoding: 7bit Thnaks to everyone who commented on my attached summary of last week's EF discussion in San Diego. I would like to summarise the rough consensus as it now appears. A replacement for RFC 2598 should be drafted, in the strict format of a PHB definition as specified in RFC 2474, based on the "possible compromise" revision to the model described in draft-charny-ef-definition-01.txt. This is to be progressed as a WG draft intended to be submitted as a Proposed Standard. The name Expedited Forwarding and the recommended code point 101110 will be used for this. Bruce Davie has agreed to act as document editor for the new draft. In private, both the RFC 2598 authors and the EFRESOLVE authors have declined to be co-authors of the new draft. I suggest that it would be appropriate to wait for the new draft before debating its hypothetical content. There will of course be a WG last call in due course. Brian Carpenter diffserv co-chair -------- Original Message -------- Subject: Yesterday's EF discussion Date: Wed, 13 Dec 2000 12:25:44 -0600 From: Brian E Carpenter Organization: IBM To: Diff Serv Summary of conclusions from EF discussion on 12/12/2000 ------------------------------------------------------- 1. After discussion, the 5 possible directions for the EF PHB were reduced to 4: 0/ Do nothing. The WG agrees that we are not yet ready to replace RFC 2598 due to lack of consensus. Publish the Charny et al and EFRESOLVE drafts as Informational RFCs, and revisit the question in late 2001. This option was rapidly eliminated by straw poll. 1/ The WG agrees that the work of the EFRESOLVE design team is the basis of the revised EF RFC, and that Charny et al should be progressed for the record as an Informational RFC. 2/ The WG agrees that the work of Anna Charny's group, modified as in the "possible compromise" message sent to the WG by Bruce Davie on Decemebr 7 is the basis of the revised EF RFC and that the EFRESOLVE draft should be published for the record as an Informational RFC. 3/ The WG agrees that the two groups are talking about two different PHBs and that they both should be worked on independentlly, as two separate standards track documents. A first straw poll showed that a small majority of those voting would be prepared to accept two PHBs (option 3). A second straw poll showed that if only one PHB was to be standardised to update RFC 2598, a large majority would prefer option 2. A third straw poll showed that a large majority would prefer only one PHB (this is not inconsistent with the first straw poll, but it eliminates option 3). It was however observed that anyone can submit a PHB to the WG, although the WG charter currently excludes defining more standard PHBs. There was insufficient time to discuss the issues of naming and code points. ---------------------- Proposed expression of WG consensus: A replacement for RFC 2598 should be drafted, in the strict format of a PHB definition as specified in RFC 2474, based on the "possible compromise" revision to the model described in draft-charny-ef-definition-01.txt. This is to be progressed as a WG draft intended to be submitted as a Proposed Standard. Open issues: Authorship of the new document. Chair's proposal: all contributors to RFC 2598, to draft-charny-ef-definition-01.txt, and to draft-ietf-diffserv-efresolve-00.txt should be recognized as authors. Should the recommended code point be 101110? Chair's proposal: yes What should the name of the PHB be? Chair's proposal: Defined Rate (DR). I believe that after this long and confusing discussion, it would be wise to retire the previous name. Brian Carpenter diffserv co-chair _______________________________________________ diffserv mailing list diffserv@ietf.org http://www1.ietf.org/mailman/listinfo/diffserv Archive: http://www2.ietf.org/mail-archive/working-groups/diffserv/current/maillist.html From diffserv-admin@ietf.org Tue Dec 19 12:11: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 SMTP id MAA18546 for ; Tue, 19 Dec 2000 12:11:41 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id LAA00992; Tue, 19 Dec 2000 11:46:52 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id LAA00965 for ; Tue, 19 Dec 2000 11:46:48 -0500 (EST) Received: from mta6.snfc21.pbi.net (mta6.snfc21.pbi.net [206.13.28.240]) by ietf.org (8.9.1a/8.9.1a) with SMTP id LAA17899 for ; Tue, 19 Dec 2000 11:46:44 -0500 (EST) Received: from allegronetworks.com ([206.170.32.194]) by mta6.snfc21.pbi.net (Sun Internet Mail Server sims.3.5.2000.01.05.12.18.p9) with ESMTP id <0G5T00480PZEEJ@mta6.snfc21.pbi.net> for diffserv@ietf.org; Tue, 19 Dec 2000 08:33:15 -0800 (PST) Date: Tue, 19 Dec 2000 08:42:06 -0800 From: Andrew Smith Subject: Re: [Diffserv] Counters in the classifier To: Fred Baker Cc: diffserv@ietf.org Message-id: <3A3F8FDE.8060302@allegronetworks.com> Organization: Allegro Networks MIME-version: 1.0 Content-type: text/plain; charset=us-ascii; format=flowed Content-transfer-encoding: 7bit User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; m18) Gecko/20001108 Netscape6/6.0 X-Accept-Language: en References: <5.0.2.1.2.20001213100135.0308d050@flipper.cisco.com> <3A37F797.F49575E6@packetdesign.com> <5.0.2.1.2.20001214122954.02508dd0@flipper.cisco.com> <5.0.2.1.2.20001219003829.0254bae0@flipper.cisco.com> Content-Transfer-Encoding: 7bit Sender: diffserv-admin@ietf.org Errors-To: diffserv-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Diffserv Discussion List X-BeenThere: diffserv@ietf.org Content-Transfer-Encoding: 7bit I'd object strongly to this change then - I'd like to see quite a lot more support for this idea before declaring WG consensus on this change. Making "debug counters" a mandatory part of a MIB like this is not a good way to do standards. Andrew Fred Baker wrote: > At 06:32 PM 12/15/00 -0800, Andrew Smith wrote: > >> And the intent is for implementation to be optional for RFC >> conformance/compliance purposes, correct? (of course it might become >> mandatory for commercial compliance :-)) > > > Nope. I don't do optional variables. It just means that many current > implementations (including some of mine) are not quite compliant. > > > _______________________________________________ > diffserv mailing list > diffserv@ietf.org > http://www1.ietf.org/mailman/listinfo/diffserv > Archive: > http://www2.ietf.org/mail-archive/working-groups/diffserv/current/maillist.html _______________________________________________ diffserv mailing list diffserv@ietf.org http://www1.ietf.org/mailman/listinfo/diffserv Archive: http://www2.ietf.org/mail-archive/working-groups/diffserv/current/maillist.html From diffserv-admin@ietf.org Tue Dec 19 12:28: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 SMTP id MAA18948 for ; Tue, 19 Dec 2000 12:28:17 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id LAA00947; Tue, 19 Dec 2000 11:44:35 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id LAA00916 for ; Tue, 19 Dec 2000 11:44:31 -0500 (EST) Received: from zrtps06s.us.nortel.com (h50s48a140n47.user.nortelnetworks.com [47.140.48.50]) by ietf.org (8.9.1a/8.9.1a) with SMTP id LAA17875 for ; Tue, 19 Dec 2000 11:44:28 -0500 (EST) Received: from zbl6c016.corpeast.baynetworks.com by zrtps06s.us.nortel.com; Tue, 19 Dec 2000 11:33:26 -0500 Received: from zbl6c002.corpeast.baynetworks.com ([132.245.205.52]) by zbl6c016.corpeast.baynetworks.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2652.39) id W8KSQNZ2; Tue, 19 Dec 2000 11:33:14 -0500 Received: from nortelnetworks.com (dhcp223-140.engeast.baynetworks.com [192.32.223.140]) by zbl6c002.corpeast.baynetworks.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2652.39) id YJ8X8WMN; Tue, 19 Dec 2000 11:33:15 -0500 Message-ID: <3A3F8E08.92034478@nortelnetworks.com> Date: Tue, 19 Dec 2000 11:34:16 -0500 X-Sybari-Space: 00000000 00000000 00000000 From: "Victor Firoiu" Organization: Nortel Networks X-Mailer: Mozilla 4.61 [en]C-{C-UDP; SSBARNEY} (Win98; U) X-Accept-Language: en MIME-Version: 1.0 To: "diffserv@ietf.org" Subject: Re: [Fwd: RE: [Diffserv] Yesterday's EF discussion] References: <3A3E96D9.4FCD6CBD@iprg.nokia.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Orig: Content-Transfer-Encoding: 7bit Sender: diffserv-admin@ietf.org Errors-To: diffserv-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 am also in favor of keeping the EF name for essentially the same reasons as below. Victor Firoiu Nortel Networks > -------- Original Message -------- > Subject: RE: [Diffserv] Yesterday's EF discussion > Date: Fri, 15 Dec 2000 15:15:28 -0800 > From: Martha Zimet > Organization: Nokia IP Routing > To: diffserv@ietf.org > > I wish to add my vote to keeping the 'EF' name for the following > reasons: > > 1. A new name will imply a new PHB, which is contrary to what I > thought the recent WG goals were (e.g. fix and not re-create). > > 2. Since the 'EF' PHB (RFC 2598) was a proposed standard for a length > of time, like other vendors, we have already implemented our version > of the 'EF' PHB and its corresponding DSCP based on our understanding > of the RFC. This is realized in our current Nokia IPRG products, > network management infrastructure, documentation, training classes, > etc. > > 3. Changing the name will be the most confusing to the those who are > not well versed in the underlying semantics in the first place. In > addition, it will cause added overhead to those of us who are involved > in explaining and socializing diffserv in our respective corporate > environments. > > Regards, > > /martha > _______________________________________________ diffserv mailing list diffserv@ietf.org http://www1.ietf.org/mailman/listinfo/diffserv Archive: http://www2.ietf.org/mail-archive/working-groups/diffserv/current/maillist.html From diffserv-admin@ietf.org Tue Dec 19 12:32: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 SMTP id MAA19056 for ; Tue, 19 Dec 2000 12:32:23 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id MAA01688; Tue, 19 Dec 2000 12:06:19 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id MAA01659 for ; Tue, 19 Dec 2000 12:06:15 -0500 (EST) Received: from artemis.shef.ac.uk ([143.167.2.11]) by ietf.org (8.9.1a/8.9.1a) with SMTP id MAA18414 for ; Tue, 19 Dec 2000 12:06:03 -0500 (EST) Received: from [143.167.2.154] (helo=mailhub2.shef.ac.uk) by artemis.shef.ac.uk with esmtp (Exim 3.16 #2) id 148QCx-0001Ko-00 for diffserv@ietf.org; Tue, 19 Dec 2000 17:05:47 +0000 Received: from dyn059145.shef.ac.uk ([143.167.59.145] helo=qosnet2) by mailhub2.shef.ac.uk with smtp (Exim 3.16 #1) id 148QCx-0004FE-00 for diffserv@ietf.org; Tue, 19 Dec 2000 17:05:47 +0000 Message-ID: <006a01bf4a45$3a4b8590$913ba78f@qos.shef.ac.uk> From: "xin chen" To: Date: Sun, 19 Dec 1999 17:19:38 -0000 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0067_01BF4A45.3A40D730" 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 X-Scanner: exiscan@artemis *148QCx-0001Ko-00* http://duncanthrax.net/exiscan/ Subject: [Diffserv] How to unsubscribe Differv mailing list? Sender: diffserv-admin@ietf.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_0067_01BF4A45.3A40D730 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable ------=_NextPart_000_0067_01BF4A45.3A40D730 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
 
------=_NextPart_000_0067_01BF4A45.3A40D730-- _______________________________________________ diffserv mailing list diffserv@ietf.org http://www1.ietf.org/mailman/listinfo/diffserv Archive: http://www2.ietf.org/mail-archive/working-groups/diffserv/current/maillist.html From diffserv-admin@ietf.org Tue Dec 19 12:49: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 SMTP id MAA19589 for ; Tue, 19 Dec 2000 12:49:05 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id MAA01861; Tue, 19 Dec 2000 12:13:55 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id MAA01830 for ; Tue, 19 Dec 2000 12:13:50 -0500 (EST) 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 SMTP id MAA18617 for ; Tue, 19 Dec 2000 12:13:46 -0500 (EST) Received: from stl-av-02.boeing.com ([192.76.190.7]) by stl-smtpout-01.boeing.com (8.9.2/8.8.5-M2) with ESMTP id LAA24163 for ; Tue, 19 Dec 2000 11:13:47 -0600 (CST) Received: from stl-hub-01.boeing.com (localhost [127.0.0.1]) by stl-av-02.boeing.com (8.9.3/8.9.2) with ESMTP id LAA00444 for ; Tue, 19 Dec 2000 11:13:31 -0600 (CST) Received: from xch-phlbh-01.he.boeing.com by stl-hub-01.boeing.com with ESMTP; Tue, 19 Dec 2000 11:13:16 -0600 Received: by xch-phlbh-01.he.boeing.com with Internet Mail Service (5.5.2650.21) id ; Tue, 19 Dec 2000 12:13:13 -0500 Message-Id: <4102273CEB77D211869200805FE6F593018C5C12@xch-phl-01.he.boeing.com> From: "Manfredi, Albert E" To: "'Brian E Carpenter'" , Diff Serv Subject: RE: [Diffserv] Enough said for now Date: Tue, 19 Dec 2000 12:13:12 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: text/plain; charset="iso-8859-1" Sender: diffserv-admin@ietf.org Errors-To: diffserv-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Diffserv Discussion List X-BeenThere: diffserv@ietf.org Brian E Carpenter wrote: > Thnaks to everyone who commented on my attached summary of last week's > EF discussion in San Diego. I would like to summarise the > rough consensus > as it now appears. > > A replacement for RFC 2598 should be drafted, in the strict format > of a PHB definition as specified in RFC 2474, based on the > "possible compromise" revision to the model described in > draft-charny-ef-definition-01.txt. This is to be progressed as > a WG draft intended to be submitted as a Proposed Standard. > > The name Expedited Forwarding and the recommended code point 101110 > will be used for this. Aw shucks. And here I had just come up with two really good names: Adjustable Transport Medium - Constrained Bitrate Retardation, and Adjustable Transport Medium - Guaranteed Frame Rate. Or perhaps simply ATM-CBR and ATM-GFR, for short. Bert _______________________________________________ diffserv mailing list diffserv@ietf.org http://www1.ietf.org/mailman/listinfo/diffserv Archive: http://www2.ietf.org/mail-archive/working-groups/diffserv/current/maillist.html From diffserv-admin@ietf.org Tue Dec 19 13:00:17 2000 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with SMTP id NAA19889 for ; Tue, 19 Dec 2000 13:00:17 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id MAA02091; Tue, 19 Dec 2000 12:26:50 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id MAA02060 for ; Tue, 19 Dec 2000 12:26:45 -0500 (EST) Received: from relay1.alcatel.be (alc119.alcatel.be [195.207.101.119]) by ietf.org (8.9.1a/8.9.1a) with SMTP id MAA18921 for ; Tue, 19 Dec 2000 12:26:41 -0500 (EST) From: Emmanuel.Desmet@alcatel.be Received: from bemail01.net.alcatel.be (localhost [127.0.0.1]) by relay1.alcatel.be (8.10.1/8.10.1) with SMTP id eBJHQDE06736 for ; Tue, 19 Dec 2000 18:26:13 +0100 (MET) Received: by bemail01.net.alcatel.be(Lotus SMTP MTA v4.6.7 (934.1 12-30-1999)) id C12569BA.005FC50A ; Tue, 19 Dec 2000 18:26:03 +0100 X-Lotus-FromDomain: ALCATEL To: "diffserv@ietf.org" Message-ID: Date: Tue, 19 Dec 2000 18:26:00 +0100 Subject: Re: [Fwd: RE: [Diffserv] Yesterday's EF discussion] Mime-Version: 1.0 Content-type: text/plain; charset=us-ascii Content-Disposition: inline Sender: diffserv-admin@ietf.org Errors-To: diffserv-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Diffserv Discussion List X-BeenThere: diffserv@ietf.org Likewise, manu --------------- I am also in favor of keeping the EF name for essentially the same reasons as below. Victor Firoiu Nortel Networks > -------- Original Message -------- > Subject: RE: [Diffserv] Yesterday's EF discussion > Date: Fri, 15 Dec 2000 15:15:28 -0800 > From: Martha Zimet > Organization: Nokia IP Routing > To: diffserv@ietf.org > > I wish to add my vote to keeping the 'EF' name for the following > reasons: > > 1. A new name will imply a new PHB, which is contrary to what I > thought the recent WG goals were (e.g. fix and not re-create). > > 2. Since the 'EF' PHB (RFC 2598) was a proposed standard for a length > of time, like other vendors, we have already implemented our version > of the 'EF' PHB and its corresponding DSCP based on our understanding > of the RFC. This is realized in our current Nokia IPRG products, > network management infrastructure, documentation, training classes, > etc. > > 3. Changing the name will be the most confusing to the those who are > not well versed in the underlying semantics in the first place. In > addition, it will cause added overhead to those of us who are involved > in explaining and socializing diffserv in our respective corporate > environments. > > Regards, > > /martha > _______________________________________________ diffserv mailing list diffserv@ietf.org http://www1.ietf.org/mailman/listinfo/diffserv Archive: http://www2.ietf.org/mail-archive/working-groups/diffserv/current/maillist.html _______________________________________________ diffserv mailing list diffserv@ietf.org http://www1.ietf.org/mailman/listinfo/diffserv Archive: http://www2.ietf.org/mail-archive/working-groups/diffserv/current/maillist.html From diffserv-admin@ietf.org Tue Dec 19 13:59: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 SMTP id NAA21539 for ; Tue, 19 Dec 2000 13:59:48 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id NAA03139; Tue, 19 Dec 2000 13:07:42 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id NAA03108 for ; Tue, 19 Dec 2000 13:07:38 -0500 (EST) Received: from p-mail2.cnet.fr (p-mail2.rd.francetelecom.fr [193.49.124.32]) by ietf.org (8.9.1a/8.9.1a) with SMTP id NAA20195 for ; Tue, 19 Dec 2000 13:07:35 -0500 (EST) Received: by p-voyageur.issy.cnet.fr with Internet Mail Service (5.5.2650.21) id ; Tue, 19 Dec 2000 19:00:20 +0100 Message-ID: <91A311FF6A85D3118DDF0060080C3D82B7DAC1@lat3721.lannion.cnet.fr> From: GARBISU Jean-Pierre FTRD/DMI/CAE To: "'Kwok-Ho Chan'" , GARBISU Jean-Pierre FTRD/DMI/CAE Cc: "'diffserv@ietf.org'" Subject: RE: [Diffserv] DiffServ MIB Counters + PIB counters Date: Tue, 19 Dec 2000 18:58:26 +0100 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: text/plain; charset="ISO-8859-1" X-MIME-Autoconverted: from quoted-printable to 8bit by optimus.ietf.org id NAA03109 Sender: diffserv-admin@ietf.org Errors-To: diffserv-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Diffserv Discussion List X-BeenThere: diffserv@ietf.org X-MIME-Autoconverted: from 8bit to quoted-printable by optimus.ietf.org id NAA03139 Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by ietf.org id NAA21539 sorry for this late answer to a previous mail thinking of one of the last comments of F.Baker on an accounting tool for SLA I think it was one of the main idea behind my questions i.e. how much the MIB will help to verify SLS, and also give infos to TE tools for CoS for this I guess we need more careful counting than for best effort traffic, possibly at the main stages of forwarding plane identified in the model on your previous answers : OK : on 1 and 2 3 : policed datagrams refer to droppped datagrams (by absolute droppers)so no count is envisioned it seems. 4 : it's an agreement 5 : OK but I know people/projects who would like this info for e.g. Traffic Engineering optimisation purposes. I heard that some linux boxes do have this type of info (but I don't strongly affirm it and want to stay in diffserv charter ;-) 6 : it seems clear that there is a necessary trade-off between counters richness and all performance issues, unnecessary counters etc. but at this point I don't really see what is the recommended way for a service provider to evaluate the efficiency of weights attribution to queues in various schedulers i.e. the conf of the PHB if some counters don't give info on average use of queues? 7: datagrams dropped due to maximum service rate in a queue are certainly dropped by absolute droppers not by algorithmic droppers (they are out of profile in their queue) (please think, secretly, of VoIP implementations :-)) 8 : OK 9 : OK best regards jeanpierre.garbisu@francetelecom.fr -----Message d'origine----- De : Kwok-Ho Chan [mailto:khchan@nortelnetworks.com] Envoyé : jeudi 16 novembre 2000 21:09 À : GARBISU Jean-Pierre FTRD/DMI/CAE Cc : 'diffserv@ietf.org' Objet : Re: [Diffserv] DiffServ MIB Counters + PIB counters Jean-Pierre: Please find response embedded. Please let me know if this answers/resolved the issues you indicated. Thanks! -- Kwok -- At 02:38 PM 11/13/00 +0100, GARBISU Jean-Pierre FTRD/DMI/CAE wrote: >Hi >herafter you 'll find a few questions on Counters related to the diffserv >MIB draft (+ one question on the PIB) >sorry if some of these questions were already asked >best regards. > >In §3.3.2 it's written >"Count Actions are used to count the traffic passing along a particular >path through the model. If specified, they are likely to be placed >first, before other types of Action. For example, when both a Count and >an Absolute Dropper Action are specified, the Count Action needs to >count the traffic stream before any traffic gets dropped. Note that >there are counters contained directly in Algorithmic Dropper elements to >indicate the amount of traffic dropped by those elements." > >Can you confirm/comment the following : > >1. there are no specific diffserv counters counting all datagrams received >before classification stage. >1bis. this information is available through MIB II interface counters. Is it >totally unnecessary to "repeat this info" in the diffserv MIB for any kind >of optimization purpose? It was the view of the authors that the info are already available in other counters and no need to be repeated within DiffServ counters. But the Model does not limit an implementation to create a Counter-Only-TCB and place this TCB as the first TCB to process DiffServ data flow, if a specific implementation requires such setup. Do you see any cases this will not work? >2. you recommend to count datagramms (per BA) after classification stage (at >this point DSCP is not attributed; it's going to be in the following action >stage i.e. marking). The Count Action in this case is immediately before the Mark Action, with the same packets/bits flowing thru both, hence the order of the Actions is not important in this case. >3. why absolute droppers must/should not count policed datagrams? at this >point it seems one must get meter configuration information to retrieve this >information, if needed. Please reference Model-04 draft section 8 for the following discussion. By "policed datagrams" I take you mean Metered, with some datagrams conforming, and some non-conforming. In Model (constructable in MIB) draft, Metering stage happens before the Action stage, hence Metered/policed datagrams are counted. The manager does need to know which Count Action entry represent the conforming and non-conforming branches of the Meter. >4. you recommend to count datagramms dropped (per BA) per algorithmic >droppers. Please clarify, is this a question, agreement, comments? There are counters in algorithmic dropper. >5. there is no recommended diffserv counters defined for average occupancy >of the BA queues. In previous WG discussions, it was decided that queue average occupancy need not be accessible outside of a device. >6. there is no recommended diffserv counters defined for unused bandwidth >re-attribution between queues. >6bis. shouldn't be valuable to count this re-attribution in any way to allow >any kind of subsequent weights optimization of the concerned schedulers? The MIB does not limit one to add implementation specific Action stages to do some of the things you are talking about. One may say the MIB is too flexible. Do you value such flexibility? >7. do you recommend any counters for datagramms dropped due to maximum >service rate in a queue? I think that is taken care of by Algorithmic Dropper's counters, please let me know if you think otherwise. >8. how far the diffserv MIB specification is supposed to indicate the >optional or mandatory counting or no counting stages? The MIB recommends at least one Count Action after each branch of Meter. Note this is a recommendation, not a requirement. Any additional counters are up to implementation needs and capability. > >9. one of the main functional "differences" between MIB and PIB >specifications seems to be the absence of counters in the PIB spec (both MIB >and PIB covering the configuration of the TCB). Is it a current issue? Is >there any plan for specifying appropriate counters in the PIB spec. The DiffServ PIB is for provisioning only, not monitoring, hence no counters are defined there. Another PIB can be defined for counting purpose. Such a PIB "Accounting PIB" is being developed in the RAP WG, which is general purpose Accounting info, not just DiffServ. > >jeanpierre.garbisu@francetelecom.fr > > > >_______________________________________________ >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://www2.ietf.org/mail-archive/working-groups/diffserv/current/maillist.html From diffserv-admin@ietf.org Tue Dec 19 13:59: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 SMTP id NAA21542 for ; Tue, 19 Dec 2000 13:59:48 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id NAA02876; Tue, 19 Dec 2000 13:00:18 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id NAA02838 for ; Tue, 19 Dec 2000 13:00:13 -0500 (EST) Received: from sj-msg-core-2.cisco.com (sj-msg-core-2.cisco.com [171.69.43.88]) by ietf.org (8.9.1a/8.9.1a) with SMTP id NAA19876 for ; Tue, 19 Dec 2000 13:00:11 -0500 (EST) Received: from p7020-img-nt.cisco.com (dhcp-10-34-54-158.cisco.com [10.34.54.158]) by sj-msg-core-2.cisco.com (8.9.3/8.9.1) with ESMTP id JAA06363; Tue, 19 Dec 2000 09:59:45 -0800 (PST) Message-Id: <5.0.2.1.2.20001219094549.02766080@flipper.cisco.com> X-Sender: fred@flipper.cisco.com X-Mailer: QUALCOMM Windows Eudora Version 5.0.2 Date: Tue, 19 Dec 2000 09:56:21 -0800 To: Andrew Smith From: Fred Baker Subject: Re: [Diffserv] Counters in the classifier Cc: diffserv@ietf.org In-Reply-To: <3A3F8FDE.8060302@allegronetworks.com> References: <5.0.2.1.2.20001213100135.0308d050@flipper.cisco.com> <3A37F797.F49575E6@packetdesign.com> <5.0.2.1.2.20001214122954.02508dd0@flipper.cisco.com> <5.0.2.1.2.20001219003829.0254bae0@flipper.cisco.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: diffserv-admin@ietf.org Errors-To: diffserv-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Diffserv Discussion List X-BeenThere: diffserv@ietf.org At 08:42 AM 12/19/00 -0800, Andrew Smith wrote: >I'd object strongly to this change then - I'd like to see quite a lot more >support for this idea before declaring WG consensus on this change. Making >"debug counters" a mandatory part of a MIB like this is not a good way to >do standards. I am, therefore, looking for supporting or negating commentary from the list. My reason for not doing "optional", by the way, is historical. First, a design guideline we have always followed with SNMP MIBs has been to avoid optional objects - maybe you provide a read-only and a read-write implementation option, or you say that a MIB covers several classes of systems, and if you are doing a system of class A then you need groups {A}, but that would rarely apply to individual objects. Second, a large part of the problem with OSI protocols was the number of options. Options were used in that design process as a way to gain consensus - if I don't have to do it, I will be less inclined to vote "no". However, it very quickly became difficult to come up with a subset of any given protocol wherein any two vendors were interoperable. This was OSI's Achilles Heel. That's not where we want to go with IP standards. Third, implementing this using a redirection to an optional object, as was proposed in the working group meeting, has the ills I mentioned in a previous email. It might make for working group consensus on the basis of "I don't actually have to implement it", but it makes for an operational headache beyond interoperability. At the end of the day, we're not building this for the working group, we're building it for the operators. We need to give them a usable product. Fourth, if something is truly optional, then it is not truly needed, and another design guideline for SNMP MIBs has always been to leave out that which is unnecessary. If it is truly optional, then it doesn't belong in the MIB. So, I don't care whether it is in or out. Somebody wanted it and argued for it, and the working group decided to accept it. I understand, I think, why they want it, and I buy the argument. If we can pick one - it is needed and should be in, or it is not needed and should be out - I'm happy. I just want a product the network operators can use when we're done. _______________________________________________ diffserv mailing list diffserv@ietf.org http://www1.ietf.org/mailman/listinfo/diffserv Archive: http://www2.ietf.org/mail-archive/working-groups/diffserv/current/maillist.html From diffserv-admin@ietf.org Tue Dec 19 14:32: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 SMTP id OAA22647 for ; Tue, 19 Dec 2000 14:32:55 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id OAA04123; Tue, 19 Dec 2000 14:00:06 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id OAA04092 for ; Tue, 19 Dec 2000 14:00:01 -0500 (EST) Received: from mailhub1.almaden.ibm.com (mailhub1.almaden.ibm.com [198.4.83.44]) by ietf.org (8.9.1a/8.9.1a) with SMTP id NAA21559 for ; Tue, 19 Dec 2000 13:59:57 -0500 (EST) Received: from maui.almaden.ibm.com (maui.almaden.ibm.com [9.1.24.92]) by mailhub1.almaden.ibm.com (8.8.8/8.8.8) with ESMTP id KAA35834; Tue, 19 Dec 2000 10:54:44 -0800 Received: from hursley.ibm.com (gsine03.us.sine.ibm.com [9.14.6.43]) by maui.almaden.ibm.com (AIX4.3/8.9.3/8.7) with ESMTP id KAA22342; Tue, 19 Dec 2000 10:59:27 -0800 Message-ID: <3A3FAF0C.6E4C942E@hursley.ibm.com> Date: Tue, 19 Dec 2000 12:55:08 -0600 From: Brian E Carpenter Organization: IBM X-Mailer: Mozilla 4.61 [en] (Win98; I) X-Accept-Language: en,fr MIME-Version: 1.0 To: xin chen CC: diffserv@ietf.org Subject: Re: [Diffserv] How to unsubscribe Differv mailing list? References: <006a01bf4a45$3a4b8590$913ba78f@qos.shef.ac.uk> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: diffserv-admin@ietf.org Errors-To: diffserv-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Diffserv Discussion List X-BeenThere: diffserv@ietf.org Content-Transfer-Encoding: 7bit All subscribers were sent a password and the instructions when they subscribed. Go to http://www1.ietf.org/mailman/options/diffserv/elp99xc@sheffield.ac.uk Brian > xin chen wrote: > > _______________________________________________ diffserv mailing list diffserv@ietf.org http://www1.ietf.org/mailman/listinfo/diffserv Archive: http://www2.ietf.org/mail-archive/working-groups/diffserv/current/maillist.html From diffserv-admin@ietf.org Tue Dec 19 14:33: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 SMTP id OAA22661 for ; Tue, 19 Dec 2000 14:33:02 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id OAA04405; Tue, 19 Dec 2000 14:07:57 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id OAA04369 for ; Tue, 19 Dec 2000 14:07:47 -0500 (EST) Received: from mailhub1.almaden.ibm.com (mailhub1.almaden.ibm.com [198.4.83.44]) by ietf.org (8.9.1a/8.9.1a) with SMTP id OAA21863 for ; Tue, 19 Dec 2000 14:07:45 -0500 (EST) Received: from maui.almaden.ibm.com (maui.almaden.ibm.com [9.1.24.92]) by mailhub1.almaden.ibm.com (8.8.8/8.8.8) with ESMTP id LAA36104; Tue, 19 Dec 2000 11:02:31 -0800 Received: from hursley.ibm.com (gsine03.us.sine.ibm.com [9.14.6.43]) by maui.almaden.ibm.com (AIX4.3/8.9.3/8.7) with ESMTP id LAA20488; Tue, 19 Dec 2000 11:07:14 -0800 Message-ID: <3A3FB0DC.5089B47E@hursley.ibm.com> Date: Tue, 19 Dec 2000 13:02:52 -0600 From: Brian E Carpenter Organization: IBM X-Mailer: Mozilla 4.61 [en] (Win98; I) X-Accept-Language: en,fr MIME-Version: 1.0 To: Fred Baker CC: Andrew Smith , diffserv@ietf.org Subject: Re: [Diffserv] Counters in the classifier References: <5.0.2.1.2.20001213100135.0308d050@flipper.cisco.com> <3A37F797.F49575E6@packetdesign.com> <5.0.2.1.2.20001214122954.02508dd0@flipper.cisco.com> <5.0.2.1.2.20001219003829.0254bae0@flipper.cisco.com> <5.0.2.1.2.20001219094549.02766080@flipper.cisco.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: diffserv-admin@ietf.org Errors-To: diffserv-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Diffserv Discussion List X-BeenThere: diffserv@ietf.org Content-Transfer-Encoding: 7bit Here are the raw notes from the discussion in San Diego: > MIB issues: > > *** Issue: add separate DSCP counters > (pros, cons on Kwok's slide) > > Open questions > - add DSCP counter table (proposal: no) > - Add counter to ClfgElementTable entry > > 1st question - call for opinions. none strongly in favor, no discussion. > > 2nd question - add counter. call for opinions, scattered support for each, no > loud noises. Proposes to go to list, wait three days for input. > > Brian - please lets put a specific resolution in the documents. > > Walter - worries that in some environments it would be impossible to have > counter in classifier. Thus wants counter to be optional. > > ??? - yes please > > Kwok - OK - pointer in table, reuse counter. > Since then Fred has argued against using pointers, and we certainly don't have consensus on compulsory counters, or on optional coounters. I feel that the only reasonable resolution at this point is to leave it out for future (or proprietary) extension. Brian Fred Baker wrote: > > At 08:42 AM 12/19/00 -0800, Andrew Smith wrote: > >I'd object strongly to this change then - I'd like to see quite a lot more > >support for this idea before declaring WG consensus on this change. Making > >"debug counters" a mandatory part of a MIB like this is not a good way to > >do standards. > > I am, therefore, looking for supporting or negating commentary from the list. > > My reason for not doing "optional", by the way, is historical. > > First, a design guideline we have always followed with SNMP MIBs has been > to avoid optional objects - maybe you provide a read-only and a read-write > implementation option, or you say that a MIB covers several classes of > systems, and if you are doing a system of class A then you need groups {A}, > but that would rarely apply to individual objects. > > Second, a large part of the problem with OSI protocols was the number of > options. Options were used in that design process as a way to gain > consensus - if I don't have to do it, I will be less inclined to vote "no". > However, it very quickly became difficult to come up with a subset of any > given protocol wherein any two vendors were interoperable. This was OSI's > Achilles Heel. That's not where we want to go with IP standards. > > Third, implementing this using a redirection to an optional object, as was > proposed in the working group meeting, has the ills I mentioned in a > previous email. It might make for working group consensus on the basis of > "I don't actually have to implement it", but it makes for an operational > headache beyond interoperability. At the end of the day, we're not building > this for the working group, we're building it for the operators. We need to > give them a usable product. > > Fourth, if something is truly optional, then it is not truly needed, and > another design guideline for SNMP MIBs has always been to leave out that > which is unnecessary. If it is truly optional, then it doesn't belong in > the MIB. > > So, I don't care whether it is in or out. Somebody wanted it and argued for > it, and the working group decided to accept it. I understand, I think, why > they want it, and I buy the argument. If we can pick one - it is needed and > should be in, or it is not needed and should be out - I'm happy. I just > want a product the network operators can use when we're done. > > _______________________________________________ > diffserv mailing list > diffserv@ietf.org > http://www1.ietf.org/mailman/listinfo/diffserv > Archive: http://www2.ietf.org/mail-archive/working-groups/diffserv/current/maillist.html _______________________________________________ diffserv mailing list diffserv@ietf.org http://www1.ietf.org/mailman/listinfo/diffserv Archive: http://www2.ietf.org/mail-archive/working-groups/diffserv/current/maillist.html From diffserv-admin@ietf.org Tue Dec 19 14:36: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 SMTP id OAA22720 for ; Tue, 19 Dec 2000 14:36:09 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id NAA03826; Tue, 19 Dec 2000 13:49:51 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id NAA03797 for ; Tue, 19 Dec 2000 13:49:46 -0500 (EST) Received: from castillo.torrentnet.com (castillo.torrentnet.com [4.18.161.34]) by ietf.org (8.9.1a/8.9.1a) with SMTP id NAA21281 for ; Tue, 19 Dec 2000 13:49:44 -0500 (EST) Received: from castillo.torrentnet.com (localhost.torrentnet.com [127.0.0.1]) by castillo.torrentnet.com (8.9.3/8.9.3) with ESMTP id NAA26020; Tue, 19 Dec 2000 13:49:10 -0500 (EST) Message-Id: <200012191849.NAA26020@castillo.torrentnet.com> X-Mailer: exmh version 2.0.2 2/24/98 To: Fred Baker cc: Andrew Smith , diffserv@ietf.org Subject: Re: [Diffserv] Counters in the classifier In-reply-to: Your message of "Tue, 19 Dec 2000 09:56:21 PST." <5.0.2.1.2.20001219094549.02766080@flipper.cisco.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Tue, 19 Dec 2000 13:49:10 -0500 From: Steve Blake Sender: diffserv-admin@ietf.org Errors-To: diffserv-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Diffserv Discussion List X-BeenThere: diffserv@ietf.org > At 08:42 AM 12/19/00 -0800, Andrew Smith wrote: > >I'd object strongly to this change then - I'd like to see quite a lot more > >support for this idea before declaring WG consensus on this change. Making > >"debug counters" a mandatory part of a MIB like this is not a good way to > >do standards. > > I am, therefore, looking for supporting or negating commentary from the list. I am opposed to adding counters to the classifier. If an implementor wants to instrument their data path in that way, it is already possible using one or more counter actions. Built-in classifier counters would be inconsistent with the prevailing style of the MIB. Regards, =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-= Steven L. Blake Ericsson IP Infrastructure (919)472-9913 _______________________________________________ diffserv mailing list diffserv@ietf.org http://www1.ietf.org/mailman/listinfo/diffserv Archive: http://www2.ietf.org/mail-archive/working-groups/diffserv/current/maillist.html From diffserv-admin@ietf.org Tue Dec 19 14:39:28 2000 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with SMTP id OAA22809 for ; Tue, 19 Dec 2000 14:39:27 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id OAA04542; Tue, 19 Dec 2000 14:13:29 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id OAA04511 for ; Tue, 19 Dec 2000 14:13:24 -0500 (EST) Received: from bor.ellacoya.com (216-064-109-139.inaddr.vitts.com [216.64.109.139]) by ietf.org (8.9.1a/8.9.1a) with SMTP id OAA22039 for ; Tue, 19 Dec 2000 14:13:21 -0500 (EST) Received: by bor.ellacoya.com with Internet Mail Service (5.5.2650.21) id ; Tue, 19 Dec 2000 14:06:20 -0500 Message-ID: From: "Weiss, Walter" To: "'Andrew Smith'" , Fred Baker Cc: diffserv@ietf.org Subject: RE: [Diffserv] Counters in the classifier Date: Tue, 19 Dec 2000 14:06:13 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C069EE.C5842F62" Sender: diffserv-admin@ietf.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_01C069EE.C5842F62 Content-Type: text/plain; charset="iso-8859-1" I have to agree with Andrew here. I have three distinct problems with this proposal. 1. Current implementations may be capable of supporting this new addition to the MIB, but many will not support as many counters as classifier elements. Hence, partial compliance would be interpreted by many implementations to mean available on some classifier elements but not others. This in turn results in an interpretation problem. How does one determine whether the MIB variable means anything or not? This will likely be address in proprietary ways in effect undermining the value of the standard in the first place. This is why I favored either a level of indirection or an additional MIB variable indicating the usage of the counter. 2. While I see the value of the notion of debug-able classifiers, I would point out that the need to debug classifiers have been around long before DiffServ. Hence, I would expect that debugging capabilities for other DiffServ components such as meters, droppers and schedulers can't be far behind. Therefore, something more comprehensive should be considered. 3. Classifiers are one of these key components that are likely to be used in many other contexts beyond DiffServ. Will other datapath configuration oriented protocols define their own version of classifiers or will the DS classifier be applied more broadly? If every WG defines it's own version of a classifier, interoperability between MIBs will become a serious problem. If other WGs start using the DS MIB and expanding it with additional forwarding elements, there are obvious implications on the generality of the existing forwarding elements already defined in the MIB. I realize I am expanding the scope of the MIB beyond DiffServ with this comment, but it is one more reason for me to take a minimalist view for the time being. regards, -Walter > -----Original Message----- > From: Andrew Smith [mailto:andrew@allegronetworks.com] > Sent: Tuesday, December 19, 2000 11:42 AM > To: Fred Baker > Cc: diffserv@ietf.org > Subject: Re: [Diffserv] Counters in the classifier > > > I'd object strongly to this change then - I'd like to see > quite a lot more > support for this idea before declaring WG consensus on this > change. Making > "debug counters" a mandatory part of a MIB like this is not a > good way to do > standards. > > Andrew > > Fred Baker wrote: > > > At 06:32 PM 12/15/00 -0800, Andrew Smith wrote: > > > >> And the intent is for implementation to be optional for RFC > >> conformance/compliance purposes, correct? (of course it > might become > >> mandatory for commercial compliance :-)) > > > > > > Nope. I don't do optional variables. It just means that > many current > > implementations (including some of mine) are not quite compliant. > > > > > > _______________________________________________ > > diffserv mailing list > > diffserv@ietf.org > > http://www1.ietf.org/mailman/listinfo/diffserv > > Archive: > > > http://www2.ietf.org/mail-archive/working-groups/diffserv/curr ent/maillist.html _______________________________________________ diffserv mailing list diffserv@ietf.org http://www1.ietf.org/mailman/listinfo/diffserv Archive: http://www2.ietf.org/mail-archive/working-groups/diffserv/current/maillist.h tml ------_=_NextPart_001_01C069EE.C5842F62 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable RE: [Diffserv] Counters in the classifier

I have to agree with Andrew here. I have three = distinct problems with this proposal.

1. Current implementations may be capable of = supporting this new addition to the MIB, but many will not support as = many counters as classifier elements. Hence, partial compliance would = be interpreted by many implementations to mean available on some = classifier elements but not others. This in turn results in an = interpretation problem. How does one determine whether the MIB variable = means anything or not? This will likely be address in proprietary ways = in effect undermining the value of the standard in the first place. = This is why I favored either a level of indirection or an additional = MIB variable indicating the usage of the counter.

2. While I see the value of the notion of debug-able = classifiers, I would point out that the need to debug classifiers have = been around long before DiffServ. Hence, I would expect that debugging = capabilities for other DiffServ components such as meters, droppers and = schedulers can't be far behind. Therefore, something more comprehensive = should be considered.

3. Classifiers are one of these key components that = are likely to be used in many other contexts beyond DiffServ. Will = other datapath configuration oriented protocols define their own = version of classifiers or will the DS classifier be applied more = broadly? If every WG defines it's own version of a classifier, = interoperability between MIBs will become a serious problem. If other = WGs start using the DS MIB and expanding it with additional forwarding = elements, there are obvious implications on the generality of the = existing forwarding elements already defined in the MIB. I realize I am = expanding the scope of the MIB beyond DiffServ with this comment, but = it is one more reason for me to take a minimalist view for the time = being.

regards,

-Walter

> -----Original Message-----
> From: Andrew Smith [mailto:andrew@allegronetworks= .com]
> Sent: Tuesday, December 19, 2000 11:42 = AM
> To: Fred Baker
> Cc: diffserv@ietf.org
> Subject: Re: [Diffserv] Counters in the = classifier
>
>
> I'd object strongly to this change then - I'd = like to see
> quite a lot more
> support for this idea before declaring WG = consensus on this
> change. Making
> "debug counters" a mandatory part of = a MIB like this is not a
> good way to do
> standards.
>
> Andrew
>
> Fred Baker wrote:
>
> > At 06:32 PM 12/15/00 -0800, Andrew Smith = wrote:
> >
> >> And the intent is for implementation = to be optional for RFC
> >> conformance/compliance purposes, = correct? (of course it
> might become
> >> mandatory for commercial compliance :-)= )
> >
> >
> > Nope. I don't do optional variables. It = just means that
> many current
> > implementations (including some of mine) = are not quite compliant.
> >
> >
> > = _______________________________________________
> > diffserv mailing list
> > diffserv@ietf.org
> > http://www1.ietf.org/mailman/listinfo/diffserv
> > Archive:
> >
> http://www2.ietf.org/mail-archive/working-groups/diffs= erv/curr
ent/maillist.html


_______________________________________________
diffserv mailing list
diffserv@ietf.org
http://www1.ietf.org/mailman/listinfo/diffserv
Archive: http://www2.ietf.org/mail-archive/working-groups/diffs= erv/current/maillist.html

------_=_NextPart_001_01C069EE.C5842F62-- _______________________________________________ diffserv mailing list diffserv@ietf.org http://www1.ietf.org/mailman/listinfo/diffserv Archive: http://www2.ietf.org/mail-archive/working-groups/diffserv/current/maillist.html From diffserv-admin@ietf.org Tue Dec 19 16:41: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 SMTP id QAA25641 for ; Tue, 19 Dec 2000 16:41:14 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id QAA07227; Tue, 19 Dec 2000 16:11:53 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id QAA07134 for ; Tue, 19 Dec 2000 16:11:47 -0500 (EST) Received: from mailhub1.almaden.ibm.com (mailhub1.almaden.ibm.com [198.4.83.44]) by ietf.org (8.9.1a/8.9.1a) with SMTP id QAA25018 for ; Tue, 19 Dec 2000 16:11:43 -0500 (EST) Received: from maui.almaden.ibm.com (maui.almaden.ibm.com [9.1.24.92]) by mailhub1.almaden.ibm.com (8.8.8/8.8.8) with ESMTP id NAA45174 for ; Tue, 19 Dec 2000 13:06:29 -0800 Received: from hursley.ibm.com (gsine03.us.sine.ibm.com [9.14.6.43]) by maui.almaden.ibm.com (AIX4.3/8.9.3/8.7) with ESMTP id NAA22362 for ; Tue, 19 Dec 2000 13:11:14 -0800 Message-ID: <3A3FCD6F.4AE3007C@hursley.ibm.com> Date: Tue, 19 Dec 2000 15:04:47 -0600 From: Brian E Carpenter Organization: IBM X-Mailer: Mozilla 4.61 [en] (Win98; I) X-Accept-Language: en,fr MIME-Version: 1.0 To: Diff Serv Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Subject: [Diffserv] What we missed in San Diego Sender: diffserv-admin@ietf.org Errors-To: diffserv-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Diffserv Discussion List X-BeenThere: diffserv@ietf.org Content-Transfer-Encoding: 7bit We'd expected to have a few minutes at the end of the first diffserv session in San Diego for several people who wished to draw drafts to the attention of the WG as an FYI. However, we ran out of time so this didn't happen. Anybody who has such a draft, please send a brief note to the list, with the draft name or URL. The game plan right now is to get the MIB and the informal model finished (currently running 5 months late), then the PIB (4 months late), the PDB description (4 months late), the new EF document, and any pending informationals all done in the next 3 months. Brian _______________________________________________ diffserv mailing list diffserv@ietf.org http://www1.ietf.org/mailman/listinfo/diffserv Archive: http://www2.ietf.org/mail-archive/working-groups/diffserv/current/maillist.html From diffserv-admin@ietf.org Tue Dec 19 21:37: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 SMTP id VAA01260 for ; Tue, 19 Dec 2000 21:37:03 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id VAA10507; Tue, 19 Dec 2000 21:08:59 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id VAA10479 for ; Tue, 19 Dec 2000 21:08:50 -0500 (EST) Received: from sj-msg-core-2.cisco.com (sj-msg-core-2.cisco.com [171.69.43.88]) by ietf.org (8.9.1a/8.9.1a) with SMTP id VAA29863 for ; Tue, 19 Dec 2000 21:08:47 -0500 (EST) Received: from p7020-img-nt.cisco.com (dhcp-10-34-54-158.cisco.com [10.34.54.158]) by sj-msg-core-2.cisco.com (8.9.3/8.9.1) with ESMTP id SAA24954; Tue, 19 Dec 2000 18:08:19 -0800 (PST) Message-Id: <5.0.2.1.2.20001219174916.03a8c020@flipper.cisco.com> X-Sender: fred@flipper.cisco.com X-Mailer: QUALCOMM Windows Eudora Version 5.0.2 Date: Tue, 19 Dec 2000 17:49:24 -0800 To: Brian E Carpenter From: Fred Baker Subject: Re: [Diffserv] Counters in the classifier Cc: Andrew Smith , diffserv@ietf.org In-Reply-To: <3A3FB0DC.5089B47E@hursley.ibm.com> References: <5.0.2.1.2.20001213100135.0308d050@flipper.cisco.com> <3A37F797.F49575E6@packetdesign.com> <5.0.2.1.2.20001214122954.02508dd0@flipper.cisco.com> <5.0.2.1.2.20001219003829.0254bae0@flipper.cisco.com> <5.0.2.1.2.20001219094549.02766080@flipper.cisco.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: diffserv-admin@ietf.org Errors-To: diffserv-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Diffserv Discussion List X-BeenThere: diffserv@ietf.org At 01:02 PM 12/19/00 -0600, Brian E Carpenter wrote: >Since then Fred has argued against using pointers, and we certainly don't have >consensus on compulsory counters, or on optional coounters. I feel that the >only reasonable resolution at this point is to leave it out for future (or >proprietary) extension. works for me _______________________________________________ diffserv mailing list diffserv@ietf.org http://www1.ietf.org/mailman/listinfo/diffserv Archive: http://www2.ietf.org/mail-archive/working-groups/diffserv/current/maillist.html From diffserv-admin@ietf.org Wed Dec 20 09:48: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 SMTP id JAA26676 for ; Wed, 20 Dec 2000 09:48:33 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id JAA23082; Wed, 20 Dec 2000 09:11:19 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id JAA23052 for ; Wed, 20 Dec 2000 09:11:14 -0500 (EST) Received: from usc.edu (root@usc.edu [128.125.253.136]) by ietf.org (8.9.1a/8.9.1a) with SMTP id JAA25024 for ; Wed, 20 Dec 2000 09:11:13 -0500 (EST) Received: from aludra.usc.edu (demir@aludra.usc.edu [128.125.253.184]) by usc.edu (8.9.3.1/8.9.3/usc) with ESMTP id GAA20613; Wed, 20 Dec 2000 06:11:14 -0800 (PST) Received: from localhost (demir@localhost) by aludra.usc.edu (8.9.3.1/8.9.3/usc) with ESMTP id GAA26681; Wed, 20 Dec 2000 06:11:13 -0800 (PST) Date: Wed, 20 Dec 2000 06:11:13 -0800 (PST) From: demir To: "Casati, Alessio (Alessio)" cc: diffserv@ietf.org Subject: RE: [Diffserv] RE: Yesterday's EF discussion In-Reply-To: <976F7C55E3B2D111A0720008C728549C04877646@en0060exch001u.uk.lucent.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 Alessio, > The way this is possible is via PHB that allows > aggregation of a number of customer networks > in a way that they do not affect one another. > This is possible via a PHB > that provides strict guarantees in terms > of delay variation across a hop. > This is the only way that allows aggregation > without uncontrolled burst accumulation, > that would result in the service not being delivered > end to end to the customer network > asking for a "virtual wire". A PHB should not be intended for a specific PDB or what so ever. What is the use of PHB-PDB layering? If what EF PHB is intended for is "VW" then rename it as EF PDB" based on "NO PHB". "Burst accumulation" is result of the "traffic" coming from "edge". The question is "if it is "appropriate "to control burst accumulation on a PHB". The answer is obvious. Accepting "inefficient ways" is another "issue". I see mixture of different "concepts" in above statements. Are you talking about a PHB, PDB, service, or combined all together? > So, back to our issue, the per hop guarantee is a delay > variation guarantee. Whether that is achieved via a color > aware configured rate, priority Queuing with non > EF traffic starvation protection, this is entirely > dependent on the router instance selected by the operator. > There are a lot of other knobs that may be used to deliver a > delay variation bound, and it would not be wise to specify > all of them. To me, "delay variation" is not a per hop gurantee. However, if a "PHB" wants to support that guarantee, it has to learn whether it is allowed to keep "state" or not. If it does, there is no problem. If it doesn't, then it should learn if it is allowed to achieve it "efficiently". If it does, there is no problem. If it doesn't, "good-bye". Delay variation is "by-product" of "configured-rate" or "priority queuing" and "EF traffic starvation protection" is not "enough" to achieve it. "Scheduling" should also be controled. "Delay-variation" guarantee is a good thing. However, it requires very "fine-granularities". Where and how is another "issue". > So, output Rate is one of the knobs to achieve the per hop delay > variation guarantee, if we like. But not what should > be used to describe the PHB. > By the way, it is clear that low per hop fixed delay > values are desirable, but the virtual wire per se does > not specify a universally acceptable delay value > (that is, the length of the virtual wire is not going to be > mandated by the standard:). These are the "statements" I have made above and during the "EF" discussions as you made here. If something is worth having (desirable), then everybody who are willing to pay for it wants to have it. The question is "if it is worth supporting on a PHB". What is "low per hop fixed delay"? D(i) = 0.0 is very good to me. I can achieve this if one is willing not to receive any packet. I assume "delay guarantee" is desirable comming along with "packet loss rate". "Delay guarantee" has to deal with similar things as "delay variance guarantee". Alper K. Demir _______________________________________________ diffserv mailing list diffserv@ietf.org http://www1.ietf.org/mailman/listinfo/diffserv Archive: http://www2.ietf.org/mail-archive/working-groups/diffserv/current/maillist.html From diffserv-admin@ietf.org Wed Dec 20 10:08: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 SMTP id KAA27602 for ; Wed, 20 Dec 2000 10:08:29 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id JAA23442; Wed, 20 Dec 2000 09:33:22 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id JAA23415 for ; Wed, 20 Dec 2000 09:33:18 -0500 (EST) Received: from usc.edu (root@usc.edu [128.125.253.136]) by ietf.org (8.9.1a/8.9.1a) with SMTP id JAA25894 for ; Wed, 20 Dec 2000 09:33:17 -0500 (EST) Received: from aludra.usc.edu (demir@aludra.usc.edu [128.125.253.184]) by usc.edu (8.9.3.1/8.9.3/usc) with ESMTP id GAA29329; Wed, 20 Dec 2000 06:33:17 -0800 (PST) Received: from localhost (demir@localhost) by aludra.usc.edu (8.9.3.1/8.9.3/usc) with ESMTP id GAA28730; Wed, 20 Dec 2000 06:33:16 -0800 (PST) Date: Wed, 20 Dec 2000 06:33:16 -0800 (PST) From: demir To: Jon Bennett cc: diffserv@ietf.org Subject: RE: [Diffserv] RE: Yesterday's EF discussion In-Reply-To: <7F4AC78738EAD2119D86009027626C6D889037@packetbdc.riverdelta.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 Jon, > I fail to see where in part 1) it mentions any concept of what the EF PHB is > other that a RATE guarantee. The lack of jitter accumulation is a result of > the second part, which as I said before falls to the network level controls > and is therefore the property one might find in a PDB but not in a PHB, > which is why we decided not to put it in the PHB, because it does not belong > there. The lack of "delay bound" is also a result of the second part. It falls into the network level controls if it is wanted to be achieved "efficiently". According to your above statement, does "delay bound" belong there? Alper K. Demir _______________________________________________ diffserv mailing list diffserv@ietf.org http://www1.ietf.org/mailman/listinfo/diffserv Archive: http://www2.ietf.org/mail-archive/working-groups/diffserv/current/maillist.html From diffserv-admin@ietf.org Wed Dec 20 11:18: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 SMTP id LAA01197 for ; Wed, 20 Dec 2000 11:18:28 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id KAA24574; Wed, 20 Dec 2000 10:47:09 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id KAA24543 for ; Wed, 20 Dec 2000 10:47:05 -0500 (EST) Received: from dxcnaf.cnaf.infn.it (dxcnaf.cnaf.infn.it [131.154.3.1]) by ietf.org (8.9.1a/8.9.1a) with SMTP id KAA29468 for ; Wed, 20 Dec 2000 10:47:02 -0500 (EST) Received: from localhost (ferrari@localhost) by dxcnaf.cnaf.infn.it (8.8.8/8.8.8) with SMTP id QAA08233 for ; Wed, 20 Dec 2000 16:47:18 +0100 (MET) Date: Wed, 20 Dec 2000 16:47:17 +0100 (MET) From: Tiziana Ferrari To: diffserv@ietf.org Subject: Re: What's in a name? Re: [Diffserv] Yesterday's EF discussion In-Reply-To: <4.1.20001219090435.020ff5c0@icamail1.epfl.ch> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: diffserv-admin@ietf.org Errors-To: diffserv-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Diffserv Discussion List X-BeenThere: diffserv@ietf.org I didn't make it for the 19th - I was away for a business trip - but I would like to vote for keeping the name "EF". Tiziana On Tue, 19 Dec 2000, Jean-Yves Le Boudec wrote: > I vote for keeping the old name EF. The industry has started working with > that name, and we shoudl keep it. > > JY > > > At 14.12.2000, Bora Akyol wrote: > >Having a second name effectively allows two PHBs. This was NOT the > >consensus in the meeting. > > > >Bora > > > > > >At 10:50 PM 12/13/2000, Grenville Armitage wrote: > > > > > >>Brian E Carpenter wrote: > >> [..] > >> > What should the name of the PHB be? > >> > Chair's proposal: Defined Rate (DR). I believe that after this long > >> > and confusing discussion, it would be wise to retire the previous > >> name. > >> > >>Brian, I think this suggestion is a good one. Clearly there are differing > >>opinions over what RFC2598 intended. I watched from the rear of the room > >>yesterday. I too saw a crowd sentiment broadly in favor of > >>draft-charny(modified) as the WG PHB to support VW and similar services. > >>But given the fact that "EF" has been differently interpreted by a number > >>of relatively intelligent people, I cannot see the value in anyone being > >>'damn right' about owning the EF name from this point onwards. The WG needs > >>a standards track PHB believed to support VW, etc, services....the name > >>"Defined Rate" captures the rough consensus towards the rate-based > >>interpretation of RFC2598. > >> > >>cheers, > >>gja (not, it must be noted, speaking of behalf of EFRESOLVE) > >> > >>_______________________________________________ > >>diffserv mailing list > >>diffserv@ietf.org > >>http://www1.ietf.org/mailman/listinfo/diffserv > >>Archive: > >>http://www2.ietf.org/mail-archive/working-groups/diffserv/current/maillist. > >html > >> > > > >Bora Akyol > >Pluris > >akyol@pluris.com > > > > > >_______________________________________________ > >diffserv mailing list > >diffserv@ietf.org > >http://www1.ietf.org/mailman/listinfo/diffserv > >Archive: > >http://www2.ietf.org/mail-archive/working-groups/diffserv/current/maillist. > html > > > > > _______________________________________________ > diffserv mailing list > diffserv@ietf.org > http://www1.ietf.org/mailman/listinfo/diffserv > Archive: http://www2.ietf.org/mail-archive/working-groups/diffserv/current/maillist.html > ***************************************************************************** Tiziana Ferrari http://www.cnaf.infn.it/~ferrari Italian National Inst. for Nuclear Physics / CNAF v.le Berti Pichat 6/2, 40127 BOLOGNA, ITALY tel: +39.051.6092.759 fax:+39.051.6092.746 ***************************************************************************** _______________________________________________ diffserv mailing list diffserv@ietf.org http://www1.ietf.org/mailman/listinfo/diffserv Archive: http://www2.ietf.org/mail-archive/working-groups/diffserv/current/maillist.html From diffserv-admin@ietf.org Wed Dec 20 18:08: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 SMTP id SAA18901 for ; Wed, 20 Dec 2000 18:08:56 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id RAA29224; Wed, 20 Dec 2000 17:26:09 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id RAA29194 for ; Wed, 20 Dec 2000 17:26:05 -0500 (EST) Received: from usc.edu (root@usc.edu [128.125.253.136]) by ietf.org (8.9.1a/8.9.1a) with SMTP id RAA17735 for ; Wed, 20 Dec 2000 17:26:02 -0500 (EST) Received: from aludra.usc.edu (demir@aludra.usc.edu [128.125.253.184]) by usc.edu (8.9.3.1/8.9.3/usc) with ESMTP id OAA09550; Wed, 20 Dec 2000 14:26:03 -0800 (PST) Received: from localhost (demir@localhost) by aludra.usc.edu (8.9.3.1/8.9.3/usc) with ESMTP id OAA07382; Wed, 20 Dec 2000 14:26:02 -0800 (PST) Date: Wed, 20 Dec 2000 14:26:02 -0800 (PST) From: demir To: Brian E Carpenter cc: "Diffserv@Ietf. Org" Subject: Re: [Diffserv] Yesterday's EF discussion In-Reply-To: <3A3E8E1F.2DFEF275@hursley.ibm.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: diffserv-admin@ietf.org Errors-To: diffserv-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Diffserv Discussion List X-BeenThere: diffserv@ietf.org Brian, Obviously, there is a WG consensus on keeping the EF name. I am completely disagree with this consensus (I have the feeling that you will tell me to deal with it. I am :) Now, charny-et-al-compromise specification is on the way to replace EF. However, to me, it is not "righ way". I am "VERY" unable to see what it is that RFC-2598 is missing as a PHB. I have made that statement before. Oh I see. "low loss", "low latency", "low jitter" is very "relative" and not "precise". How far a PHB can go other than saying "low". RFC-2598 has an obvious reasoning for this: "loss, latency and jitter are all due to the traffic experiences while transiting network". I thought a PHB should have a "consistent-reasoning" about expected "aggregate bahaviors". RFC-2598 has a very "consistent-reasoning: "we show the generality of this PHB by noting that it can be produced by more than one mechanism and give an example of its use to produce at least one service, a virtual leased line". I am "VERY" unable to see a "consistent-reasoning" on charny-et-al-compromise (I have the sense that you will tell me to wait for the draft or try harder to see it. I disagree cause the "general idea" is clear to me). Is the problem that to make RFC-2598 more "precise" by giving an "approximate" formula on "delay bound" and a "specific" algorithm on "well-defined rate"? This might create a big "misunderstanding" and wrong "consistent-reasoning". "loss", "delay" and "jitter" are all related to mechanisms underneath and how network traffic control is achieved ("traffic conditioners"). With support of network traffic control and "appropriate" scheduling mechanisms, delay depends on "burstiness" allowed. So does "loss" and "jitter". In addition to this, "loss" depends on "queue management" and "jitter" requires individual flow "state". Providing "bound" on one of these will affect the others (loss, delay, jitter). It doesn't seem reasonable to me that a PHB is having a "risk" of all these problems. What is the next step will be if "current EF" fails to achieve the "goal"? I guess, "jitter' didn't work, "delay" failed, let's deal with "loss" :) I assume if we put alot of "burden" on a PHB it will be a very "smart PHB". We know that doesn't scale. RFC-2598 has a way of dealing with it: "well-defined rate" where a PHB can be "smart" about. Diffserv has a way of being smart about "diffserv domain" related "issues": PDB. May be, what EF is missing is to elaborate on this. It seems it is okay for a PHB to "approximate" to "worst-case delay bound" by Diffserv WG (previously "delay variance bound". I am sorry to say that the behavior of the hop (EF) has changed. Now, it is approximating to bound "delay" with a "specific" algorithm where it is not related to "worst-case delay bound" which requires "state" for individual flows or some assumptions. I don't see any problem with RFC-2598 other than, may be, some elaboration. There are 8 (eight) choices to bound "something" (loss, delay, jitter) if a PHB is willing to take some "risks" on "consistent-reasoning"; each having a different behavior and the most general way to express this is that something is *always* less than something. How things are done is details and it is wrong to specify a detail unless it is universally accepted. My 2 cents, Alper K. Demir On Mon, 18 Dec 2000, Brian E Carpenter wrote: > The current question is whether the charny-et-al-compromise specification > is going to be called EF. [If not, let the games commence :-] > > Brian > > "Manfredi, Albert E" wrote: > > > > Brian E Carpenter: > > > > > Bruce, the reason I chose to put the naming question to the list is > > > that the naming issue was very far from explicit in the discussion > > > on Tuesday, and there wasn't time to make it explicit. > > > > > > My intention is to close off the naming discussion tomorrow > > > December 19, > > > and state what I see as the rough consensus. > > > > Sorry I didn't commit to memory all of the suggestions, but did anyone > > recomment something like, say, Guaranteed Frame Rate (GFR)? :)) > > > > Dunno, I just pulled that one out of the air. > > > > Bert > > _______________________________________________ > diffserv mailing list > diffserv@ietf.org > http://www1.ietf.org/mailman/listinfo/diffserv > Archive: http://www2.ietf.org/mail-archive/working-groups/diffserv/current/maillist.html > _______________________________________________ diffserv mailing list diffserv@ietf.org http://www1.ietf.org/mailman/listinfo/diffserv Archive: http://www2.ietf.org/mail-archive/working-groups/diffserv/current/maillist.html From diffserv-admin@ietf.org Wed Dec 20 18:11: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 SMTP id SAA19004 for ; Wed, 20 Dec 2000 18:11:56 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id RAA29293; Wed, 20 Dec 2000 17:30:03 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id RAA29243 for ; Wed, 20 Dec 2000 17:29:59 -0500 (EST) Received: from hotmail.com (f162.law4.hotmail.com [216.33.149.162]) by ietf.org (8.9.1a/8.9.1a) with SMTP id RAA17841 for ; Wed, 20 Dec 2000 17:29:57 -0500 (EST) Received: from mail pickup service by hotmail.com with Microsoft SMTPSVC; Wed, 20 Dec 2000 14:29:28 -0800 Received: from 208.248.148.132 by lw4fd.law4.hotmail.msn.com with HTTP; Wed, 20 Dec 2000 22:29:28 GMT X-Originating-IP: [208.248.148.132] From: "Grace Kou" To: diffserv@ietf.org Date: Wed, 20 Dec 2000 22:29:28 Mime-Version: 1.0 Content-Type: text/plain; format=flowed Message-ID: X-OriginalArrivalTime: 20 Dec 2000 22:29:28.0582 (UTC) FILETIME=[50B1E260:01C06AD4] Subject: [Diffserv] basic doubts about 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 Hi, I am studying Diffserv (from a service provider's perspective) and have some basic questions. I would like to know what are the typical services (or any real-world examples) to be supported by EF and AF PHBs? If EF is targeted for typically low-delay and low jitter, real-time, applications, then what kind of services are the "better-than-best-effort" AF PHBs targeting? With these PHBs, in particular AF PHBs, as loosely defined as they are now, how is a service provider supposed to construct services with QoS over a heterogeneous network that supports these "building blocks", which may come from different vendors and look and implemented very differently? Suppose my SLS is defined by a 3-tuple: . How am I supposed to create a service based on this 3-tuple using Diffserv "building blocks" if I don't even know what AF1, AF2, AF3, and AF4 are? If I have to individually tune the parameters of meters, the schedulers and the like on a per-hop basis along the path to ensure my SLS is met, then what is the need for all these PHB's any way? As far as I am concerned, AF PHBs are only useful intra domain for, perhaps, creating a PDB. Thank you. - G. Kou _________________________________________________________________ Get your FREE download of MSN Explorer at http://explorer.msn.com _______________________________________________ diffserv mailing list diffserv@ietf.org http://www1.ietf.org/mailman/listinfo/diffserv Archive: http://www2.ietf.org/mail-archive/working-groups/diffserv/current/maillist.html From diffserv-admin@ietf.org Wed Dec 20 18:57: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 SMTP id SAA19967 for ; Wed, 20 Dec 2000 18:57:45 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id SAA00128; Wed, 20 Dec 2000 18:27:33 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id SAA00097 for ; Wed, 20 Dec 2000 18:27:29 -0500 (EST) Received: from mailhub1.almaden.ibm.com (mailhub1.almaden.ibm.com [198.4.83.44]) by ietf.org (8.9.1a/8.9.1a) with SMTP id SAA19353 for ; Wed, 20 Dec 2000 18:27:26 -0500 (EST) Received: from maui.almaden.ibm.com (maui.almaden.ibm.com [9.1.24.92]) by mailhub1.almaden.ibm.com (8.8.8/8.8.8) with ESMTP id PAA38036; Wed, 20 Dec 2000 15:21:52 -0800 Received: from hursley.ibm.com (gsine04.us.sine.ibm.com [9.14.6.44]) by maui.almaden.ibm.com (AIX4.3/8.9.3/8.7) with ESMTP id PAA32264; Wed, 20 Dec 2000 15:26:58 -0800 Message-ID: <3A413F74.BCAACBC@hursley.ibm.com> Date: Wed, 20 Dec 2000 17:23:32 -0600 From: Brian E Carpenter Organization: IBM X-Mailer: Mozilla 4.61 [en] (Win98; I) X-Accept-Language: en,fr MIME-Version: 1.0 To: demir CC: "Diffserv@Ietf. Org" Subject: Re: [Diffserv] Yesterday's EF discussion References: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: diffserv-admin@ietf.org Errors-To: diffserv-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Diffserv Discussion List X-BeenThere: diffserv@ietf.org Content-Transfer-Encoding: 7bit Demir, You are in the dissenting minority. As I said yesterday, let's wait for the new PHB draft to see if we still have a rough consensus. Brian demir wrote: > > Brian, > Obviously, there is a WG consensus on keeping the EF name. I am completely > disagree with this consensus (I have the feeling that you will tell me to > deal with it. I am :) Now, charny-et-al-compromise specification is on the > way to replace EF. However, to me, it is not "righ way". I am > "VERY" unable to see what it is that RFC-2598 is missing as a PHB. I have > made that statement before. Oh I see. "low loss", "low latency", "low > jitter" is very "relative" and not "precise". How far a PHB can go > other than saying "low". RFC-2598 has an obvious reasoning for > this: "loss, latency and jitter are all due to the traffic experiences > while transiting network". I thought a PHB should have a > "consistent-reasoning" about expected "aggregate bahaviors". RFC-2598 has > a very "consistent-reasoning: "we show the generality of this PHB by > noting that it can be produced by more than one mechanism and give an > example of its use to produce at least one service, a virtual leased > line". I am "VERY" unable to see a "consistent-reasoning" on > charny-et-al-compromise (I have the sense that you will tell me to wait > for the draft or try harder to see it. I disagree cause the "general > idea" is clear to me). Is the problem that to make RFC-2598 more > "precise" by giving an "approximate" formula on "delay bound" and a > "specific" algorithm on "well-defined rate"? This might create a big > "misunderstanding" and wrong "consistent-reasoning". "loss", "delay" and > "jitter" are all related to mechanisms underneath and how network traffic > control is achieved ("traffic conditioners"). With support of network > traffic control and "appropriate" scheduling mechanisms, delay depends on > "burstiness" allowed. So does "loss" and "jitter". In addition to this, > "loss" depends on "queue management" and "jitter" requires individual flow > "state". Providing "bound" on one of these will affect the others (loss, > delay, jitter). It doesn't seem reasonable to me that a PHB is having a > "risk" of all these problems. What is the next step will be if "current > EF" fails to achieve the "goal"? I guess, "jitter' didn't work, > "delay" failed, let's deal with "loss" :) I assume if we put alot of > "burden" on a PHB it will be a very "smart PHB". We know that doesn't > scale. RFC-2598 has a way of dealing with it: "well-defined rate" where a > PHB can be "smart" about. Diffserv has a way of being smart about > "diffserv domain" related "issues": PDB. May be, what EF is missing is to > elaborate on this. It seems it is okay for a PHB to "approximate" to > "worst-case delay bound" by Diffserv WG (previously "delay variance > bound". I am sorry to say that the behavior of the hop (EF) has > changed. Now, it is approximating to bound "delay" with a > "specific" algorithm where it is not related to "worst-case delay > bound" which requires "state" for individual flows or some assumptions. I > don't see any problem with RFC-2598 other than, may be, some > elaboration. There are 8 (eight) choices to bound "something" (loss, > delay, jitter) if a PHB is willing to take some "risks" on > "consistent-reasoning"; each having a different behavior and the most > general way to express this is that something is *always* less than > something. How things are done is details and it is wrong to specify a > detail unless it is universally accepted. > > My 2 cents, > > Alper K. Demir > > On Mon, 18 Dec 2000, Brian E Carpenter wrote: > > > The current question is whether the charny-et-al-compromise specification > > is going to be called EF. [If not, let the games commence :-] > > > > Brian > > > > "Manfredi, Albert E" wrote: > > > > > > Brian E Carpenter: > > > > > > > Bruce, the reason I chose to put the naming question to the list is > > > > that the naming issue was very far from explicit in the discussion > > > > on Tuesday, and there wasn't time to make it explicit. > > > > > > > > My intention is to close off the naming discussion tomorrow > > > > December 19, > > > > and state what I see as the rough consensus. > > > > > > Sorry I didn't commit to memory all of the suggestions, but did anyone > > > recomment something like, say, Guaranteed Frame Rate (GFR)? :)) > > > > > > Dunno, I just pulled that one out of the air. > > > > > > Bert > > > > _______________________________________________ > > diffserv mailing list > > diffserv@ietf.org > > http://www1.ietf.org/mailman/listinfo/diffserv > > Archive: http://www2.ietf.org/mail-archive/working-groups/diffserv/current/maillist.html > > > > _______________________________________________ > diffserv mailing list > diffserv@ietf.org > http://www1.ietf.org/mailman/listinfo/diffserv > Archive: http://www2.ietf.org/mail-archive/working-groups/diffserv/current/maillist.html _______________________________________________ diffserv mailing list diffserv@ietf.org http://www1.ietf.org/mailman/listinfo/diffserv Archive: http://www2.ietf.org/mail-archive/working-groups/diffserv/current/maillist.html From diffserv-admin@ietf.org Wed Dec 20 19:08:32 2000 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with SMTP id TAA20238 for ; Wed, 20 Dec 2000 19:08:31 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id SAA00410; Wed, 20 Dec 2000 18:35:56 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id SAA00378 for ; Wed, 20 Dec 2000 18:35:52 -0500 (EST) Received: from mailhub1.almaden.ibm.com (mailhub1.almaden.ibm.com [198.4.83.44]) by ietf.org (8.9.1a/8.9.1a) with SMTP id SAA19510 for ; Wed, 20 Dec 2000 18:35:49 -0500 (EST) Received: from maui.almaden.ibm.com (maui.almaden.ibm.com [9.1.24.92]) by mailhub1.almaden.ibm.com (8.8.8/8.8.8) with ESMTP id PAA43098; Wed, 20 Dec 2000 15:30:15 -0800 Received: from hursley.ibm.com (gsine04.us.sine.ibm.com [9.14.6.44]) by maui.almaden.ibm.com (AIX4.3/8.9.3/8.7) with ESMTP id PAA22394; Wed, 20 Dec 2000 15:35:20 -0800 Message-ID: <3A414168.5B0547D2@hursley.ibm.com> Date: Wed, 20 Dec 2000 17:31:52 -0600 From: Brian E Carpenter Organization: IBM X-Mailer: Mozilla 4.61 [en] (Win98; I) X-Accept-Language: en,fr MIME-Version: 1.0 To: Grace Kou CC: diffserv@ietf.org Subject: Re: [Diffserv] basic doubts about PHBs 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 Grace, The AF proponents have not yet attempted to publish PDB (per-domain behavior) definitions based on AF, so I don't think we have an answer to your question for AF. For EF, despite all the recent debate, we do have a generic view that something like Virtual Wire is the right type of PDB, and that is work in progress. For purely practical discussion on this I'd suggest the diffserv implementation list. But if anyone wants to draft a PDB based on AF, now is the time to do so. Brian Grace Kou wrote: > > Hi, > > I am studying Diffserv (from a service provider's perspective) > and have some basic questions. I would like to know what are the > typical services (or any real-world examples) to be supported by EF > and AF PHBs? If EF is targeted for typically low-delay and low > jitter, real-time, applications, then what kind of services are > the "better-than-best-effort" AF PHBs targeting? With these PHBs, > in particular AF PHBs, as loosely defined as they are now, how is a > service provider supposed to construct services with QoS over a > heterogeneous network that supports these "building blocks", which > may come from different vendors and look and implemented very differently? > Suppose my SLS is defined by a 3-tuple: > . How am I supposed to > create a service based on this 3-tuple using Diffserv "building > blocks" if I don't even know what AF1, AF2, AF3, and AF4 are? > If I have to individually tune the parameters of meters, the schedulers > and the like on a per-hop basis along the path to ensure my SLS is met, > then what is the need for all these PHB's any way? As far as I am > concerned, AF PHBs are only useful intra domain for, perhaps, creating > a PDB. > > Thank you. > > - G. Kou > _________________________________________________________________ > Get your FREE download of MSN Explorer at http://explorer.msn.com > > _______________________________________________ > diffserv mailing list > diffserv@ietf.org > http://www1.ietf.org/mailman/listinfo/diffserv > Archive: http://www2.ietf.org/mail-archive/working-groups/diffserv/current/maillist.html -- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - Brian E Carpenter Program Director, Internet Standards & Technology, IBM On assignment for IBM at http://www.iCAIR.org Board Chairman, Internet Society http://www.isoc.org Non-IBM email: brian@icair.org _______________________________________________ diffserv mailing list diffserv@ietf.org http://www1.ietf.org/mailman/listinfo/diffserv Archive: http://www2.ietf.org/mail-archive/working-groups/diffserv/current/maillist.html From diffserv-admin@ietf.org Wed Dec 20 20:35: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 SMTP id UAA21377 for ; Wed, 20 Dec 2000 20:35:16 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id TAA01276; Wed, 20 Dec 2000 19:54:11 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id TAA01245 for ; Wed, 20 Dec 2000 19:54:07 -0500 (EST) Received: from usc.edu (root@usc.edu [128.125.253.136]) by ietf.org (8.9.1a/8.9.1a) with SMTP id TAA20761 for ; Wed, 20 Dec 2000 19:54:06 -0500 (EST) Received: from aludra.usc.edu (demir@aludra.usc.edu [128.125.253.184]) by usc.edu (8.9.3.1/8.9.3/usc) with ESMTP id QAA19176; Wed, 20 Dec 2000 16:54:06 -0800 (PST) Received: from localhost (demir@localhost) by aludra.usc.edu (8.9.3.1/8.9.3/usc) with ESMTP id QAA27980; Wed, 20 Dec 2000 16:54:05 -0800 (PST) Date: Wed, 20 Dec 2000 16:54:05 -0800 (PST) From: demir To: Brian E Carpenter cc: "Diffserv@Ietf. Org" Subject: Re: [Diffserv] Yesterday's EF discussion In-Reply-To: <3A413F74.BCAACBC@hursley.ibm.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: diffserv-admin@ietf.org Errors-To: diffserv-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Diffserv Discussion List X-BeenThere: diffserv@ietf.org Brian, I don't see myself in the dissenting minority. I don't have any problem with "accepting!" consensus. I am in the "accepting!" minority :) I only "speculated" on a "end-to-end argument" related to current PHB discussion. Alper K. Demir On Wed, 20 Dec 2000, Brian E Carpenter wrote: > Demir, > > You are in the dissenting minority. As I said yesterday, let's > wait for the new PHB draft to see if we still have a rough consensus. > > Brian > > demir wrote: > > > > Brian, > > Obviously, there is a WG consensus on keeping the EF name. I am completely > > disagree with this consensus (I have the feeling that you will tell me to > > deal with it. I am :) Now, charny-et-al-compromise specification is on the > > way to replace EF. However, to me, it is not "righ way". I am > > "VERY" unable to see what it is that RFC-2598 is missing as a PHB. I have > > made that statement before. Oh I see. "low loss", "low latency", "low > > jitter" is very "relative" and not "precise". How far a PHB can go > > other than saying "low". RFC-2598 has an obvious reasoning for > > this: "loss, latency and jitter are all due to the traffic experiences > > while transiting network". I thought a PHB should have a > > "consistent-reasoning" about expected "aggregate bahaviors". RFC-2598 has > > a very "consistent-reasoning: "we show the generality of this PHB by > > noting that it can be produced by more than one mechanism and give an > > example of its use to produce at least one service, a virtual leased > > line". I am "VERY" unable to see a "consistent-reasoning" on > > charny-et-al-compromise (I have the sense that you will tell me to wait > > for the draft or try harder to see it. I disagree cause the "general > > idea" is clear to me). Is the problem that to make RFC-2598 more > > "precise" by giving an "approximate" formula on "delay bound" and a > > "specific" algorithm on "well-defined rate"? This might create a big > > "misunderstanding" and wrong "consistent-reasoning". "loss", "delay" and > > "jitter" are all related to mechanisms underneath and how network traffic > > control is achieved ("traffic conditioners"). With support of network > > traffic control and "appropriate" scheduling mechanisms, delay depends on > > "burstiness" allowed. So does "loss" and "jitter". In addition to this, > > "loss" depends on "queue management" and "jitter" requires individual flow > > "state". Providing "bound" on one of these will affect the others (loss, > > delay, jitter). It doesn't seem reasonable to me that a PHB is having a > > "risk" of all these problems. What is the next step will be if "current > > EF" fails to achieve the "goal"? I guess, "jitter' didn't work, > > "delay" failed, let's deal with "loss" :) I assume if we put alot of > > "burden" on a PHB it will be a very "smart PHB". We know that doesn't > > scale. RFC-2598 has a way of dealing with it: "well-defined rate" where a > > PHB can be "smart" about. Diffserv has a way of being smart about > > "diffserv domain" related "issues": PDB. May be, what EF is missing is to > > elaborate on this. It seems it is okay for a PHB to "approximate" to > > "worst-case delay bound" by Diffserv WG (previously "delay variance > > bound". I am sorry to say that the behavior of the hop (EF) has > > changed. Now, it is approximating to bound "delay" with a > > "specific" algorithm where it is not related to "worst-case delay > > bound" which requires "state" for individual flows or some assumptions. I > > don't see any problem with RFC-2598 other than, may be, some > > elaboration. There are 8 (eight) choices to bound "something" (loss, > > delay, jitter) if a PHB is willing to take some "risks" on > > "consistent-reasoning"; each having a different behavior and the most > > general way to express this is that something is *always* less than > > something. How things are done is details and it is wrong to specify a > > detail unless it is universally accepted. > > > > My 2 cents, > > > > Alper K. Demir > > > > On Mon, 18 Dec 2000, Brian E Carpenter wrote: > > > > > The current question is whether the charny-et-al-compromise specification > > > is going to be called EF. [If not, let the games commence :-] > > > > > > Brian > > > > > > "Manfredi, Albert E" wrote: > > > > > > > > Brian E Carpenter: > > > > > > > > > Bruce, the reason I chose to put the naming question to the list is > > > > > that the naming issue was very far from explicit in the discussion > > > > > on Tuesday, and there wasn't time to make it explicit. > > > > > > > > > > My intention is to close off the naming discussion tomorrow > > > > > December 19, > > > > > and state what I see as the rough consensus. > > > > > > > > Sorry I didn't commit to memory all of the suggestions, but did anyone > > > > recomment something like, say, Guaranteed Frame Rate (GFR)? :)) > > > > > > > > Dunno, I just pulled that one out of the air. > > > > > > > > Bert > > > > > > _______________________________________________ > > > diffserv mailing list > > > diffserv@ietf.org > > > http://www1.ietf.org/mailman/listinfo/diffserv > > > Archive: http://www2.ietf.org/mail-archive/working-groups/diffserv/current/maillist.html > > > > > > > _______________________________________________ > > diffserv mailing list > > diffserv@ietf.org > > http://www1.ietf.org/mailman/listinfo/diffserv > > Archive: http://www2.ietf.org/mail-archive/working-groups/diffserv/current/maillist.html > > _______________________________________________ > diffserv mailing list > diffserv@ietf.org > http://www1.ietf.org/mailman/listinfo/diffserv > Archive: http://www2.ietf.org/mail-archive/working-groups/diffserv/current/maillist.html > _______________________________________________ diffserv mailing list diffserv@ietf.org http://www1.ietf.org/mailman/listinfo/diffserv Archive: http://www2.ietf.org/mail-archive/working-groups/diffserv/current/maillist.html From diffserv-admin@ietf.org Wed Dec 20 20:50:17 2000 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with SMTP id UAA21585 for ; Wed, 20 Dec 2000 20:50:17 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id UAA01548; Wed, 20 Dec 2000 20:08:29 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id UAA01517 for ; Wed, 20 Dec 2000 20:08:25 -0500 (EST) Received: from mailman.packetdesign.com (dns.PACKETDESIGN.NET [216.15.46.10]) by ietf.org (8.9.1a/8.9.1a) with SMTP id UAA20924 for ; Wed, 20 Dec 2000 20:08:23 -0500 (EST) Received: from packetdesign.com (dhcp-168-0-13.packetdesign.com [192.168.0.13]) by mailman.packetdesign.com (8.11.0/8.11.0) with ESMTP id eBL17qQ48345 for ; Wed, 20 Dec 2000 17:07:52 -0800 (PST) (envelope-from nichols@packetdesign.com) Message-ID: <3A4157FE.5DAF0CC0@packetdesign.com> Date: Wed, 20 Dec 2000 17:08:14 -0800 From: Kathleen Nichols X-Mailer: Mozilla 4.73 [en] (X11; I; Linux 2.2.12 i386) X-Accept-Language: en MIME-Version: 1.0 To: diffserv@ietf.org Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Subject: [Diffserv] draft-ietf-diffserv-pdf-def-02 Sender: diffserv-admin@ietf.org Errors-To: diffserv-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Diffserv Discussion List X-BeenThere: diffserv@ietf.org Content-Transfer-Encoding: 7bit Following the informal Last Call and including some additional points raised at the WG meeting (technically after the last call), and after some consulation with our AD, Scott Bradner, we've revised this draft and sent it on to Scott and Allison. The new draft was submitted to the internet drafts editor so should show up soon. Briefly, Change log for -02 version A number of typos and unclear sections were fixed after comments were received. The word "rules" was used in several places for different purposes. Used different words or diffserv terms (Introduction, 4, 5.2, 7). More discussion of Service Level Guarantees and possible relationship to a BE PDB (7.1). Marked "guidelines" of section 8 with Gx's as consistent with RFC 2475. Changed guidelines so that a path is available even if there isn't an active WG. Kathie _______________________________________________ diffserv mailing list diffserv@ietf.org http://www1.ietf.org/mailman/listinfo/diffserv Archive: http://www2.ietf.org/mail-archive/working-groups/diffserv/current/maillist.html From diffserv-admin@ietf.org Wed Dec 20 21:06:31 2000 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with SMTP id VAA21855 for ; Wed, 20 Dec 2000 21:06:31 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id UAA01828; Wed, 20 Dec 2000 20:29:47 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id UAA01795 for ; Wed, 20 Dec 2000 20:29:42 -0500 (EST) Received: from mailman.packetdesign.com (dns.PACKETDESIGN.NET [216.15.46.10]) by ietf.org (8.9.1a/8.9.1a) with SMTP id UAA21231 for ; Wed, 20 Dec 2000 20:29:39 -0500 (EST) Received: from packetdesign.com (dhcp-168-0-13.packetdesign.com [192.168.0.13]) by mailman.packetdesign.com (8.11.0/8.11.0) with ESMTP id eBL1T6Q48513; Wed, 20 Dec 2000 17:29:06 -0800 (PST) (envelope-from nichols@packetdesign.com) Message-ID: <3A415CF8.4756D2B@packetdesign.com> Date: Wed, 20 Dec 2000 17:29:28 -0800 From: Kathleen Nichols X-Mailer: Mozilla 4.73 [en] (X11; I; Linux 2.2.12 i386) X-Accept-Language: en MIME-Version: 1.0 To: Brian E Carpenter CC: Grace Kou , diffserv@ietf.org Subject: Re: [Diffserv] basic doubts about PHBs References: <3A414168.5B0547D2@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 Actually, there WAS an unsubmitted draft from Nabil Seddigh, Biswajit Nandy, and Juha Heinanen on something called an AR PDB. (Assured Rate, I think). They sent us a url for it after the I-D deadline and we encouraged them to submit it, but said it was too late for the San Diego IETF. Kathie Brian E Carpenter wrote: > > Grace, > > The AF proponents have not yet attempted to publish PDB (per-domain > behavior) definitions based on AF, so I don't think we have an answer > to your question for AF. For EF, despite all the recent debate, > we do have a generic view that something like Virtual Wire is the right > type of PDB, and that is work in progress. > > For purely practical discussion on this I'd suggest the diffserv > implementation list. But if anyone wants to draft a PDB based on AF, > now is the time to do so. > > Brian > > Grace Kou wrote: > > > > Hi, > > > > I am studying Diffserv (from a service provider's perspective) > > and have some basic questions. I would like to know what are the > > typical services (or any real-world examples) to be supported by EF > > and AF PHBs? If EF is targeted for typically low-delay and low > > jitter, real-time, applications, then what kind of services are > > the "better-than-best-effort" AF PHBs targeting? With these PHBs, > > in particular AF PHBs, as loosely defined as they are now, how is a > > service provider supposed to construct services with QoS over a > > heterogeneous network that supports these "building blocks", which > > may come from different vendors and look and implemented very differently? > > Suppose my SLS is defined by a 3-tuple: > > . How am I supposed to > > create a service based on this 3-tuple using Diffserv "building > > blocks" if I don't even know what AF1, AF2, AF3, and AF4 are? > > If I have to individually tune the parameters of meters, the schedulers > > and the like on a per-hop basis along the path to ensure my SLS is met, > > then what is the need for all these PHB's any way? As far as I am > > concerned, AF PHBs are only useful intra domain for, perhaps, creating > > a PDB. > > > > Thank you. > > > > - G. Kou > > _________________________________________________________________ > > Get your FREE download of MSN Explorer at http://explorer.msn.com > > > > _______________________________________________ > > diffserv mailing list > > diffserv@ietf.org > > http://www1.ietf.org/mailman/listinfo/diffserv > > Archive: http://www2.ietf.org/mail-archive/working-groups/diffserv/current/maillist.html > > -- > - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - > Brian E Carpenter > Program Director, Internet Standards & Technology, IBM > On assignment for IBM at http://www.iCAIR.org > Board Chairman, Internet Society http://www.isoc.org > Non-IBM email: brian@icair.org > > _______________________________________________ > diffserv mailing list > diffserv@ietf.org > http://www1.ietf.org/mailman/listinfo/diffserv > Archive: http://www2.ietf.org/mail-archive/working-groups/diffserv/current/maillist.html _______________________________________________ diffserv mailing list diffserv@ietf.org http://www1.ietf.org/mailman/listinfo/diffserv Archive: http://www2.ietf.org/mail-archive/working-groups/diffserv/current/maillist.html From diffserv-admin@ietf.org Wed Dec 20 21:22:06 2000 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with SMTP id VAA22135 for ; Wed, 20 Dec 2000 21:22:06 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id UAA02256; Wed, 20 Dec 2000 20:42:20 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id UAA02225 for ; Wed, 20 Dec 2000 20:42:16 -0500 (EST) Received: from usc.edu (root@usc.edu [128.125.253.136]) by ietf.org (8.9.1a/8.9.1a) with SMTP id UAA21482 for ; Wed, 20 Dec 2000 20:42:14 -0500 (EST) Received: from aludra.usc.edu (demir@aludra.usc.edu [128.125.253.184]) by usc.edu (8.9.3.1/8.9.3/usc) with ESMTP id RAA21151; Wed, 20 Dec 2000 17:42:15 -0800 (PST) Received: from localhost (demir@localhost) by aludra.usc.edu (8.9.3.1/8.9.3/usc) with ESMTP id RAA20157; Wed, 20 Dec 2000 17:42:14 -0800 (PST) Date: Wed, 20 Dec 2000 17:42:14 -0800 (PST) From: demir To: Brian E Carpenter cc: Grace Kou , diffserv@ietf.org Subject: Re: [Diffserv] basic doubts about PHBs In-Reply-To: <3A414168.5B0547D2@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 Grace, I think "do nothing PDB", "do whatever you want PDB" and "do everything you can PDB" will give you a vast amount of services for AF. Like Brian said, "do whatever needed PDB" is not yet attempted. To me, "do nothing PDB" is enough for some applications and they will be happy about it. I don't agree with your statement on "better-than-best-effort" service attempt of AF PHB. To me in a multi-class-service environment, it is not possible to compare services unless there is a relation with compared services or one defines what comparision means (this option might mislead). I don't agree with your referring "loosely defined" for AF PHB or EF PHB (RFC-2598). I guess what you mean is "based on coarse-grained" mechanisms for diffserv services. To me, it is not possible to compare "coarse-grained" mechanisms without above assumptions I made in a general way. However, market decides the "pricing" and this is not only based on PHBs, I assume. Alper K. Demir On Wed, 20 Dec 2000, Brian E Carpenter wrote: > Grace, > > The AF proponents have not yet attempted to publish PDB (per-domain > behavior) definitions based on AF, so I don't think we have an answer > to your question for AF. For EF, despite all the recent debate, > we do have a generic view that something like Virtual Wire is the right > type of PDB, and that is work in progress. > > For purely practical discussion on this I'd suggest the diffserv > implementation list. But if anyone wants to draft a PDB based on AF, > now is the time to do so. > > Brian > > Grace Kou wrote: > > > > Hi, > > > > I am studying Diffserv (from a service provider's perspective) > > and have some basic questions. I would like to know what are the > > typical services (or any real-world examples) to be supported by EF > > and AF PHBs? If EF is targeted for typically low-delay and low > > jitter, real-time, applications, then what kind of services are > > the "better-than-best-effort" AF PHBs targeting? With these PHBs, > > in particular AF PHBs, as loosely defined as they are now, how is a > > service provider supposed to construct services with QoS over a > > heterogeneous network that supports these "building blocks", which > > may come from different vendors and look and implemented very differently? > > Suppose my SLS is defined by a 3-tuple: > > . How am I supposed to > > create a service based on this 3-tuple using Diffserv "building > > blocks" if I don't even know what AF1, AF2, AF3, and AF4 are? > > If I have to individually tune the parameters of meters, the schedulers > > and the like on a per-hop basis along the path to ensure my SLS is met, > > then what is the need for all these PHB's any way? As far as I am > > concerned, AF PHBs are only useful intra domain for, perhaps, creating > > a PDB. > > > > Thank you. > > > > - G. Kou > > _________________________________________________________________ > > Get your FREE download of MSN Explorer at http://explorer.msn.com > > > > _______________________________________________ > > diffserv mailing list > > diffserv@ietf.org > > http://www1.ietf.org/mailman/listinfo/diffserv > > Archive: http://www2.ietf.org/mail-archive/working-groups/diffserv/current/maillist.html > > -- > - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - > Brian E Carpenter > Program Director, Internet Standards & Technology, IBM > On assignment for IBM at http://www.iCAIR.org > Board Chairman, Internet Society http://www.isoc.org > Non-IBM email: brian@icair.org > > _______________________________________________ > diffserv mailing list > diffserv@ietf.org > http://www1.ietf.org/mailman/listinfo/diffserv > Archive: http://www2.ietf.org/mail-archive/working-groups/diffserv/current/maillist.html > _______________________________________________ diffserv mailing list diffserv@ietf.org http://www1.ietf.org/mailman/listinfo/diffserv Archive: http://www2.ietf.org/mail-archive/working-groups/diffserv/current/maillist.html From diffserv-admin@ietf.org Wed Dec 20 23:55: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 SMTP id XAA26348 for ; Wed, 20 Dec 2000 23:55:39 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id XAA04269; Wed, 20 Dec 2000 23:38:20 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id XAA04238 for ; Wed, 20 Dec 2000 23:38:16 -0500 (EST) Received: from web10905.mail.yahoo.com (web10905.mail.yahoo.com [216.136.131.41]) by ietf.org (8.9.1a/8.9.1a) with SMTP id XAA26080 for ; Wed, 20 Dec 2000 23:38:14 -0500 (EST) Message-ID: <20001221043816.14239.qmail@web10905.mail.yahoo.com> Received: from [161.142.112.8] by web10905.mail.yahoo.com; Wed, 20 Dec 2000 20:38:16 PST Date: Wed, 20 Dec 2000 20:38:16 -0800 (PST) From: Qahhar Qadir To: diffserv@ietf.org MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Subject: [Diffserv] Guaranteed services IntServ Patch for NS-2? Sender: diffserv-admin@ietf.org Errors-To: diffserv-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Diffserv Discussion List X-BeenThere: diffserv@ietf.org Hi Group, Could you please tell me how can get the NS-2 patch for Guaranteed Services Intserv implementation? Thanx Safeen __________________________________________________ Do You Yahoo!? Yahoo! Shopping - Thousands of Stores. Millions of Products. http://shopping.yahoo.com/ _______________________________________________ diffserv mailing list diffserv@ietf.org http://www1.ietf.org/mailman/listinfo/diffserv Archive: http://www2.ietf.org/mail-archive/working-groups/diffserv/current/maillist.html From diffserv-admin@ietf.org Thu Dec 21 05:33: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 SMTP id FAA14425 for ; Thu, 21 Dec 2000 05:33:12 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id FAA13513; Thu, 21 Dec 2000 05:00:54 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id FAA13414 for ; Thu, 21 Dec 2000 05:00:47 -0500 (EST) Received: from pelican.tk.uni-linz.ac.at (root@pelican.tk.uni-linz.ac.at [140.78.188.41]) by ietf.org (8.9.1a/8.9.1a) with SMTP id FAA14132 for ; Thu, 21 Dec 2000 05:00:46 -0500 (EST) Received: from olibaer (olibaer.tk.uni-linz.ac.at [140.78.92.45]) by pelican.tk.uni-linz.ac.at (8.9.1a/8.9.1) with SMTP id LAA05679 for ; Thu, 21 Dec 2000 11:00:46 +0100 (MET) From: Michael Welzl To: Date: Thu, 21 Dec 2000 11:07:52 +0100 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook 8.5, Build 4.71.2173.0 X-MimeOLE: Produced By Microsoft MimeOLE V5.50.3825.400 Importance: Normal X-MIME-Autoconverted: from 8bit to quoted-printable by pelican.tk.uni-linz.ac.at id LAA05679 X-MIME-Autoconverted: from quoted-printable to 8bit by optimus.ietf.org id FAA13415 Subject: [Diffserv] 2nd CFP Special session "ABR to the Internet", SCI 2001, ext. abstracts due 31.12.00 Sender: diffserv-admin@ietf.org Errors-To: diffserv-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Diffserv Discussion List X-BeenThere: diffserv@ietf.org X-MIME-Autoconverted: from 8bit to quoted-printable by optimus.ietf.org id FAA13513 Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by ietf.org id FAA14425 Please note that the deadline for submission of extended abstracts (31. 12.) is getting close. Our apologies if you receive this message more than once. Please distribute this call to any of your colleagues who might be interested. -------------------------------------------------------------------- 2nd C A L L F O R P A P E R S Special Session: ABR to the Internet ==================================== THE 5TH WORLD MULTICONFERENCE ON SYSTEMICS, CYBERNETICS AND INFORMATICS SCI'2001 July, 22-25, 2001 Orlando, Florida(USA) Sheraton World http://www.iiis.org/sci/ THE "ABR TO THE INTERNET" SESSION: ATM's "Available Bit Rate" (ABR) service provides a dramatically reduced cell loss ratio by means of a signaling mechanism called "Explicit Rate Feedback"; information from the network is provided to end nodes in order to facilitate adaptation. On the contrary, adaptive Internet applications rely on mechanisms that probe the network in order to avoid congestions; packet loss must be experienced before it can be avoided on a long term basis. Developers of commercial applications seem to avoid adaptation because they don't see enough QoS benefit. SCOPE: As a first step, we have seen ECN enhance adaptation on the Internet. We are looking for papers that represent the next step. Topics of interest include, but are not limited to, the following questions: * What data should be provided to end nodes? * Which QoS could be achieved? * Where should the signaling take place? (end2end, edge2edge, core, ...) * How do we deal with path changes? * Can the signaling be incorporated with DiffServ, MPLS, ...? * What about fairness issues and TCP-friendliness? SUBMISSION OF PAPERS: Prospective authors are invited to submit an extended abstract (about 1.5 to 2 pages) to Michael Welzl (michael@tk.uni-linz.ac.at) in postscript, PDF or Word 97 format. English is the official language of SCI 2001, thus all papers must be submitted and presented in English. EVALUATION PROCESS: Papers will be evaluated for originality, significance, clarity, and soundness. Each paper will be refereed by several researchers in the topical area. THE CONFERENCE: SCI 2001 is an international forum for scientists and engineers, researchers and consultants, theoreticians and practitioners in the fields of Systemics, Cybernetics and Informatics. It is a forum for focused disciplinary research, as well as for multi, inter and transdiciplinary studies and projects. One of its aims is to relate disciplines fostering analogical thinking and, hence, producing input to the logical thinking. Invited Sessions with high quality papers might be selected for multiple author book publications. Two books are being published now as result of good invited sessions. IMPORTANT DATES: 31. 12. Submission of extended abstracts (1.5 - 2 pages) 16. 02. Notification of acceptance 13. 04. full papers due All accepted papers are expected to be presented at the conference. OTHER INFORMATION: It is planned to hold a BOF session on "ABR to the Internet" at a future IETF meeting; authors are invited to join this collaborative effort which may eventually be a realization of this session's topic. Further information on the BOF can be found at http://www.tk.uni-linz.ac.at/~michael/ptp SESSION CHAIR / CONTACT: Michael Welzl Telecooperation Group Dpt. of Computer Science Johannes Kepler University of Linz Altenberger Str. 69 A-4040 Linz, Austria Phone: +43 (732) 2468 - 9264 Fax: +43 (732) 2468 - 9829 E-mail: michael@tk.uni-linz.ac.at SESSION CO-CHAIR: Prof. Dr. Max Mühlhäuser TU Darmstadt - FB 20 FG Telekooperation Alexanderstrasse 6, D-64283 Darmstadt / Germany Phone: +49 (6151) 16 - 3709 Fax: +49 (6151) 16 - 3052 Refer to http://www.tk.uni-linz.ac.at/~michael/abr2internet for up-to-date information. _______________________________________________ diffserv mailing list diffserv@ietf.org http://www1.ietf.org/mailman/listinfo/diffserv Archive: http://www2.ietf.org/mail-archive/working-groups/diffserv/current/maillist.html From diffserv-admin@ietf.org Thu Dec 21 09:41:45 2000 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with SMTP id JAA20850 for ; Thu, 21 Dec 2000 09:41:45 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id JAA15812; Thu, 21 Dec 2000 09:05:16 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id JAA15790 for ; Thu, 21 Dec 2000 09:05:13 -0500 (EST) Received: from sol4.rmc.ca (sol4.rmc.ca [137.94.1.134]) by ietf.org (8.9.1a/8.9.1a) with SMTP id JAA19708 for ; Thu, 21 Dec 2000 09:05:13 -0500 (EST) Received: from rmc.ca ([137.94.177.81]) by sol4.rmc.ca (Netscape Messaging Server 4.1) with ESMTP id G5X8FW00.I1P for ; Thu, 21 Dec 2000 09:04:44 -0500 Message-ID: <3A420E04.50E50901@rmc.ca> Date: Thu, 21 Dec 2000 09:04:52 -0500 From: "John Dullaert" X-Mailer: Mozilla 4.73 [en] (WinNT; U) X-Accept-Language: en MIME-Version: 1.0 To: Diff Serv Subject: Re: [Diffserv] Yesterday's EF discussion References: <200012140019.AAA08792@mail-gw1.hursley.ibm.com> <3A38135E.1AD72AFF@hursley.ibm.com> Content-Type: multipart/mixed; boundary="------------D7D2414CCA27A55C5CFB5E0E" Sender: diffserv-admin@ietf.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. --------------D7D2414CCA27A55C5CFB5E0E Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit This may be a little late, but given that the end result is essentially the same behaviour, without getting into too much detail, I would recommend keeping the name. It is bad enough that some people still refer to Premium service in the same breath as EF. jcd Brian E Carpenter wrote: > Nabil, > > The issue is what is least confusing to the user community - a new definition > with the old name, or a new name? I'm interested in opinions. > > Brian > > Nabil Seddigh wrote: > > > > In message "[Diffserv] Yesterday's EF discussion", Brian E Carpenter > > writes: > > > > > > > > What should the name of the PHB be? > > > Chair's proposal: Defined Rate (DR). I believe that after this > > long > > > and confusing discussion, it would be wise to retire the previous > > name. > > > > > > > Somehow DR sounds like a better name for a PDB. > > If it is decided that the "EF" name be retired, would suggest picking > > a name that's reflective of some kind of forwarding treatment. > > e.g. XF (Express Forwarding), LDJ (Low Delay Jitter Forwarding) > > etc > > > > Controversy aside, there's a lot of paper work out there with the name > > EF on it. Is there any way to escape without changing the name? > > > > Best, > > Nabil Seddigh > > _______________________________________________ > diffserv mailing list > diffserv@ietf.org > http://www1.ietf.org/mailman/listinfo/diffserv > Archive: http://www2.ietf.org/mail-archive/working-groups/diffserv/current/maillist.html --------------D7D2414CCA27A55C5CFB5E0E Content-Type: text/x-vcard; charset=us-ascii; name="dullaert-j.vcf" Content-Description: Card for John C. Dullaert Content-Disposition: attachment; filename="dullaert-j.vcf" Content-Transfer-Encoding: 7bit begin:vcard n:Dullaert;John tel;cell:613-548-8053 tel;fax:613-544-8107 tel;home:613-548-8053 tel;work:613-541-6000 x 6028 x-mozilla-html:FALSE org:Royal Military College of Canada;Computer Engineering version:2.1 email;internet:dullaert-j@rmc.ca title:Captain adr;quoted-printable:;;Room 5005=0D=0ASawyer Building=0D=0ARMC;Kingston;Ontario;K7K 5K7;Canada fn:John C. Dullaert end:vcard --------------D7D2414CCA27A55C5CFB5E0E-- _______________________________________________ diffserv mailing list diffserv@ietf.org http://www1.ietf.org/mailman/listinfo/diffserv Archive: http://www2.ietf.org/mail-archive/working-groups/diffserv/current/maillist.html From diffserv-admin@ietf.org Thu Dec 21 10:18:58 2000 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with SMTP id KAA21704 for ; Thu, 21 Dec 2000 10:18:53 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id JAA16267; Thu, 21 Dec 2000 09:45:25 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id JAA16246 for ; Thu, 21 Dec 2000 09:45:22 -0500 (EST) Received: from mailhub1.almaden.ibm.com (mailhub1.almaden.ibm.com [198.4.83.44]) by ietf.org (8.9.1a/8.9.1a) with SMTP id JAA20898 for ; Thu, 21 Dec 2000 09:45:22 -0500 (EST) Received: from maui.almaden.ibm.com (maui.almaden.ibm.com [9.1.24.92]) by mailhub1.almaden.ibm.com (8.8.8/8.8.8) with ESMTP id GAA52884; Thu, 21 Dec 2000 06:39:35 -0800 Received: from hursley.ibm.com (gsine04.us.sine.ibm.com [9.14.6.44]) by maui.almaden.ibm.com (AIX4.3/8.9.3/8.7) with ESMTP id GAA32470; Thu, 21 Dec 2000 06:44:53 -0800 Message-ID: <3A421714.9A1EA6CC@hursley.ibm.com> Date: Thu, 21 Dec 2000 08:43:32 -0600 From: Brian E Carpenter Organization: IBM X-Mailer: Mozilla 4.61 [en] (Win98; I) X-Accept-Language: en,fr MIME-Version: 1.0 To: Qahhar Qadir CC: diffserv@ietf.org Subject: Re: [Diffserv] Guaranteed services IntServ Patch for NS-2? References: <20001221043816.14239.qmail@web10905.mail.yahoo.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: diffserv-admin@ietf.org Errors-To: diffserv-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Diffserv Discussion List X-BeenThere: diffserv@ietf.org Content-Transfer-Encoding: 7bit This is not an appropriate topic for the WG list. Thanks Brian Carpenter diffserv co-chair Qahhar Qadir wrote: > > Hi Group, > > Could you please tell me how can get the NS-2 patch > for Guaranteed Services Intserv implementation? > > Thanx > Safeen > > __________________________________________________ > Do You Yahoo!? > Yahoo! Shopping - Thousands of Stores. Millions of Products. > http://shopping.yahoo.com/ > > _______________________________________________ > diffserv mailing list > diffserv@ietf.org > http://www1.ietf.org/mailman/listinfo/diffserv > Archive: http://www2.ietf.org/mail-archive/working-groups/diffserv/current/maillist.html -- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - Brian E Carpenter Program Director, Internet Standards & Technology, IBM On assignment for IBM at http://www.iCAIR.org Board Chairman, Internet Society http://www.isoc.org Non-IBM email: brian@icair.org _______________________________________________ diffserv mailing list diffserv@ietf.org http://www1.ietf.org/mailman/listinfo/diffserv Archive: http://www2.ietf.org/mail-archive/working-groups/diffserv/current/maillist.html From diffserv-admin@ietf.org Thu Dec 21 11:50: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 SMTP id LAA24086 for ; Thu, 21 Dec 2000 11:50:20 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id LAA17534; Thu, 21 Dec 2000 11:21:09 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id LAA17503 for ; Thu, 21 Dec 2000 11:21:05 -0500 (EST) Received: from sj-msg-core-4.cisco.com (sj-msg-core-4.cisco.com [171.71.163.10]) by ietf.org (8.9.1a/8.9.1a) with SMTP id LAA23235 for ; Thu, 21 Dec 2000 11:21:04 -0500 (EST) From: Asim.Khan@vf.vodafone.co.uk Received: from sj-msg-av-1.cisco.com (sj-msg-av-1.cisco.com [171.69.11.130]) by sj-msg-core-4.cisco.com (8.9.3/8.9.1) with ESMTP id IAA27457 for ; Thu, 21 Dec 2000 08:20:37 -0800 (PST) Received: from proxy1.cisco.com (localhost [127.0.0.1]) by sj-msg-av-1.cisco.com (8.10.1/8.10.1) with ESMTP id eBLGKZc04700 for ; Thu, 21 Dec 2000 08:20:35 -0800 (PST) Received: from igate2.vodafone.co.uk (igate2.vodafone.co.uk [194.62.232.10]) by proxy1.cisco.com (8.9.1b+Sun/8.9.3) with ESMTP id IAA00007 for ; Thu, 21 Dec 2000 08:20:21 -0800 (PST) Received: by igate2.vodafone.co.uk; (8.8.8/1.3/10May95) id QAA20243; Thu, 21 Dec 2000 16:15:29 GMT Received: from putney.vfl.vodafone (unverified) by mimesweeper1.vfl.vodafone (Content Technologies SMTPRS 2.0.15) with ESMTP id for ; Thu, 21 Dec 2000 16:15:29 +0000 Received: by putney.vfl.vodafone with Internet Mail Service (5.5.2448.0) id ; Thu, 21 Dec 2000 16:13:50 -0000 Message-Id: To: diffserv@external.cisco.com Date: Thu, 21 Dec 2000 16:13:47 -0000 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2448.0) Content-Type: text/plain; charset="iso-8859-1" Subject: [Diffserv] (no subject) Sender: diffserv-admin@ietf.org Errors-To: diffserv-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Diffserv Discussion List X-BeenThere: diffserv@ietf.org Dear All, Needed to know whether Diffserv provides mechanisms to provide preferential treatment to router-controlled traffic i.e OSPF, TDP/LDP, IS-IS. Regards Asim Khan _______________________________________________ diffserv mailing list diffserv@ietf.org http://www1.ietf.org/mailman/listinfo/diffserv Archive: http://www2.ietf.org/mail-archive/working-groups/diffserv/current/maillist.html From diffserv-admin@ietf.org Thu Dec 21 14:12: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 SMTP id OAA27839 for ; Thu, 21 Dec 2000 14:12:21 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id NAA19377; Thu, 21 Dec 2000 13:50:23 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id NAA19351 for ; Thu, 21 Dec 2000 13:50:19 -0500 (EST) Received: from pmesmtp01.wcom.com (pmesmtp01.wcom.com [199.249.20.1]) by ietf.org (8.9.1a/8.9.1a) with SMTP id NAA27258 for ; Thu, 21 Dec 2000 13:50:19 -0500 (EST) Received: from CONVERSION-DAEMON by firewall.mcit.com (PMDF V5.2-32 #42256) id <0G5X00J01LM320@firewall.mcit.com> for diffserv@ietf.org; Thu, 21 Dec 2000 18:49:15 +0000 (GMT) Received: from pmismtp01.wcomnet.com ([166.38.62.36]) by firewall.mcit.com (PMDF V5.2-32 #42256) with ESMTP id <0G5X00GL2LM2C1@firewall.mcit.com> for diffserv@ietf.org; Thu, 21 Dec 2000 18:49:15 +0000 (GMT) Received: from CONVERSION-DAEMON by pmismtp01.wcomnet.com (PMDF V5.2-33 #42258) id <0G5X00C01LM2XV@pmismtp01.wcomnet.com> for diffserv@ietf.org; Thu, 21 Dec 2000 18:49:14 +0000 (GMT) Received: from pmismtp01.wcomnet.com by pmismtp01.wcomnet.com (PMDF V5.2-33 #42258) with SMTP id <0G5X00C01LM2XS@pmismtp01.wcomnet.com> for diffserv@ietf.org; Thu, 21 Dec 2000 18:49:14 +0000 (GMT) Received: from omzexch006.mcit.com ([166.37.194.37]) by pmismtp01.wcomnet.com (PMDF V5.2-33 #42258) with ESMTP id <0G5X008LNLLNE4@pmismtp01.wcomnet.com> for diffserv@ietf.org; Thu, 21 Dec 2000 18:49:00 +0000 (GMT) Received: by omzexch006 with Internet Mail Service (5.5.2651.58) id ; Thu, 21 Dec 2000 18:48:59 +0000 Content-return: allowed Date: Thu, 21 Dec 2000 18:48:54 +0000 From: "Iliff, Tina" To: "'diffserv@ietf.org'" Message-id: <492EB4A3F68CD411ABE800508B69362E14B46C@RIPEXCH002.wcomnet.com> MIME-version: 1.0 X-Mailer: Internet Mail Service (5.5.2651.58) Content-type: multipart/alternative; boundary="Boundary_(ID_0EwJnwe01YRsfELPmdp48A)" Subject: [Diffserv] diffserv-pib-02; qosIfClassificationCaps Sender: diffserv-admin@ietf.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. --Boundary_(ID_0EwJnwe01YRsfELPmdp48A) Content-type: text/plain; charset=iso-8859-1 All, Comment regarding qosIfClassificationCapsSpec: The inputIpClassification value is stated to indicate whether or not the PEP supports classification on the ingress. My concern is that the PIB draft specifically states the following: On a given interface, there must be a complete classifier in place at all times in the ingress direction. This means that there will always be one or more filters that match every possible pattern that could be presented in an incoming packet. There is no such requirement in the egress direction." Maybe the capability indication which the PEP can provide for the ingress direction is whether or not it supports DiffServ QoS on ingress. What are your thoughts? Tina Iliff --Boundary_(ID_0EwJnwe01YRsfELPmdp48A) Content-type: text/html; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable diffserv-pib-02; qosIfClassificationCaps

All,

Comment regarding = qosIfClassificationCapsSpec:
The inputIpClassification value is = stated to indicate whether or not the PEP supports classification on = the ingress.  My concern is that the PIB draft specifically states = the following:  On a = given interface, there must be a complete  classifier  = in  place  at  all  times in   the = ingress direction. This means that there will always

be one or more filters that = match every possible pattern  that  could be presented in an = incoming packet.
       There is no such requirement = in the egress direction."

Maybe the capability indication which = the PEP can provide for the ingress direction is whether or not it = supports DiffServ QoS on ingress.

What are your thoughts?

Tina Iliff

--Boundary_(ID_0EwJnwe01YRsfELPmdp48A)-- _______________________________________________ diffserv mailing list diffserv@ietf.org http://www1.ietf.org/mailman/listinfo/diffserv Archive: http://www2.ietf.org/mail-archive/working-groups/diffserv/current/maillist.html From diffserv-admin@ietf.org Thu Dec 21 15:19: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 SMTP id PAA29412 for ; Thu, 21 Dec 2000 15:19:15 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id OAA20086; Thu, 21 Dec 2000 14:49:58 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id OAA20055 for ; Thu, 21 Dec 2000 14:49:54 -0500 (EST) Received: from mailman.packetdesign.com (dns.PACKETDESIGN.NET [216.15.46.10]) by ietf.org (8.9.1a/8.9.1a) with SMTP id OAA28632 for ; Thu, 21 Dec 2000 14:49:53 -0500 (EST) Received: from packetdesign.com (dhcp-168-0-13.packetdesign.com [192.168.0.13]) by mailman.packetdesign.com (8.11.0/8.11.0) with ESMTP id eBLJmhQ56783; Thu, 21 Dec 2000 11:48:44 -0800 (PST) (envelope-from nichols@packetdesign.com) Message-ID: <3A425EB7.9925F3CD@packetdesign.com> Date: Thu, 21 Dec 2000 11:49:11 -0800 From: Kathleen Nichols X-Mailer: Mozilla 4.73 [en] (X11; I; Linux 2.2.12 i386) X-Accept-Language: en MIME-Version: 1.0 To: Roland Bless CC: diffserv@ietf.org Subject: Re: [Diffserv] comments on the bulk handling draft References: <200012141109.MAA03984@tpce10.telematik.informatik.uni-karlsruhe.de> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: diffserv-admin@ietf.org Errors-To: diffserv-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Diffserv Discussion List X-BeenThere: diffserv@ietf.org Content-Transfer-Encoding: 7bit Roland Bless wrote: > > Kathleen Nichcols wrote: > > > It's a shame you see it as a PHB...I really like that name, > > "limited effort" ... > > Why is it a shame? I expressed it that way to say that I thought that would make a good alternate name for the BH PDB. This was not a technical comment. It doesn't need to be pursued. ... I omitted some of our discussion, but I think these two paragraphs below show we are saying the same thing. That you MAY starve, but are not REQUIRED to starve: this is up to the network administrator. Writing the PDB to *permit* starvation was critical for two reasons: 1) we heard several operators express a desire to do that and 2) this is very different from the current notion of "best effort". Your words seem, to me, to say you think starvation is a bad idea, but to leave it up to the administrator. This is the same as the BH PDB, except we try not to express an opinion on whether starvation is "good" or "bad". > > IMHO even in congestion situations, one should be able to get some > LE packets through. Therefore, we think that starvation is even > not good for this low priority class. But if an administrator > decides to set the configurable limit to 0, then starvation is > also permitted. > > > So we were looking for something that PERMITS starvation, but > > doesn't require it. As I said above, I think that non-starvation, > > but a possible limit is easily covered by a CS. The earlier > > problem with using a CS had been concerns over breaking the > > SHOULD to do starvation. I spoke about this yesterday and > > Brian posted on this after you proposed your initial draft > > some months ago. > ... > > > But we want to describe a behavior across a domain. Both BE and > > BH have null traffic conditioning, though there may be classification > > required, may be marking, and may even be policing. > > Yes, but we want to describe a forwarding behavior. The origin > of the LE PHB was in the context of our proposed multicast > solution: if a new branch is grafted to a multicast tree by an existing > mc-routing protocol, packets are re-marked to the LE PHB within a multicast > DS node as long as no reservation was set up (by whatever mechanism) for > the new branch. In order to protect ordinary BE users from a possible flood > of re-marked packets which arrive with a better PHB, we defined this LE PHB. > In this case, a source of LE packets is possibly located within a domain. > Our intent is for a more general PDB to be used as needed. I would suggest that some experimentation with your multicast approach would be in order first. It's possible that the internet industry would reach a point where some of the CS PHBs, or some other DSCP marking, might be "default" configured for use by such PDBs as "best effort", "bulk handling", "network critical", etc. But it would be best to get some deployment experience and see what is useful first. Further, the notion of the amount of resource to allocate to something which is below best effort seems, arguably, to be best done on a network or domain basis. regards, Kathie _______________________________________________ diffserv mailing list diffserv@ietf.org http://www1.ietf.org/mailman/listinfo/diffserv Archive: http://www2.ietf.org/mail-archive/working-groups/diffserv/current/maillist.html From diffserv-admin@ietf.org Thu Dec 21 16:00:36 2000 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with SMTP id QAA00692 for ; Thu, 21 Dec 2000 16:00:36 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id PAA20528; Thu, 21 Dec 2000 15:24:03 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id PAA20505 for ; Thu, 21 Dec 2000 15:23:59 -0500 (EST) Received: from prue.eim.surrey.ac.uk (IDENT:exim@prue.eim.surrey.ac.uk [131.227.76.5]) by ietf.org (8.9.1a/8.9.1a) with SMTP id PAA29547 for ; Thu, 21 Dec 2000 15:24:00 -0500 (EST) Received: from regan.ee.surrey.ac.uk ([131.227.89.11]) by prue.eim.surrey.ac.uk with esmtp (Exim 3.16 #1) id 149CEr-0000hq-00; Thu, 21 Dec 2000 20:22:57 +0000 Date: Thu, 21 Dec 2000 20:22:42 +0000 (GMT) From: Lloyd Wood X-Sender: eep1lw@regan.ee.surrey.ac.uk Reply-To: L.Wood@eim.surrey.ac.uk To: Kathleen Nichols cc: Roland Bless , diffserv@ietf.org Subject: Re: [Diffserv] comments on the bulk handling draft In-Reply-To: <3A425EB7.9925F3CD@packetdesign.com> Message-ID: Organization: speaking for none X-url: http://www.ee.surrey.ac.uk/Personal/L.Wood/ X-no-archive: yes MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: diffserv-admin@ietf.org Errors-To: diffserv-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Diffserv Discussion List X-BeenThere: diffserv@ietf.org On Thu, 21 Dec 2000, Kathleen Nichols wrote: > It's a shame you see [BH] as a PHB...I really like that name, > "limited effort" I move that we rename the EF PHB 'unlimited effort', as a reflection of the time and resources expended on it. > I expressed it that way to say that I thought that would make > a good alternate name for the BH PDB. This was not a technical > comment. It doesn't need to be pursued. This is not a technical comment, and does not need to be pursued. L. PGP _______________________________________________ diffserv mailing list diffserv@ietf.org http://www1.ietf.org/mailman/listinfo/diffserv Archive: http://www2.ietf.org/mail-archive/working-groups/diffserv/current/maillist.html From diffserv-admin@ietf.org Thu Dec 21 17:11: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 SMTP id RAA02669 for ; Thu, 21 Dec 2000 17:11:23 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id QAA21738; Thu, 21 Dec 2000 16:46:27 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id QAA21707 for ; Thu, 21 Dec 2000 16:46:22 -0500 (EST) Received: from sj-msg-core-4.cisco.com (sj-msg-core-4.cisco.com [171.71.163.10]) by ietf.org (8.9.1a/8.9.1a) with SMTP id QAA01988 for ; Thu, 21 Dec 2000 16:46:22 -0500 (EST) Received: from sj-msg-av-1.cisco.com (sj-msg-av-1.cisco.com [171.69.11.130]) by sj-msg-core-4.cisco.com (8.9.3/8.9.1) with ESMTP id NAA08823 for ; Thu, 21 Dec 2000 13:45:54 -0800 (PST) Received: from proxy2.cisco.com (localhost [127.0.0.1]) by sj-msg-av-1.cisco.com (8.10.1/8.10.1) with ESMTP id eBLLjqb16322 for ; Thu, 21 Dec 2000 13:45:53 -0800 (PST) Received: from mailhub1.almaden.ibm.com (mailhub1.almaden.ibm.com [198.4.83.44]) by proxy2.cisco.com (8.9.1b+Sun/8.9.3) with ESMTP id NAA26701 for ; Thu, 21 Dec 2000 13:44:27 -0800 (PST) Received: from maui.almaden.ibm.com (maui.almaden.ibm.com [9.1.24.92]) by mailhub1.almaden.ibm.com (8.8.8/8.8.8) with ESMTP id NAA40474; Thu, 21 Dec 2000 13:35:22 -0800 Received: from hursley.ibm.com (gsine04.us.sine.ibm.com [9.14.6.44]) by maui.almaden.ibm.com (AIX4.3/8.9.3/8.7) with ESMTP id NAA32654; Thu, 21 Dec 2000 13:40:44 -0800 Message-ID: <3A42787C.46AF364A@hursley.ibm.com> Date: Thu, 21 Dec 2000 15:39:08 -0600 From: Brian E Carpenter Organization: IBM X-Mailer: Mozilla 4.61 [en] (Win98; I) X-Accept-Language: en,fr MIME-Version: 1.0 To: Asim.Khan@vf.vodafone.co.uk CC: diffserv@external.cisco.com 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 That is the operator's choice. I think many people expect to use Class Selector 6 for routing traffic, but diffserv doesn't dictate the choice. Brian Asim.Khan@vf.vodafone.co.uk wrote: > > Dear All, > Needed to know whether Diffserv provides mechanisms to provide preferential > treatment to router-controlled traffic i.e OSPF, TDP/LDP, IS-IS. > > Regards > > Asim Khan > > _______________________________________________ > diffserv mailing list > diffserv@ietf.org > http://www1.ietf.org/mailman/listinfo/diffserv > Archive: http://www2.ietf.org/mail-archive/working-groups/diffserv/current/maillist.html _______________________________________________ diffserv mailing list diffserv@ietf.org http://www1.ietf.org/mailman/listinfo/diffserv Archive: http://www2.ietf.org/mail-archive/working-groups/diffserv/current/maillist.html From diffserv-admin@ietf.org Thu Dec 21 17:13: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 SMTP id RAA02707 for ; Thu, 21 Dec 2000 17:13:35 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id QAA21788; Thu, 21 Dec 2000 16:48:16 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id QAA21756 for ; Thu, 21 Dec 2000 16:48:11 -0500 (EST) Received: from mailhub1.almaden.ibm.com (mailhub1.almaden.ibm.com [198.4.83.44]) by ietf.org (8.9.1a/8.9.1a) with SMTP id QAA02041 for ; Thu, 21 Dec 2000 16:48:11 -0500 (EST) Received: from maui.almaden.ibm.com (maui.almaden.ibm.com [9.1.24.92]) by mailhub1.almaden.ibm.com (8.8.8/8.8.8) with ESMTP id NAA53482; Thu, 21 Dec 2000 13:42:19 -0800 Received: from hursley.ibm.com (gsine04.us.sine.ibm.com [9.14.6.44]) by maui.almaden.ibm.com (AIX4.3/8.9.3/8.7) with ESMTP id NAA27386; Thu, 21 Dec 2000 13:47:42 -0800 Message-ID: <3A427A1D.7401847E@hursley.ibm.com> Date: Thu, 21 Dec 2000 15:46:05 -0600 From: Brian E Carpenter Organization: IBM X-Mailer: Mozilla 4.61 [en] (Win98; I) X-Accept-Language: en,fr MIME-Version: 1.0 To: "Iliff, Tina" CC: "'diffserv@ietf.org'" Subject: Re: [Diffserv] diffserv-pib-02; qosIfClassificationCaps References: <492EB4A3F68CD411ABE800508B69362E14B46C@RIPEXCH002.wcomnet.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 Not quite sure why you see a problem. Classification on egress would be somewhat unusual, but if there is no classifier on input a node cannot possibly be a diffserv node. I would assume that all classifiers will have a wild card match (a.k.a. an "else" clause) to catch packets that aren't caught by any explicit filter. Presumably, these packets would get default behavior. Brian > "Iliff, Tina" wrote: > > All, > > Comment regarding qosIfClassificationCapsSpec: > The inputIpClassification value is stated to indicate whether or not the PEP supports classification on the ingress. My > concern is that the PIB draft specifically states the following: On a given interface, there must be a complete classifier > in place at all times in the ingress direction. This means that there will always > > be one or more filters that match every possible pattern that could be presented in an incoming packet. > There is no such requirement in the egress direction." > > Maybe the capability indication which the PEP can provide for the ingress direction is whether or not it supports DiffServ QoS > on ingress. > > What are your thoughts? > > Tina Iliff _______________________________________________ diffserv mailing list diffserv@ietf.org http://www1.ietf.org/mailman/listinfo/diffserv Archive: http://www2.ietf.org/mail-archive/working-groups/diffserv/current/maillist.html From diffserv-admin@ietf.org Thu Dec 21 18:58: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 SMTP id SAA05044 for ; Thu, 21 Dec 2000 18:58:13 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id SAA23283; Thu, 21 Dec 2000 18:35:29 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id SAA23254 for ; Thu, 21 Dec 2000 18:35:25 -0500 (EST) Received: from dgesmtp01.wcom.com (dgesmtp01.wcom.com [199.249.16.16]) by ietf.org (8.9.1a/8.9.1a) with SMTP id SAA04690 for ; Thu, 21 Dec 2000 18:35:24 -0500 (EST) Received: from CONVERSION-DAEMON by firewall.mcit.com (PMDF V5.2-33 #42260) id <0G5X00K01YU855@firewall.mcit.com> for diffserv@ietf.org; Thu, 21 Dec 2000 23:34:56 +0000 (GMT) Received: from pmismtp04.wcomnet.com ([166.38.62.39]) by firewall.mcit.com (PMDF V5.2-33 #42260) with ESMTP id <0G5X00GJQYU8I4@firewall.mcit.com>; Thu, 21 Dec 2000 23:34:56 +0000 (GMT) Received: from CONVERSION-DAEMON by pmismtp04.wcomnet.com (PMDF V5.2-33 #42258) id <0G5X00901YU73H@pmismtp04.wcomnet.com>; Thu, 21 Dec 2000 23:34:55 +0000 (GMT) Received: from pmismtp04.wcomnet.com by pmismtp04.wcomnet.com (PMDF V5.2-33 #42258) with SMTP id <0G5X00801YTSWF@pmismtp04.wcomnet.com>; Thu, 21 Dec 2000 23:34:54 +0000 (GMT) Received: from omzexch007.mcit.com ([166.37.194.38]) by pmismtp04.wcomnet.com (PMDF V5.2-33 #42258) with ESMTP id <0G5X004L3YTP59@pmismtp04.wcomnet.com>; Thu, 21 Dec 2000 23:34:37 +0000 (GMT) Received: by omzexch007 with Internet Mail Service (5.5.2651.58) id ; Thu, 21 Dec 2000 23:34:37 +0000 Content-return: allowed Date: Thu, 21 Dec 2000 23:34:35 +0000 From: "Iliff, Tina" Subject: RE: [Diffserv] diffserv-pib-02; qosIfClassificationCaps To: "'Brian E Carpenter'" Cc: "'diffserv@ietf.org'" Message-id: <492EB4A3F68CD411ABE800508B69362E14B470@RIPEXCH002.wcomnet.com> MIME-version: 1.0 X-Mailer: Internet Mail Service (5.5.2651.58) Content-type: text/plain; charset=ISO-8859-1 Sender: diffserv-admin@ietf.org Errors-To: diffserv-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Diffserv Discussion List X-BeenThere: diffserv@ietf.org Maybe I should have stated it as a question or request: Please clarify the use of the qosIfClassificationCaps PRC as well as Specs attribute value. I agree. I do not see a requirement for classification on egress. I also understand the requirement to perform classification on egress in order to have a mechanism to separate traffic in order to provide different levels of service. This is exactly why I pose the question regarding the intent of the qosIfClassificationCapsSpec. -----Original Message----- From: Brian E Carpenter [mailto:brian@hursley.ibm.com] Sent: Thursday, December 21, 2000 3:46 PM To: Iliff, Tina Cc: 'diffserv@ietf.org' Subject: Re: [Diffserv] diffserv-pib-02; qosIfClassificationCaps Not quite sure why you see a problem. Classification on egress would be somewhat unusual, but if there is no classifier on input a node cannot possibly be a diffserv node. I would assume that all classifiers will have a wild card match (a.k.a. an "else" clause) to catch packets that aren't caught by any explicit filter. Presumably, these packets would get default behavior. Brian > "Iliff, Tina" wrote: > > All, > > Comment regarding qosIfClassificationCapsSpec: > The inputIpClassification value is stated to indicate whether or not the PEP supports classification on the ingress. My > concern is that the PIB draft specifically states the following: On a given interface, there must be a complete classifier > in place at all times in the ingress direction. This means that there will always > > be one or more filters that match every possible pattern that could be presented in an incoming packet. > There is no such requirement in the egress direction." > > Maybe the capability indication which the PEP can provide for the ingress direction is whether or not it supports DiffServ QoS > on ingress. > > What are your thoughts? > > Tina Iliff _______________________________________________ diffserv mailing list diffserv@ietf.org http://www1.ietf.org/mailman/listinfo/diffserv Archive: http://www2.ietf.org/mail-archive/working-groups/diffserv/current/maillist.h tml _______________________________________________ diffserv mailing list diffserv@ietf.org http://www1.ietf.org/mailman/listinfo/diffserv Archive: http://www2.ietf.org/mail-archive/working-groups/diffserv/current/maillist.html From diffserv-admin@ietf.org Thu Dec 21 20:29:52 2000 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with SMTP id UAA06542 for ; Thu, 21 Dec 2000 20:29:52 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id UAA24203; Thu, 21 Dec 2000 20:08:57 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id UAA24172 for ; Thu, 21 Dec 2000 20:08:49 -0500 (EST) Received: from exchsrv1.cosinecom.com (mail.cosinecom.com [63.88.104.16]) by ietf.org (8.9.1a/8.9.1a) with SMTP id UAA06103 for ; Thu, 21 Dec 2000 20:08:45 -0500 (EST) Received: by exchsrv1.cosinecom.com with Internet Mail Service (5.5.2650.21) id ; Thu, 21 Dec 2000 17:06:18 -0800 Message-ID: <7EB7C6B62C4FD41196A80090279A2911D8AB3A@exchsrv1.cosinecom.com> From: Jay Wang To: "'Iliff, Tina'" , "'Brian E Carpenter'" Cc: "'diffserv@ietf.org'" Subject: RE: [Diffserv] diffserv-pib-02; qosIfClassificationCaps Date: Thu, 21 Dec 2000 17:06:12 -0800 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C06BB3.60917F80" Sender: diffserv-admin@ietf.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_01C06BB3.60917F80 Content-Type: text/plain; charset="iso-8859-1" > Maybe I should have stated it as a question or request: > Please clarify the use of the qosIfClassificationCaps PRC as > well as Specs > attribute value. > > I agree. I do not see a requirement for classification on > egress. > I also understand the requirement to perform classification on > egress in order to have a mechanism to separate traffic in order to provide > different levels of service. You meant ingress here, right. Obviously, It is not "required" to do classification on Egress to support diffserv. Also, regarding your question regarding the use of qosIfClassificationCaps, you stated: "Maybe the capability indication which the PEP can provide for the ingress direction is whether or not it supports DiffServ QoS on ingress." Trying to guess what you mean from this, I think the answer is no because classification is a necessary, but NOT a sufficient, condition for QoS/Diffserv. So classification capability alone can not imply the if/node necessarily supports Diffserv/QoS. - Jay ------_=_NextPart_001_01C06BB3.60917F80 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable RE: [Diffserv] diffserv-pib-02; qosIfClassificationCaps

> Maybe I should have stated it as a question or = request:
> Please clarify the use of the = qosIfClassificationCaps PRC as
> well as Specs
> attribute value.
>
> I agree.  I do not see a requirement for = classification on
> egress. 

> I also understand the requirement to perform = classification on
> egress in order to have a mechanism to separate = traffic in order to provide
> different levels of service. 

You meant ingress here, right. Obviously, It is not = "required" to do classification
on Egress to support diffserv. Also, regarding your = question regarding
the use of qosIfClassificationCaps, you stated: =

        "Maybe the capability indication which the PEP can = provide for the ingress
        direction = is whether or not it supports DiffServ QoS on ingress."

Trying to guess what you mean from this, I think the = answer is no because
classification is a necessary, but NOT a sufficient, = condition for QoS/Diffserv.
So classification capability alone can not imply the = if/node necessarily supports
Diffserv/QoS.


- Jay

------_=_NextPart_001_01C06BB3.60917F80-- _______________________________________________ diffserv mailing list diffserv@ietf.org http://www1.ietf.org/mailman/listinfo/diffserv Archive: http://www2.ietf.org/mail-archive/working-groups/diffserv/current/maillist.html From diffserv-admin@ietf.org Fri Dec 22 18:33: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 SMTP id SAA16261 for ; Fri, 22 Dec 2000 18:33:11 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id SAA11353; Fri, 22 Dec 2000 18:11:20 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id SAA11322 for ; Fri, 22 Dec 2000 18:11:16 -0500 (EST) Received: from zcars04f.ca.nortel.com (h57s242a129n47.user.nortelnetworks.com [47.129.242.57]) by ietf.org (8.9.1a/8.9.1a) with SMTP id SAA16057 for ; Fri, 22 Dec 2000 18:11:14 -0500 (EST) Message-Id: <200012222311.SAA16057@ietf.org> Received: from zcard00n.ca.nortel.com by zcars04f.ca.nortel.com; Fri, 22 Dec 2000 18:07:58 -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.2652.39) id ZNHKTT6G; Fri, 22 Dec 2000 18:08:00 -0500 Received: from zcars02x.ca.nortel.com ([47.23.81.10]) by zcard00f.ca.nortel.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2652.39) id Y6C6MFV7; Fri, 22 Dec 2000 18:07:58 -0500 Date: Fri, 22 Dec 2000 18:07:42 -0500 (EST) X-Sybari-Space: 00000000 00000000 00000000 From: "Nabil Seddigh" Reply-To: "Nabil Seddigh" Subject: Re: [Diffserv] Assured Rate PDB To: Kathleen Nichols cc: Brian E Carpenter , Grace Kou , diffserv@ietf.org X-Mailer: Rosa 2.1 SunOS5.6 X-Rosa-Trace: nseddigh@zcars02x <47.23.81.10> MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-ID: X-Orig: Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by optimus.ietf.org id SAA11323 Sender: diffserv-admin@ietf.org Errors-To: 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 draft has been submitted to the internet-draft editor - we will post again when it appears in the drafts directory. The title and abstract are as follows: "An Assured Rate Per-Domain Behaviour for Differentiated Services" ----------------------------------------------- "This document describes a diffserv per-domain behaviour (PDB) called Assured Rate (AR). The AR PDB is suitable for carrying traffic aggregates that require rate assurance but do not require delay and jitter bounds. The traffic aggregate will also have the opportunity to obtain excess bandwidth beyond the assured rate. The PDB can be created using the diffserv AF PHB along with suitable policers at the domain ingress nodes." Regards Nabil >Actually, there WAS an unsubmitted draft from Nabil Seddigh, Biswajit >Nandy, >and Juha Heinanen on something called an AR PDB. (Assured Rate, I >think). They sent us a url for it after the I-D deadline and we >encouraged them to submit it, but said it was too late for >the San Diego IETF. > > Kathie _______________________________________________ diffserv mailing list diffserv@ietf.org http://www1.ietf.org/mailman/listinfo/diffserv Archive: http://www2.ietf.org/mail-archive/working-groups/diffserv/current/maillist.html From diffserv-admin@ietf.org Fri Dec 22 23:39:59 2000 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with SMTP id XAA20355 for ; Fri, 22 Dec 2000 23:39:59 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id XAA13543; Fri, 22 Dec 2000 23:13:39 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id XAA13506 for ; Fri, 22 Dec 2000 23:13:35 -0500 (EST) Received: from aomswin1.allenovery.com (mail1.allenovery.com [194.129.43.121]) by ietf.org (8.9.1a/8.9.1a) with SMTP id XAA19898 for ; Fri, 22 Dec 2000 23:13:32 -0500 (EST) Received: from mail.mindspring.com (unverified) by aomswin1.allenovery.com (Content Technologies SMTPRS 4.1.5) with SMTP id for ; Sat, 23 Dec 2000 03:48:56 +0000 From: To: Date: Fri, 22 Dec 2000 19:07:57 Message-Id: <73.86287.520943@mail.mindspring.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Subject: [Diffserv] (no subject) Sender: diffserv-admin@ietf.org Errors-To: diffserv-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Diffserv Discussion List X-BeenThere: diffserv@ietf.org Content-Transfer-Encoding: 7bit GET YOUR OWN 100 MEG WEBSITE FOR ONLY $11.95 PER MONTH TODAY! STOP PAYING $19.95 or more TODAY for your web site, WHEN YOU CAN GET ONE FOR ONLY $11.95 PER MONTH! DO YOU ALREADY HAVE A WEBSITE? ALL YOU HAVE TO DO IS TRANSFER THE DOMAIN TO OUR SERVERS AND UPLOAD YOUR DATA AND YOU ARE READY TO GO! YOUR NEW WEB SPACE CAN BE CREATED INSTANTLY WITH JUST A SIMPLE PHONE CALL TO OUR OFFICE. YOU CAN CHANGE THE DESIGN OF YOUR SITE AS MUCH AS YOU WANT with no extra charge! UNLIMITED TRAFFIC -- no extra charge! FRONT PAGE EXTENSIONS are FULLY SUPPORTED. A SET UP FEE OF $40.00 APPLIES for FIRST TIME CUSTOMERS. ALL FEES PREPAID IN ADVANCE FOR THE YEAR PLUS A $40.00 SET UP CHARGE. FOR DETAILS CALL 1 888 248 0765 if you are outside the USA, please fax 240 337 8325 Webhosting International _______________________________________________ diffserv mailing list diffserv@ietf.org http://www1.ietf.org/mailman/listinfo/diffserv Archive: http://www2.ietf.org/mail-archive/working-groups/diffserv/current/maillist.html From diffserv-admin@ietf.org Sun Dec 31 12:01: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 SMTP id MAA07983 for ; Sun, 31 Dec 2000 12:01:55 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id LAA02542; Sun, 31 Dec 2000 11:34:56 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id LAA02511 for ; Sun, 31 Dec 2000 11:34:51 -0500 (EST) Received: from warp.seabridge.co.il (warp.seabridgenetworks.com [212.25.127.242]) by ietf.org (8.9.1a/8.9.1a) with SMTP id LAA07912 for ; Sun, 31 Dec 2000 11:34:47 -0500 (EST) Received: from tiger.seabridge.co.il (tiger.seabridge.co.il [172.30.10.101]) by warp.seabridge.co.il (8.9.3/8.9.3) with ESMTP id TAA31547 for ; Sun, 31 Dec 2000 19:55:01 +0200 Received: by tiger.seabridge.co.il with Internet Mail Service (5.5.2650.21) id <45GL36HF>; Sun, 31 Dec 2000 18:31:43 +0200 Message-ID: From: Baruchi Greenberg To: "'diffserv@ietf.org'" Cc: Rachel Hoffman , Amit Meyuhas Date: Sun, 31 Dec 2000 18:31:46 +0200 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C07347.28F108F2" Subject: [Diffserv] Question about the Data Path Table in 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 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_01C07347.28F108F2 Content-Type: text/plain; charset="windows-1255" Hi I will appreciate very much if somebody will clarify the following issue for me. If the ingress diffServDataPathStart of a few ifIndex are configured to the same value I.e. to the same data path, how should we interpret it, is it: * Not valid configuration * Valid, and all those interfaces added together in the same actual data path * Valid, and each of this interfaces has it's own private data path according to the data path representation pointed by the diffServDataPathStart * Valid, and some other meaning ( whet is this meaning ? ) Thanks Baruchi ---------------------------------------------------------------------------- Baruchi Greenberg SEABRIDGE Ltd. E-mail: baruchi.greenberg@SeabridgeNetworks.com Phone: +972-4-9597277 (Ext. 238) Fax: +972-4-9597279 ------_=_NextPart_001_01C07347.28F108F2 Content-Type: text/html; charset="windows-1255" Content-Transfer-Encoding: quoted-printable Question about the Data Path Table in the diffserv = MIB

Hi

I will appreciate very much if = somebody will clarify the following issue for me.

If the ingress   = diffServDataPathStart  of a few  ifIndex are configured to = the same value  I.e. to the same data path,
how should we interpret it,  is = it:

  • Not valid = configuration
  • Valid, and all those interfaces added = together in the same actual data path
  • Valid, and each of this interfaces = has it's own private data path according to the data path = representation pointed by the diffServDataPathStart
  • Valid, and some other = meaning    ( whet is this meaning ? )

Thanks
        Baruchi

---------------------------------------------------------= -------------------
 Baruchi = Greenberg      SEABRIDGE  Ltd.
    = E-mail:   baruchi.greenberg@SeabridgeNetworks.com
    Phone:  = +972-4-9597277 (Ext. 238)  Fax: = +972-4-9597279

------_=_NextPart_001_01C07347.28F108F2-- _______________________________________________ diffserv mailing list diffserv@ietf.org http://www1.ietf.org/mailman/listinfo/diffserv Archive: http://www2.ietf.org/mail-archive/working-groups/diffserv/current/maillist.html