From mailman-owner@ietf.org Sat Apr 1 05:04:06 2000 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA07662 for ; Sat, 1 Apr 2000 05:04: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 FAA20973 for ; Sat, 1 Apr 2000 05:01:47 -0500 (EST) Date: Sat, 1 Apr 2000 05:01:47 -0500 (EST) From: mailman-owner@ietf.org Message-Id: <200004011001.FAA20973@optimus.ietf.org> Subject: ietf.org mailing list memberships reminder To: diffserv-archive@ns.ietf.org X-No-Archive: yes Precedence: bulk X-Mailman-Version: 1.0 Precedence: bulk List-Id: Diffserv Discussion List This is a reminder, sent out once a month, about your ietf.org mailing list memberships. It includes your subscription info and how to use it to change it or unsubscribe from a list. You can visit the URLs to change your membership status or configuration, including unsubscribing, setting digest-style delivery or disabling delivery altogether (e.g., for a vacation), and so on. In addition to the URL interfaces, you can also use email to make such changes. For more info, send a message to the '-request' address of the list (for example, diffserv-request@ietf.org) containing just the word 'help' in the message body, and an email message will be sent to you with instructions. If you have questions, problems, comments, etc, send them to mailman-owner@ietf.org. Thanks! Passwords for diffserv-archive@optimus.ietf.org: List Password // URL ---- -------- diffserv@ietf.org aUvt http://www.ietf.org/mailman/options/diffserv/diffserv-archive@optimus.ietf.org From diffserv-admin@ietf.org Sat Apr 1 21:32:59 2000 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA14014 for ; Sat, 1 Apr 2000 21:32: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 VAA09200; Sat, 1 Apr 2000 21:05: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 VAA09170 for ; Sat, 1 Apr 2000 21:05:23 -0500 (EST) Received: from cis.ohio-state.edu (root@mail.cis.ohio-state.edu [164.107.115.5]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA13768 for ; Sat, 1 Apr 2000 21:07:40 -0500 (EST) Received: from zeta.cis.ohio-state.edu (pjaganna@zeta.cis.ohio-state.edu [164.107.112.46]) by cis.ohio-state.edu (8.9.1/8.9.1) with SMTP id VAA23136 for ; Sat, 1 Apr 2000 21:07:41 -0500 (EST) Message-Id: <200004020207.VAA23136@cis.ohio-state.edu> Date: Sat, 1 Apr 2000 21:07:41 -0500 (EST) From: prasanna jagannathan Reply-To: prasanna jagannathan To: diffserv@ietf.org MIME-Version: 1.0 Content-Type: TEXT/plain; charset=us-ascii Content-MD5: 21fEzKSwjoV6Qe03Hy/99A== X-Mailer: dtmail 1.2.1 CDE Version 1.2.1 SunOS 5.6 sun4u sparc Subject: [Diffserv] standardization of new BA descriptions reg. Sender: diffserv-admin@ietf.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, From the BA definitions draft, is it true that new BA descriptions will be discussed but however will not be standardized ? If so when and who will standardize the new BA descriptions ? or NO more BA descriptions will be discussed ? It would be very helpful if this is made clear. cheers, Prasanna Kumar. _______________________________________________ diffserv mailing list diffserv@ietf.org http://www.ietf.org/mailman/listinfo/diffserv Archive: http://www-nrg.ee.lbl.gov/diff-serv-arch/ From diffserv-admin@ietf.org Sat Apr 1 21: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 ESMTP id VAA15069 for ; Sat, 1 Apr 2000 21:49: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 VAA09289; Sat, 1 Apr 2000 21:15: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 VAA09258 for ; Sat, 1 Apr 2000 21:15:08 -0500 (EST) Received: from cis.ohio-state.edu (root@mail.cis.ohio-state.edu [164.107.115.5]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA13806 for ; Sat, 1 Apr 2000 21:17:25 -0500 (EST) Received: from zeta.cis.ohio-state.edu (pjaganna@zeta.cis.ohio-state.edu [164.107.112.46]) by cis.ohio-state.edu (8.9.1/8.9.1) with SMTP id VAA23376 for ; Sat, 1 Apr 2000 21:17:26 -0500 (EST) Message-Id: <200004020217.VAA23376@cis.ohio-state.edu> Date: Sat, 1 Apr 2000 21:17:26 -0500 (EST) From: prasanna jagannathan Reply-To: prasanna jagannathan To: diffserv@ietf.org MIME-Version: 1.0 Content-Type: TEXT/plain; charset=us-ascii Content-MD5: VEcf+TsATkiBmfVAfO+1CA== X-Mailer: dtmail 1.2.1 CDE Version 1.2.1 SunOS 5.6 sun4u sparc Subject: [Diffserv] standardization of new BA descriptions reg. Sender: diffserv-admin@ietf.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, From the BA definitions draft, is it true that new BA descriptions will be discussed but however will not be standardized ? If so when and who will standardize the new BA descriptions ? or will NO more BA descriptions will be discussed ? It would be very helpful if this is made clear. cheers, Prasanna Kumar. _______________________________________________ diffserv mailing list diffserv@ietf.org http://www.ietf.org/mailman/listinfo/diffserv Archive: http://www-nrg.ee.lbl.gov/diff-serv-arch/ From diffserv-admin@ietf.org Sun Apr 2 18: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 ESMTP id SAA27139 for ; Sun, 2 Apr 2000 18:40:30 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id SAA21072; Sun, 2 Apr 2000 18:07:36 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id SAA21041 for ; Sun, 2 Apr 2000 18:07:32 -0400 (EDT) Received: from omega.cisco.com (omega.cisco.com [171.69.63.141]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA26949 for ; Sun, 2 Apr 2000 18:09:52 -0400 (EDT) Received: from cisco.com (ssh.cisco.com [171.69.10.34]) by omega.cisco.com (8.8.8-Cisco List Logging/8.8.8) with ESMTP id PAA09665; Sun, 2 Apr 2000 15:08:51 -0700 (PDT) Message-ID: <38E7C579.EDB1F6ED@cisco.com> Date: Sun, 02 Apr 2000 15:11:05 -0700 From: Kathleen Nichols X-Mailer: Mozilla 4.61 [en] (Win98; U) X-Accept-Language: en MIME-Version: 1.0 To: prasanna jagannathan CC: diffserv@ietf.org Subject: Re: [Diffserv] standardization of new BA descriptions reg. References: <200004020207.VAA23136@cis.ohio-state.edu> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: diffserv-admin@ietf.org Errors-To: diffserv-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Diffserv Discussion List X-BeenThere: diffserv@ietf.org Content-Transfer-Encoding: 7bit Some of this should be in the Adelaide minutes, but see below: prasanna jagannathan wrote: > > HI, > > From the BA definitions draft, is it true > > that new BA descriptions will be discussed but however will not be > standardized ? > > If so when and who will standardize the new BA descriptions ? > > or > > NO more BA descriptions will be discussed ? It is an item that is open for WG discussion whether to make these Informational or Experimental RFCs, perhaps something that becomes BCP? I put this on a slide at Adelaide, but we didn't discuss this. There was at least one person who felt this type of document isn't necessary. Brian and I (and our AD, I believe) think these descriptions should not be a required part of the standard, but they are meant to give information about how the rules at a DS domain edge plus PHBs can be configured to give particular characteristics. Whether a network operator chooses to use any particular BA is optional. Although there probably needs to be a widely understood description of what is intended by "best effort" (if we keep that term). This is another open discussion topic. I can see where this looks confusing in the charter milestones, but no, it is now an active charter item to work on such descriptions. See section 9.0 of the BA definition draft for our first cut at how we might see this going. Kathie _______________________________________________ diffserv mailing list diffserv@ietf.org http://www.ietf.org/mailman/listinfo/diffserv Archive: http://www-nrg.ee.lbl.gov/diff-serv-arch/ From diffserv-admin@ietf.org Sun Apr 2 23: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 ESMTP id XAA01306 for ; Sun, 2 Apr 2000 23:48:33 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id XAA23030; Sun, 2 Apr 2000 23:15:43 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id XAA22999 for ; Sun, 2 Apr 2000 23:15:39 -0400 (EDT) Received: from crufty.research.bell-labs.com (crufty.research.bell-labs.com [204.178.16.49]) by ietf.org (8.9.1a/8.9.1a) with SMTP id XAA00691 for ; Sun, 2 Apr 2000 23:18:00 -0400 (EDT) Received: from zubin.dnrc.bell-labs.com ([135.180.130.56]) by crufty; Sun Apr 2 23:17:45 EDT 2000 Received: from dnrc.bell-labs.com ([135.254.81.14]) by zubin.dnrc.bell-labs.com (8.9.3/8.9.3) with ESMTP id XAA01211; Sun, 2 Apr 2000 23:17:32 -0400 (EDT) Message-ID: <38E80E19.1414F92B@dnrc.bell-labs.com> Date: Sun, 02 Apr 2000 20:20:57 -0700 From: Grenville Armitage Organization: Bell Laboratories, Lucent Technologies X-Mailer: Mozilla 4.61 [en] (WinNT; U) X-Accept-Language: en MIME-Version: 1.0 To: Kathleen Nichols CC: diffserv@ietf.org Subject: Re: [Diffserv] standardization of new BA descriptions reg. References: <200004020207.VAA23136@cis.ohio-state.edu> <38E7C579.EDB1F6ED@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 Kathleen Nichols wrote: [..] > Although there probably > needs to be a widely understood description of what is > intended by "best effort" (if we keep that term). This is > another open discussion topic. Perhaps "FU" service, as in Fairly Useful? Pronounced "foo", in line with conventional IETF usage of the word to cover imprecise scenarios. (Coincidentally, this is also how the two letters are pronounced in 'snafu', not to suggest Best Effort networks are usually FU'd :-) cheers, gja _______________________________________________ diffserv mailing list diffserv@ietf.org http://www.ietf.org/mailman/listinfo/diffserv Archive: http://www-nrg.ee.lbl.gov/diff-serv-arch/ From diffserv-admin@ietf.org Mon Apr 3 01:03:50 2000 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA02102 for ; Mon, 3 Apr 2000 01:03:49 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id AAA23719; Mon, 3 Apr 2000 00:31:40 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id AAA23694 for ; Mon, 3 Apr 2000 00:31:37 -0400 (EDT) Received: from omega.cisco.com (omega.cisco.com [171.69.63.141]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA01724 for ; Mon, 3 Apr 2000 00:33:58 -0400 (EDT) Received: from cisco.com (ssh.cisco.com [171.69.10.34]) by omega.cisco.com (8.8.8-Cisco List Logging/8.8.8) with ESMTP id VAA00425; Sun, 2 Apr 2000 21:33:26 -0700 (PDT) Message-ID: <38E81F9B.DD208A84@cisco.com> Date: Sun, 02 Apr 2000 21:35:39 -0700 From: Kathleen Nichols X-Mailer: Mozilla 4.61 [en] (Win98; U) X-Accept-Language: en MIME-Version: 1.0 To: Grenville Armitage CC: diffserv@ietf.org Subject: Re: [Diffserv] standardization of new BA descriptions reg. References: <200004020207.VAA23136@cis.ohio-state.edu> <38E7C579.EDB1F6ED@cisco.com> <38E80E19.1414F92B@dnrc.bell-labs.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: diffserv-admin@ietf.org Errors-To: diffserv-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Diffserv Discussion List X-BeenThere: diffserv@ietf.org Content-Transfer-Encoding: 7bit What a great name! Grenville Armitage wrote: > > Kathleen Nichols wrote: > [..] > > Although there probably > > needs to be a widely understood description of what is > > intended by "best effort" (if we keep that term). This is > > another open discussion topic. > > Perhaps "FU" service, as in Fairly Useful? Pronounced "foo", in line > with conventional IETF usage of the word to cover imprecise scenarios. > (Coincidentally, this is also how the two letters are pronounced in > 'snafu', not to suggest Best Effort networks are usually FU'd :-) > > cheers, > gja _______________________________________________ diffserv mailing list diffserv@ietf.org http://www.ietf.org/mailman/listinfo/diffserv Archive: http://www-nrg.ee.lbl.gov/diff-serv-arch/ From diffserv-admin@ietf.org Mon Apr 3 04:45:09 2000 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA14810 for ; Mon, 3 Apr 2000 04:45:09 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id EAA00425; Mon, 3 Apr 2000 04:12:21 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id EAA00395 for ; Mon, 3 Apr 2000 04:12:17 -0400 (EDT) Received: from babar.switch.ch (babar.switch.ch [130.59.4.2]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA14580 for ; Mon, 3 Apr 2000 04:14:38 -0400 (EDT) Received: (from leinen@localhost) by babar.switch.ch (8.9.3+Sun/8.9.3) id KAA17844; Mon, 3 Apr 2000 10:14:36 +0200 (MEST) X-Authentication-Warning: babar.switch.ch: leinen set sender to simon@limmat.switch.ch using -f To: Grenville Armitage Cc: Kathleen Nichols , diffserv@ietf.org Subject: Re: [Diffserv] standardization of new BA descriptions reg. References: <200004020207.VAA23136@cis.ohio-state.edu> <38E7C579.EDB1F6ED@cisco.com> <38E80E19.1414F92B@dnrc.bell-labs.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: Grenville Armitage's message of "Sun, 02 Apr 2000 20:20:57 -0700" Date: 03 Apr 2000 10:14:36 +0200 Message-ID: Lines: 3 User-Agent: Gnus/5.0803 (Gnus v5.8.3) Emacs/20.6 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 So who's going to write down the FU BA definition? -- Simon. _______________________________________________ diffserv mailing list diffserv@ietf.org http://www.ietf.org/mailman/listinfo/diffserv Archive: http://www-nrg.ee.lbl.gov/diff-serv-arch/ From diffserv-admin@ietf.org Mon Apr 3 10:54:06 2000 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA18187 for ; Mon, 3 Apr 2000 10:54:06 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id KAA03582; Mon, 3 Apr 2000 10:08:44 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id KAA03551 for ; Mon, 3 Apr 2000 10:08:40 -0400 (EDT) Received: from slb-smtpout-01.boeing.com (slb-smtpout-01.boeing.com [12.13.237.21]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA17544 for ; Mon, 3 Apr 2000 10:11:01 -0400 (EDT) Received: from slb-av-01.boeing.com ([129.172.13.4]) by slb-smtpout-01.boeing.com (8.9.2/8.8.5-M2) with ESMTP id HAA14690 for ; Mon, 3 Apr 2000 07:10:04 -0700 (PDT) Received: from slb-hub-01.boeing.com (localhost [127.0.0.1]) by slb-av-01.boeing.com (8.9.2/8.9.2) with ESMTP id HAA02215 for ; Mon, 3 Apr 2000 07:09:15 -0700 (PDT) Received: from xch-phlbh-01.he.boeing.com by slb-hub-01.boeing.com with ESMTP; Mon, 3 Apr 2000 07:09:04 -0700 Received: by xch-phlbh-01.he.boeing.com with Internet Mail Service (5.5.2650.21) id ; Mon, 3 Apr 2000 10:09:03 -0400 Message-Id: <4102273CEB77D211869200805FE6F59356EF1A@xch-phl-01.he.boeing.com> From: "Manfredi, Albert E" To: "'Simon Leinen'" Cc: diffserv@ietf.org Subject: RE: [Diffserv] standardization of new BA descriptions reg. Date: Mon, 3 Apr 2000 10:08:57 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: text/plain; charset="iso-8859-1" Sender: diffserv-admin@ietf.org Errors-To: diffserv-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Diffserv Discussion List X-BeenThere: diffserv@ietf.org Simon Leinen wrote: > So who's going to write down the FU BA definition? You mean, the FU BA Requirement? Or FUBAR? Bert albert.e.manfredi@boeing.com _______________________________________________ diffserv mailing list diffserv@ietf.org http://www.ietf.org/mailman/listinfo/diffserv Archive: http://www-nrg.ee.lbl.gov/diff-serv-arch/ From diffserv-admin@ietf.org Mon Apr 3 15:29:01 2000 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA22633 for ; Mon, 3 Apr 2000 15:29:01 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id NAA12199; Mon, 3 Apr 2000 13:47:24 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id NAA12168 for ; Mon, 3 Apr 2000 13:47:20 -0400 (EDT) Received: from omega.cisco.com (omega.cisco.com [171.69.63.141]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA20601 for ; Mon, 3 Apr 2000 13:49:42 -0400 (EDT) Received: from cisco.com (dhcp-o-38-206.cisco.com [171.71.38.206]) by omega.cisco.com (8.8.8-Cisco List Logging/8.8.8) with ESMTP id KAA09179; Mon, 3 Apr 2000 10:48:38 -0700 (PDT) Message-ID: <38E8DA4C.F03D84D7@cisco.com> Date: Mon, 03 Apr 2000 10:52:12 -0700 From: Kathleen Nichols X-Mailer: Mozilla 4.61 [en] (Win98; U) X-Accept-Language: en MIME-Version: 1.0 To: Simon Leinen CC: Grenville Armitage , diffserv@ietf.org Subject: Re: [Diffserv] standardization of new BA descriptions reg. References: <200004020207.VAA23136@cis.ohio-state.edu> <38E7C579.EDB1F6ED@cisco.com> <38E80E19.1414F92B@dnrc.bell-labs.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: diffserv-admin@ietf.org Errors-To: diffserv-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Diffserv Discussion List X-BeenThere: diffserv@ietf.org Content-Transfer-Encoding: 7bit Looks like Grenville volunteered. The question is whether to make it a section in the BA spec doc or a very short stand alone document. Oh, yes, and just when Grenville will finish it... Simon Leinen wrote: > > So who's going to write down the FU BA definition? > -- > Simon. > > _______________________________________________ > diffserv mailing list > diffserv@ietf.org > http://www.ietf.org/mailman/listinfo/diffserv > Archive: http://www-nrg.ee.lbl.gov/diff-serv-arch/ _______________________________________________ diffserv mailing list diffserv@ietf.org http://www.ietf.org/mailman/listinfo/diffserv Archive: http://www-nrg.ee.lbl.gov/diff-serv-arch/ From diffserv-admin@ietf.org Mon Apr 3 17:22:23 2000 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA24993 for ; Mon, 3 Apr 2000 17:22:22 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id QAA13819; Mon, 3 Apr 2000 16:47:41 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id QAA13788 for ; Mon, 3 Apr 2000 16:47:37 -0400 (EDT) Received: from recife.di.ufpe.br ([150.161.2.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA24580 for ; Mon, 3 Apr 2000 16:49:33 -0400 (EDT) Received: from paulista (paulista [150.161.2.50]) by recife.di.ufpe.br (8.9.3+Sun/8.9.3) with SMTP id RAA26580; Mon, 3 Apr 2000 17:38:42 -0300 (EST) Date: Mon, 3 Apr 2000 17:38:42 -0300 (EST) From: Rogerio Andrade X-Sender: rca3@paulista To: Kathleen Nichols cc: Grenville Armitage , diffserv@ietf.org Subject: Re: [Diffserv] standardization of new BA descriptions reg. In-Reply-To: <38E81F9B.DD208A84@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 In Portuguese, this name ("FU..", actualy a slang) is a little bit dirtier :-) []'s Rogerio. Rogerio de Carvalho Andrade Analista de Suporte - Embrapa - DIN mailto:Rogerio.Andrade@Embrapa.br Mestrando em Ciencia da Computacao - UFPE - DI mailto:Rogerio@di.ufpe.br On Sun, 2 Apr 2000, Kathleen Nichols wrote: > > What a great name! > > Grenville Armitage wrote: > > > > Kathleen Nichols wrote: > > [..] > > > Although there probably > > > needs to be a widely understood description of what is > > > intended by "best effort" (if we keep that term). This is > > > another open discussion topic. > > > > Perhaps "FU" service, as in Fairly Useful? Pronounced "foo", in line > > with conventional IETF usage of the word to cover imprecise scenarios. > > (Coincidentally, this is also how the two letters are pronounced in > > 'snafu', not to suggest Best Effort networks are usually FU'd :-) > > > > cheers, > > gja > > _______________________________________________ > diffserv mailing list > diffserv@ietf.org > http://www.ietf.org/mailman/listinfo/diffserv > Archive: http://www-nrg.ee.lbl.gov/diff-serv-arch/ > > _______________________________________________ diffserv mailing list diffserv@ietf.org http://www.ietf.org/mailman/listinfo/diffserv Archive: http://www-nrg.ee.lbl.gov/diff-serv-arch/ From diffserv-admin@ietf.org Mon Apr 3 17:32:19 2000 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA25134 for ; Mon, 3 Apr 2000 17:32:19 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id QAA13954; Mon, 3 Apr 2000 16:59:50 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id QAA13927 for ; Mon, 3 Apr 2000 16:59:46 -0400 (EDT) Received: from sj-msg-core-1.cisco.com (sj-msg-core-1.cisco.com [171.71.163.11]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA24771 for ; Mon, 3 Apr 2000 17:02:07 -0400 (EDT) Received: from proxy3.cisco.com (proxy3.cisco.com [192.31.7.90]) by sj-msg-core-1.cisco.com (8.9.3/8.9.1) with SMTP id OAA05724 for ; Mon, 3 Apr 2000 14:01:41 -0700 (PDT) Received: from c008.sfo.cp.net (c008-h013.c008.sfo.cp.net [209.228.14.202]) by proxy3.cisco.com with SMTP (MailShield v1.5); Mon, 03 Apr 2000 14:01:37 -0700 Received: (cpmta 12255 invoked from network); 3 Apr 2000 13:59:23 -0700 Received: from unknown (HELO narendra) (38.186.47.9) by smtp.campio.com with SMTP; 3 Apr 2000 13:59:23 -0700 X-Sent: 3 Apr 2000 20:59:23 GMT From: "Narendra Dhara" To: Subject: [Diffserv] unsubscribe diffserv Date: Mon, 3 Apr 2000 09:34:47 -0700 Message-ID: <000101bf9db0$193a0160$f401000a@narendra> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook CWS, Build 9.0.2416 (9.0.2910.0) Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2314.1300 X-SMTP-HELO: c008.sfo.cp.net X-SMTP-MAIL-FROM: Narendra@campio.com X-SMAP-Received-From: outside X-SMTP-PEER-INFO: c008-h013.c008.sfo.cp.net [209.228.14.202] Content-Transfer-Encoding: 7bit Sender: diffserv-admin@ietf.org Errors-To: diffserv-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 mailing list diffserv@ietf.org http://www.ietf.org/mailman/listinfo/diffserv Archive: http://www-nrg.ee.lbl.gov/diff-serv-arch/ From diffserv-admin@ietf.org Tue Apr 4 08:38:58 2000 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA01074 for ; Tue, 4 Apr 2000 08:38:58 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id HAA25622; Tue, 4 Apr 2000 07:42:18 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id HAA25589 for ; Tue, 4 Apr 2000 07:42:14 -0400 (EDT) Received: from smtp1.libero.it (smtp1.libero.it [193.70.192.51]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA29549 for ; Tue, 4 Apr 2000 07:44:35 -0400 (EDT) Received: from libero.it (151.29.202.70) by smtp1.libero.it; 4 Apr 2000 13:44:05 +0200 Message-ID: <38E92690.C65DA1B4@libero.it> Date: Tue, 04 Apr 2000 01:17:36 +0200 From: Harrie Hazewinkel X-Mailer: Mozilla 4.6 [en] (Win98; I) X-Accept-Language: en MIME-Version: 1.0 To: DIFFSERV WG Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Subject: [Diffserv] 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 Content-Transfer-Encoding: 7bit HI all, This is regarding the 'diffServClassifierTable' of the DIFF-SERV-MIB. 1) The 'diffServClassifierPrecedence' assigns precedences in the 'diffServClassifierTable'. Looking in the table I see also a 'diffServClassifierNext' column. I believe the naming is confusing. This object does not specify the next classifier, but the datapath element. Should the name not reflect this?? 2) Can 'diffServClassifierNext' object also not point to an next entry in the 'diffServClassifierTable'?? If yes, is it then possible to create invalid combinations of 'diffServClassifierPrecedence' and 'diffServClassifierNext'. For instance, Entry 1: precedence = 10, next = "entry 2" Entry 2: precedence = 11, next = 0.0 "Entry 2" will be first tested as classifier followed by "entry 1". Hist next points to "entry 2" so do we jump back to "entry 2"?? Thanks by advance for a clarification, Harrie O---------------------------------------------------------O mailto:harrie@libero.it http://digilander.iol.it/harrie/ phone: +39-0331974135 postal: via Galilei 13, 21018 Sesto Calende (VA), Italy O---------------------------------------------------------O _______________________________________________ diffserv mailing list diffserv@ietf.org http://www.ietf.org/mailman/listinfo/diffserv Archive: http://www-nrg.ee.lbl.gov/diff-serv-arch/ From diffserv-admin@ietf.org Tue Apr 4 09:58:15 2000 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA03530 for ; Tue, 4 Apr 2000 09:58:15 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id JAA26522; Tue, 4 Apr 2000 09:27:44 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id JAA26491 for ; Tue, 4 Apr 2000 09:27:40 -0400 (EDT) Received: from crufty.research.bell-labs.com (crufty.research.bell-labs.com [204.178.16.49]) by ietf.org (8.9.1a/8.9.1a) with SMTP id JAA02756 for ; Tue, 4 Apr 2000 09:30:02 -0400 (EDT) Received: from zubin.dnrc.bell-labs.com ([135.180.130.56]) by crufty; Tue Apr 4 09:28:25 EDT 2000 Received: from dnrc.bell-labs.com ([135.254.81.22]) by zubin.dnrc.bell-labs.com (8.9.3/8.9.3) with ESMTP id JAA08736; Tue, 4 Apr 2000 09:28:17 -0400 (EDT) Message-ID: <38E9EEC0.F06366E4@dnrc.bell-labs.com> Date: Tue, 04 Apr 2000 06:31:44 -0700 From: Grenville Armitage Organization: Bell Laboratories, Lucent Technologies X-Mailer: Mozilla 4.61 [en] (WinNT; U) X-Accept-Language: en MIME-Version: 1.0 To: Kathleen Nichols CC: diffserv@ietf.org Subject: Re: [Diffserv] standardization of new BA descriptions reg. References: <200004020207.VAA23136@cis.ohio-state.edu> <38E7C579.EDB1F6ED@cisco.com> <38E80E19.1414F92B@dnrc.bell-labs.com> <38E8DA4C.F03D84D7@cisco.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: diffserv-admin@ietf.org Errors-To: diffserv-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Diffserv Discussion List X-BeenThere: diffserv@ietf.org Content-Transfer-Encoding: 7bit I'll do it just after I finish my upcoming work entitled "Men are from RFC2022, Women are from RFC2191".... cheers, gja Kathleen Nichols wrote: > > Looks like Grenville volunteered. The question is whether to make > it a section in the BA spec doc or a very short stand alone document. > Oh, yes, and just when Grenville will finish it... > > Simon Leinen wrote: > > > > So who's going to write down the FU BA definition? > > -- > > Simon. _______________________________________________ diffserv mailing list diffserv@ietf.org http://www.ietf.org/mailman/listinfo/diffserv Archive: http://www-nrg.ee.lbl.gov/diff-serv-arch/ From diffserv-admin@ietf.org Tue Apr 4 14:40:05 2000 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA11878 for ; Tue, 4 Apr 2000 14:40:05 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id OAA29377; Tue, 4 Apr 2000 14:08:41 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id OAA29350 for ; Tue, 4 Apr 2000 14:08:36 -0400 (EDT) Received: from imo24.mx.aol.com (imo24.mx.aol.com [152.163.225.68]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA10989 for ; Tue, 4 Apr 2000 14:10:57 -0400 (EDT) From: Telford001@aol.com Received: from Telford001@aol.com by imo24.mx.aol.com (mail_out_v25.3.) id l.c0.264e119 (4329); Tue, 4 Apr 2000 14:10:08 -0400 (EDT) Message-ID: Date: Tue, 4 Apr 2000 14:10:08 EDT To: diffserv@ietf.org (DIFFSERV WG), rsvp@isi.edu ('rsvp@isi.edu'), issll@lmcs.mit.edu CC: martillo@telfordtools.com MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit X-Mailer: AOL 5.0 for Windows sub 101 Content-Transfer-Encoding: 7bit Subject: [Diffserv] QOS, RSVP, Differential Services, Integrated Services and IPv6 Sender: diffserv-admin@ietf.org Errors-To: diffserv-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Diffserv Discussion List X-BeenThere: diffserv@ietf.org Content-Transfer-Encoding: 7bit I have been thinking about guaranteeing latencies in packet delivery. If a WAN network provides transport for very large packets, and if a reservation is made for video traffic that requires a very low latency at high priority, would it not make sense for intermediate routers to fragment very large packets so that if a priority low latency packet arrived at an intermediate router while that router is transmitting a lower priority packet, the wait before the high priority low latency packet actually begins to transmit would be low because as soon as the reservation had been made, the router limited the transmit MTU size on the relevant interfaces to decrease possible delays through an intermediate router? Joachim Martillo President Telford Tools, Inc. 17 Pleasant Hill Ave. Boston, MA 02126-2813 V 617-298-4107, 298-1617 F 617-298-1745 E martillo@telfordtools.com U http://www.telfordtools.com _______________________________________________ diffserv mailing list diffserv@ietf.org http://www.ietf.org/mailman/listinfo/diffserv Archive: http://www-nrg.ee.lbl.gov/diff-serv-arch/ From diffserv-admin@ietf.org Tue Apr 4 14:54:44 2000 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA12318 for ; Tue, 4 Apr 2000 14:54:44 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id OAA29528; Tue, 4 Apr 2000 14:22:38 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id OAA29497 for ; Tue, 4 Apr 2000 14:22:33 -0400 (EDT) Received: from procyon.pmc-sierra.bc.ca ([134.87.115.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA11389 for ; Tue, 4 Apr 2000 14:24:54 -0400 (EDT) Received: from nt-exchange1.pmc-sierra.bc.ca (nt-exchange1.pmc-sierra.bc.ca [134.87.116.183]) by procyon.pmc-sierra.bc.ca (6.6.6/6.6.6) with ESMTP id LAA15232; Tue, 4 Apr 2000 11:23:53 -0700 (PDT) Received: by nt-exchange1.pmc-sierra.bc.ca with Internet Mail Service (5.5.2650.21) id <2JHG36BM>; Tue, 4 Apr 2000 11:23:54 -0700 Message-ID: <336ECDAFDF7DD311B9E30090277AEE4101B40488@nt-exchange-bby.pmc-sierra.bc.ca> From: Shahram Davari To: "'Telford001@aol.com'" , diffserv@ietf.org, rsvp@isi.edu, issll@lmcs.mit.edu Cc: martillo@telfordtools.com Subject: RE: [Diffserv] QOS, RSVP, Differential Services, Integrated Servi ces and IPv6 Date: Tue, 4 Apr 2000 11:21:18 -0700 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: text/plain; charset="iso-8859-1" Sender: diffserv-admin@ietf.org Errors-To: diffserv-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Diffserv Discussion List X-BeenThere: diffserv@ietf.org It all depends on the link speed. I don't think that this kind of delay in the core is a problem, because the core links are of high speed. For example the delay for a video/audio packet to wait behind an MTU=1500 byte packet in a OC-192 link (~10 Gbit/sec) is close to 1 micro-second. On the other hand if the link speed is in the order of 1 Mbit/sec, then the delay would be almost 10 msec which is significant. But I don't expect a WAN core router to have 1 Mbit/sec link. -Shahram >-----Original Message----- >From: Telford001@aol.com [mailto:Telford001@aol.com] >Sent: Tuesday, April 04, 2000 2:10 PM >To: diffserv@ietf.org; rsvp@isi.edu; issll@lmcs.mit.edu >Cc: martillo@telfordtools.com >Subject: [Diffserv] QOS, RSVP, Differential Services, Integrated >Services and IPv6 > > >I have been thinking about guaranteeing latencies in packet delivery. >If a WAN network provides transport for very large packets, and if a >reservation is made for video traffic that requires a very low latency >at high priority, would it not make sense for intermediate routers to >fragment very large packets so that if a priority low latency packet >arrived at an intermediate router while that router is transmitting >a lower priority packet, the wait before the high priority low latency >packet actually begins to transmit would be low because as soon >as the reservation had been made, the router limited the transmit >MTU size on the relevant interfaces to decrease possible delays >through an intermediate router? > >Joachim Martillo >President >Telford Tools, Inc. >17 Pleasant Hill Ave. >Boston, MA 02126-2813 >V 617-298-4107, 298-1617 >F 617-298-1745 >E martillo@telfordtools.com >U http://www.telfordtools.com > >_______________________________________________ >diffserv mailing list >diffserv@ietf.org >http://www.ietf.org/mailman/listinfo/diffserv >Archive: http://www-nrg.ee.lbl.gov/diff-serv-arch/ > _______________________________________________ diffserv mailing list diffserv@ietf.org http://www.ietf.org/mailman/listinfo/diffserv Archive: http://www-nrg.ee.lbl.gov/diff-serv-arch/ From diffserv-admin@ietf.org Tue Apr 4 15:22:48 2000 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA13330 for ; Tue, 4 Apr 2000 15:22:48 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id OAA29915; Tue, 4 Apr 2000 14:49:57 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id OAA29884 for ; Tue, 4 Apr 2000 14:49:53 -0400 (EDT) Received: from bettina.informatik.uni-bremen.de (bettina.informatik.uni-bremen.de [134.102.224.3]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA12230 for ; Tue, 4 Apr 2000 14:52:13 -0400 (EDT) Received: from dienstmann.informatik.uni-bremen.de (dienstmann.informatik.uni-bremen.de [134.102.224.51]) by bettina.informatik.uni-bremen.de (8.8.7/8.8.7) with ESMTP id UAA00256; Tue, 4 Apr 2000 20:52:09 +0200 (MET DST) Received: (from cabo@localhost) by dienstmann.informatik.uni-bremen.de (8.8.8+Sun/8.8.7) id UAA00650; Tue, 4 Apr 2000 20:52:08 +0200 (MET DST) Date: Tue, 4 Apr 2000 20:52:08 +0200 (MET DST) Message-Id: <200004041852.UAA00650@dienstmann.informatik.uni-bremen.de> From: Carsten Bormann To: Telford001@aol.com Cc: diffserv@ietf.org (DIFFSERV WG), rsvp@ISI.EDU ('rsvp@isi.edu'), issll@lmcs.mit.edu, martillo@telfordtools.com In-Reply-To: References: Subject: [Diffserv] Re: QOS, RSVP, Differential Services, Integrated Services and IPv6 Sender: diffserv-admin@ietf.org Errors-To: diffserv-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Diffserv Discussion List X-BeenThere: diffserv@ietf.org Telford001@aol.com writes: > [...] would it not make sense for intermediate routers to > fragment very large packets so that if a priority low latency packet > arrived at an intermediate router while that router is transmitting > a lower priority packet, [...] Yes, kind of. RFC 2686-2689, products of the ISSLL WG. Good night. Gruesse, Carsten _______________________________________________ diffserv mailing list diffserv@ietf.org http://www.ietf.org/mailman/listinfo/diffserv Archive: http://www-nrg.ee.lbl.gov/diff-serv-arch/ From diffserv-admin@ietf.org Tue Apr 4 16:18:17 2000 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA14969 for ; Tue, 4 Apr 2000 16:18:17 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id PAA00788; Tue, 4 Apr 2000 15:48:08 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id PAA00757 for ; Tue, 4 Apr 2000 15:48:03 -0400 (EDT) Received: from mail-gw.hursley.ibm.com (mail-gw.hursley.ibm.com [194.196.110.15]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA14136 for ; Tue, 4 Apr 2000 15:50:24 -0400 (EDT) Received: from sp3at21.hursley.ibm.com (sp3at21.hursley.ibm.com [9.20.45.21]) by mail-gw.hursley.ibm.com (AIX4.3/UCB 8.8.8/8.8.8) with ESMTP id UAA42356; Tue, 4 Apr 2000 20:49:07 +0100 Received: from hursley.ibm.com (gsine03.us.sine.ibm.com [9.14.6.43]) by sp3at21.hursley.ibm.com (AIX4.2/UCB 8.7/8.7.3) with ESMTP id UAA24062; Tue, 4 Apr 2000 20:49:00 +0100 (BST) Message-ID: <38EA4737.47EFB5DD@hursley.ibm.com> Date: Tue, 04 Apr 2000 14:49:11 -0500 From: Brian E Carpenter Organization: IBM X-Mailer: Mozilla 4.61 [en] (Win98; I) X-Accept-Language: en,fr MIME-Version: 1.0 To: Carsten Bormann CC: Telford001@aol.com, DIFFSERV WG , martillo@telfordtools.com Subject: Re: [Diffserv] Re: QOS, RSVP, Differential Services, Integrated Services and IPv6 References: <200004041852.UAA00650@dienstmann.informatik.uni-bremen.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 Thanks Carsten. On the diffserv list, this correspondence is now closed. Brian Carpenter diffserv co-chair Carsten Bormann wrote: > > Telford001@aol.com writes: > > [...] would it not make sense for intermediate routers to > > fragment very large packets so that if a priority low latency packet > > arrived at an intermediate router while that router is transmitting > > a lower priority packet, [...] > > Yes, kind of. RFC 2686-2689, products of the ISSLL WG. Good night. > > Gruesse, Carsten > > _______________________________________________ > diffserv mailing list > diffserv@ietf.org > http://www.ietf.org/mailman/listinfo/diffserv > Archive: http://www-nrg.ee.lbl.gov/diff-serv-arch/ _______________________________________________ diffserv mailing list diffserv@ietf.org http://www.ietf.org/mailman/listinfo/diffserv Archive: http://www-nrg.ee.lbl.gov/diff-serv-arch/ From diffserv-admin@ietf.org Tue Apr 4 17:31:19 2000 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA17152 for ; Tue, 4 Apr 2000 17:31:19 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id QAA01571; Tue, 4 Apr 2000 16:55:35 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id QAA01540 for ; Tue, 4 Apr 2000 16:55:31 -0400 (EDT) Received: from procyon.pmc-sierra.bc.ca ([134.87.115.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA16104 for ; Tue, 4 Apr 2000 16:57:53 -0400 (EDT) Received: from nt-exchange1.pmc-sierra.bc.ca (nt-exchange1.pmc-sierra.bc.ca [134.87.116.183]) by procyon.pmc-sierra.bc.ca (6.6.6/6.6.6) with ESMTP id NAA27326; Tue, 4 Apr 2000 13:57:52 -0700 (PDT) Received: by nt-exchange1.pmc-sierra.bc.ca with Internet Mail Service (5.5.2650.21) id <2J27SWJ3>; Tue, 4 Apr 2000 13:57:54 -0700 Message-ID: <336ECDAFDF7DD311B9E30090277AEE4101B40489@nt-exchange-bby.pmc-sierra.bc.ca> From: Shahram Davari To: "'Siamack Ayandeh'" , diffserv@ietf.org Subject: RE: [Diffserv] ID-VW-BA, questions on jitter Date: Tue, 4 Apr 2000 13:55:18 -0700 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: text/plain; charset="iso-8859-1" Sender: diffserv-admin@ietf.org Errors-To: diffserv-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Diffserv Discussion List X-BeenThere: diffserv@ietf.org Hi Siamak, Please see my comments below: >-----Original Message----- >From: Siamack Ayandeh [mailto:sayandeh@ascend.com] >Sent: Wednesday, March 22, 2000 3:28 PM >To: diffserv@ietf.org >Subject: [Diffserv] ID-VW-BA, questions on jitter > > >I appreciate if the authors of the draft would comment >on the following factors impacting jitter for virtual wire >behavior aggregate (VW-BA). > >1. Neither RFC 2598 nor VW deal with the jitter induced by inband >control >and routing traffic which may be of higher priority than EF. Relative >to "network" precedence is EF > >a) at a higher priority? >b) Is it of the same priority where each Class Selector CP > is limited to emitting one packet using a token bucket. >c) Or of lower priority. I think a higher priority (than EF) class is acceptable only if it does not emit more than 1 MTU size packet at a time. As you mentioned one way of ensuring this property is probably to shape the higher priority flow to MTU size packets. > >2. Related question is that ID-VW-BA page-5 talks of "EF's priority >queuing model". RFC 2598 does not impose such a requirement. > >3. Given that the MTU size is likely to be >> than (fixed) EF packet >size (S), "n" in equation-1 should be at least 2 x MTU/S. >Leading to the need for fragmentation on slow links carrying EF. >This limits the plausible share of EF to 5% of link bandwidth or >less. > Although your computation is a little off (in fact n > 1 + MTU/S, because MTU/B < S/R - S/B), but your point is valid, and this limitation exist in low speed links. >4. Does this residual service time of (2 x MTU/S) also arise in the >context >of non-prority schedulers such as non-bursty WFQ? Is the new >limit k x 2 xMTU/S where k+1 is the number of scheduling classes. > When WFQ is going to be used to emulate Priority Queing (PQ), the weight assigned to EF should not correspond to its configured rate, but the weight should be much higher ( W >> R/B). For example if 5% of the link is EF, the weight of the EF queue should be set to 90% not 5%. Your point is valid to some extent if improper weight is used. But with proper selection of weight the jitter (due to other queues) can be limited to 1 MTU size packet at output rate. >5. Given that "k" may be of order of 10s if not hundreds (of >class-queues), >what guidelines do authors suggest should be followed in terms of >limiting >"k". > >6. If this limit on "k" is not acceptable, then is EF-PHB and the VW >behavior >aggregate limiting scheduler implementations? > >7. Given that S, the packet size would be different for various EF >flows, the >jitter window discussed in the draft is an upper bound based on the >largest >packet size. How does this bound on jitter window effect the idea of a >virtual wire for flows carrying the smaller packets? > >Many thanks, Siamack > > > > > >_______________________________________________ >diffserv mailing list >diffserv@ietf.org >http://www.ietf.org/mailman/listinfo/diffserv >Archive: http://www-nrg.ee.lbl.gov/diff-serv-arch/ > _______________________________________________ diffserv mailing list diffserv@ietf.org http://www.ietf.org/mailman/listinfo/diffserv Archive: http://www-nrg.ee.lbl.gov/diff-serv-arch/ From diffserv-admin@ietf.org Tue Apr 4 17:32:03 2000 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA17180 for ; Tue, 4 Apr 2000 17:32:03 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id RAA01846; Tue, 4 Apr 2000 17:02:31 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id RAA01815 for ; Tue, 4 Apr 2000 17:02:26 -0400 (EDT) Received: from mail-gw.hursley.ibm.com (mail-gw.hursley.ibm.com [194.196.110.15]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA16363 for ; Tue, 4 Apr 2000 17:04:47 -0400 (EDT) Received: from sp3at21.hursley.ibm.com (sp3at21.hursley.ibm.com [9.20.45.21]) by mail-gw.hursley.ibm.com (AIX4.3/UCB 8.8.8/8.8.8) with ESMTP id WAA59032; Tue, 4 Apr 2000 22:04:14 +0100 Received: from hursley.ibm.com (gsine03.us.sine.ibm.com [9.14.6.43]) by sp3at21.hursley.ibm.com (AIX4.2/UCB 8.7/8.7.3) with ESMTP id WAA30144; Tue, 4 Apr 2000 22:04:13 +0100 (BST) Message-ID: <38EA58D8.1093335D@hursley.ibm.com> Date: Tue, 04 Apr 2000 16:04:24 -0500 From: Brian E Carpenter Organization: IBM X-Mailer: Mozilla 4.61 [en] (Win98; I) X-Accept-Language: en,fr MIME-Version: 1.0 To: Diff Serv CC: Kathleen Nichols Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Subject: [Diffserv] Behavior Aggregates - where next? Sender: diffserv-admin@ietf.org Errors-To: diffserv-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Diffserv Discussion List X-BeenThere: diffserv@ietf.org Content-Transfer-Encoding: 7bit Following the diffserv discussion in Adelaide, we would like to clarify the motivation and direction for the work on BAs. Firstly, to clear out a terminology issue, the formal definition of a BA in RFC 2475 is slightly too restrictive and will require updating. Secondly, the plan is to continue the bottom-up approach adopted from the start of the diffserv work. Having defined a set of PHBs, the next step is to identify and quantify the characteristics that packets belonging to a behavior aggregate will experience as they cross a DS domain. This can result in an edge-to-edge quality of service definition. Enterprise network managers, and many ISPs, need a range of such definitions with numeric parameters, as an aid to deploying diffserv in a useful way. The diffserv WG charter was recently updated in response to this need. Thirdly, the intention now is to clarify draft-ietf-diffserv-ba-def-01.txt in view of the discussion. Also draft-ietf-diffserv-ba-vw-00.txt is a first draft of a "worked example" of a BA and it will undergo more revision. Finally, other BA drafts related to the various standard PHBs, including the Class Selectors, are solicited. Brian and Kathie diffserv co-chairs _______________________________________________ diffserv mailing list diffserv@ietf.org http://www.ietf.org/mailman/listinfo/diffserv Archive: http://www-nrg.ee.lbl.gov/diff-serv-arch/ From diffserv-admin@ietf.org Tue Apr 4 19:05:59 2000 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA20092 for ; Tue, 4 Apr 2000 19:05:59 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id SAA02979; Tue, 4 Apr 2000 18:38:41 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id SAA02957 for ; Tue, 4 Apr 2000 18:38:38 -0400 (EDT) Received: from recife.di.ufpe.br (recife.di.ufpe.br [150.161.2.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA19248 for ; Tue, 4 Apr 2000 18:40:51 -0400 (EDT) Received: from paulista.di.ufpe.br (paulista [150.161.2.50]) by recife.di.ufpe.br (8.9.3+Sun/8.9.3) with ESMTP id TAA13649 for ; Tue, 4 Apr 2000 19:40:15 -0300 (EST) Received: (from cak@localhost) by paulista.di.ufpe.br (8.9.3+Sun/8.9.1) id TAA26121; Tue, 4 Apr 2000 19:40:15 -0300 (EST) Date: Tue, 4 Apr 2000 19:40:15 -0300 (EST) From: Carlos Alberto Kamienski X-Sender: cak@paulista To: diffserv@ietf.org Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Subject: [Diffserv] Status of "A Framework for Differentiated Services" Sender: diffserv-admin@ietf.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 to know the current stauts of the draft "A Framework for Differentiated Services" that wasn't updated since february 1999 and now was removed from the Internet Draft section of diffserv charter. Is the diffserv wg no more interested in this draft ? TIA Carlos _______________________________________________ diffserv mailing list diffserv@ietf.org http://www.ietf.org/mailman/listinfo/diffserv Archive: http://www-nrg.ee.lbl.gov/diff-serv-arch/ From diffserv-admin@ietf.org Tue Apr 4 20:23:43 2000 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA20891 for ; Tue, 4 Apr 2000 20:23:43 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id TAA03715; Tue, 4 Apr 2000 19:54:27 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id TAA03683 for ; Tue, 4 Apr 2000 19:54:23 -0400 (EDT) Received: from dfssl.exchange.microsoft.com ([131.107.88.59]) by ietf.org (8.9.1a/8.9.1a) with SMTP id TAA20671 for ; Tue, 4 Apr 2000 19:56:44 -0400 (EDT) Received: from 127.0.0.1 by dfssl.exchange.microsoft.com (InterScan E-Mail VirusWall NT); Tue, 04 Apr 2000 16:03:24 -0700 (Pacific Daylight Time) Received: by dfssl with Internet Mail Service (5.5.2650.21) id <2JBDY4LT>; Tue, 4 Apr 2000 16:03:24 -0700 Message-ID: <078292D50C98D2118D090008C7E9C6A60C2F4680@STAY.platinum.corp.microsoft.com> From: Yoram Bernet To: Brian E Carpenter , Carsten Bormann Cc: Telford001@aol.com, DIFFSERV WG , martillo@telfordtools.com Subject: RE: [Diffserv] Re: QOS, RSVP, Differential Services, Integrated S ervices and IPv6 Date: Tue, 4 Apr 2000 16:03:10 -0700 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: text/plain Sender: diffserv-admin@ietf.org Errors-To: diffserv-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Diffserv Discussion List X-BeenThere: diffserv@ietf.org > On the diffserv list, this correspondence is now closed. > > Brian Carpenter > diffserv co-chair > So - is that official? Does it need concurrence of both chairs to close a thread? Or are you operating autonomously? Where is the official 'thread closing process doc'd"? :-)... _______________________________________________ diffserv mailing list diffserv@ietf.org http://www.ietf.org/mailman/listinfo/diffserv Archive: http://www-nrg.ee.lbl.gov/diff-serv-arch/ From diffserv-admin@ietf.org Wed Apr 5 08:41:32 2000 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA09295 for ; Wed, 5 Apr 2000 08:41:32 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id IAA14246; Wed, 5 Apr 2000 08:10:08 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id IAA14215 for ; Wed, 5 Apr 2000 08:10:03 -0400 (EDT) Received: from imo-d10.mx.aol.com (imo-d10.mx.aol.com [205.188.157.42]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA08625 for ; Wed, 5 Apr 2000 08:12:28 -0400 (EDT) From: Telford001@aol.com Received: from Telford001@aol.com by imo-d10.mx.aol.com (mail_out_v25.3.) id c.4a.3a564ac (9823); Wed, 5 Apr 2000 08:11:53 -0400 (EDT) Message-ID: <4a.3a564ac.261c8789@aol.com> Date: Wed, 5 Apr 2000 08:11:53 EDT Subject: Re: [Diffserv] QOS, RSVP, Differential Services, Integrated Services and IPv6 To: fred@cisco.com CC: diffserv@ietf.org, rsvp@isi.edu, issll@lmcs.mit.edu, martillo@telfordtools.com MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit X-Mailer: AOL 5.0 for Windows sub 101 Content-Transfer-Encoding: 7bit Sender: diffserv-admin@ietf.org Errors-To: diffserv-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 a message dated 4/5/00 8:04:10 AM Eastern Daylight Time, fred@cisco.com writes: > At 02:10 PM 4/4/00 -0400, Telford001@aol.com wrote: > >I have been thinking about guaranteeing latencies in packet delivery. > >If a WAN network provides transport for very large packets, and if a > >reservation is made for video traffic that requires a very low latency > >at high priority, would it not make sense for intermediate routers to > >fragment very large packets so that if a priority low latency packet > >arrived at an intermediate router while that router is transmitting > >a lower priority packet, the wait before the high priority low latency > >packet actually begins to transmit would be low because as soon > >as the reservation had been made, the router limited the transmit > >MTU size on the relevant interfaces to decrease possible delays > >through an intermediate router? > > In some cases, yes. On relatively low speed lines, some routers use PPP > Multilink, even on a single line, in order to get the fragmentation and > reassembly. VoIP data goes in the PPP IPCP stream, TCP data goes via the ML > LCP. > > The place where this becomes unnecessary is when the speed of the link is > fast enough that the jitter introduced by competing traffic is within > acceptable bounds. That rate is on the order of megabits per second; for > most equipment, T-1 links don't require this. It depends on maximum packet sizes and the number of hops. The size of packets on some of the faster media have become quite large, and supporting jumbograms has been rather common. Latencies can also accumulate. With a sufficient number of hops small delays can cause a lot of jitter. Joachim Martillo President Telford Tools, Inc. 17 Pleasant Hill Ave. Boston, MA 02126-2813 V 617-298-4107, 298-1617 F 617-298-1745 E martillo@telfordtools.com U http://www.telfordtools.com _______________________________________________ diffserv mailing list diffserv@ietf.org http://www.ietf.org/mailman/listinfo/diffserv Archive: http://www-nrg.ee.lbl.gov/diff-serv-arch/ From diffserv-admin@ietf.org Wed Apr 5 08:47:45 2000 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA09319 for ; Wed, 5 Apr 2000 08:47:45 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id IAA14161; Wed, 5 Apr 2000 08:01:34 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id IAA14130 for ; Wed, 5 Apr 2000 08:01:30 -0400 (EDT) Received: from sj-mailhub-3.cisco.com (sj-mailhub-3.cisco.com [171.68.224.215]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA08566 for ; Wed, 5 Apr 2000 08:03:55 -0400 (EDT) Received: from rhino (rhino.cisco.com [172.20.9.57]) by sj-mailhub-3.cisco.com (8.9.1a/8.9.1) with ESMTP id FAA02913; Wed, 5 Apr 2000 05:03:34 -0700 (PDT) Received: from p7020-img-nt.cisco.com (fred-hm-dhcp1.cisco.com [171.69.128.116]) by rhino (SMI-8.6/CISCO.WS.1.1) with ESMTP id FAA01741; Wed, 5 Apr 2000 05:07:31 -0700 Message-Id: <4.3.0.20000405045848.01e03c50@flipper.cisco.com> X-Sender: fred@flipper.cisco.com X-Mailer: QUALCOMM Windows Eudora Version 4.3 Date: Wed, 05 Apr 2000 05:02:00 -0700 To: Telford001@aol.com From: Fred Baker Subject: Re: [Diffserv] QOS, RSVP, Differential Services, Integrated Services and IPv6 Cc: diffserv@ietf.org (DIFFSERV WG), rsvp@isi.edu ('rsvp@isi.edu'), issll@lmcs.mit.edu, martillo@telfordtools.com In-Reply-To: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: diffserv-admin@ietf.org Errors-To: diffserv-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Diffserv Discussion List X-BeenThere: diffserv@ietf.org At 02:10 PM 4/4/00 -0400, Telford001@aol.com wrote: >I have been thinking about guaranteeing latencies in packet delivery. >If a WAN network provides transport for very large packets, and if a >reservation is made for video traffic that requires a very low latency >at high priority, would it not make sense for intermediate routers to >fragment very large packets so that if a priority low latency packet >arrived at an intermediate router while that router is transmitting >a lower priority packet, the wait before the high priority low latency >packet actually begins to transmit would be low because as soon >as the reservation had been made, the router limited the transmit >MTU size on the relevant interfaces to decrease possible delays >through an intermediate router? In some cases, yes. On relatively low speed lines, some routers use PPP Multilink, even on a single line, in order to get the fragmentation and reassembly. VoIP data goes in the PPP IPCP stream, TCP data goes via the ML LCP. The place where this becomes unnecessary is when the speed of the link is fast enough that the jitter introduced by competing traffic is within acceptable bounds. That rate is on the order of megabits per second; for most equipment, T-1 links don't require this. _______________________________________________ diffserv mailing list diffserv@ietf.org http://www.ietf.org/mailman/listinfo/diffserv Archive: http://www-nrg.ee.lbl.gov/diff-serv-arch/ From diffserv-admin@ietf.org Wed Apr 5 09:03:36 2000 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA09517 for ; Wed, 5 Apr 2000 09:03:36 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id IAA14499; Wed, 5 Apr 2000 08:23:26 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id IAA14471 for ; Wed, 5 Apr 2000 08:23:22 -0400 (EDT) Received: from kickme.cisco.com (kickme.cisco.com [198.92.30.42]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA08777 for ; Wed, 5 Apr 2000 08:25:46 -0400 (EDT) Received: from rhino (rhino.cisco.com [172.20.9.57]) by kickme.cisco.com (8.9.1a/8.9.1) with ESMTP id FAA02706; Wed, 5 Apr 2000 05:23:30 -0700 (PDT) Received: from p7020-img-nt.cisco.com (fred-hm-dhcp1.cisco.com [171.69.128.116]) by rhino (SMI-8.6/CISCO.WS.1.1) with ESMTP id FAA01754; Wed, 5 Apr 2000 05:29:23 -0700 Message-Id: <4.3.0.20000405052259.00db7760@flipper.cisco.com> X-Sender: fred@flipper.cisco.com X-Mailer: QUALCOMM Windows Eudora Version 4.3 Date: Wed, 05 Apr 2000 05:24:12 -0700 To: Telford001@aol.com From: Fred Baker Subject: Re: [Diffserv] QOS, RSVP, Differential Services, Integrated Services and IPv6 Cc: diffserv@ietf.org, rsvp@isi.edu, issll@lmcs.mit.edu, martillo@telfordtools.com In-Reply-To: <4a.3a564ac.261c8789@aol.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 think we're in violent agreement. At some relatively low speed, the PPP Multilink procedure can be used to fragment competing traffic. At some not-much-higher speed, it becomes irrelevant. We're dickering about the magic number. _______________________________________________ diffserv mailing list diffserv@ietf.org http://www.ietf.org/mailman/listinfo/diffserv Archive: http://www-nrg.ee.lbl.gov/diff-serv-arch/ From diffserv-admin@ietf.org Wed Apr 5 09:26:09 2000 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA09865 for ; Wed, 5 Apr 2000 09:26:09 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id IAA14890; Wed, 5 Apr 2000 08:50:41 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id IAA14861 for ; Wed, 5 Apr 2000 08:50:37 -0400 (EDT) Received: from mex.italtel.it (mex.italtel.it [138.132.117.4]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA09364; Wed, 5 Apr 2000 08:52:58 -0400 (EDT) Received: .(iltws72 [138.132.52.82]) by mex.italtel.it (8.9.0/8.9.0) with ESMTP id OAA24004 Received: .(localhost [127.0.0.1]) by iltws72.settimo.italtel.it (8.9.1a/8.9.1) with ESMTP id OAA23916 Received: from ic8u32.settimo.italtel.it (ic8u32.settimo.italtel.it [138.132.1.1]) by mix.italtel.it (8.9.3/8.9.3) with SMTP id OAA23724; Wed, 5 Apr 2000 14:51:19 +0200 (MET DST) Received: by ic8u32.settimo.italtel.it id AA09770; Wed, 5 Apr 2000 15:09:43 +0200 Received: from iltws09.settimo.italtel.it by ilt9h01.settimo.italtel.it with SMTP (1.38.193.5/16.2) id AA23257; Wed, 5 Apr 2000 14:42:16 +0200 Message-Id: <38EB376C.3F4943F3@icn.siemens.it> Date: Wed, 05 Apr 2000 14:54:05 +0200 From: Jonathan Buschmann Reply-To: Jonathan.Buschmann@icn.siemens.it X-Mailer: Mozilla 4.72 [en] (X11; U; SunOS 5.7 sun4u) X-Accept-Language: en Mime-Version: 1.0 To: Alex Zinin Cc: diffserv@ietf.org, ietf-web@ietf.org Subject: Re: [Diffserv] Mail-list management References: <13745.000327@amt.ru> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: diffserv-admin@ietf.org Errors-To: diffserv-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Diffserv Discussion List X-BeenThere: diffserv@ietf.org Content-Transfer-Encoding: 7bit Alex Zinin wrote: > Hello, > > I can't access the address specified in the mailman's help > output for some reason: > > http://www.ietf.org/mailman/listinfo/diffserv > > Does anyone know the correct URL? > > Alex. > > _______________________________________________ > diffserv mailing list > diffserv@ietf.org > http://www.ietf.org/mailman/listinfo/diffserv > Archive: http://www-nrg.ee.lbl.gov/diff-serv-arch/ Alex, Discovered this recently. www.ietf.org is an alias for two names www1.ietf.org (the "Real" one in reston) and a mirror www2.ietf.org. If DNS resoves your name to the www2 IP address, mailman won't work (apparantly it's not mirrored/installed on the other machine). So just use www1.ietf.org to access mailman. jonathan _______________________________________________ diffserv mailing list diffserv@ietf.org http://www.ietf.org/mailman/listinfo/diffserv Archive: http://www-nrg.ee.lbl.gov/diff-serv-arch/ From diffserv-admin@ietf.org Wed Apr 5 10:55:22 2000 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA11011 for ; Wed, 5 Apr 2000 10:55:22 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id KAA16071; Wed, 5 Apr 2000 10:12:52 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id KAA16048 for ; Wed, 5 Apr 2000 10:12:48 -0400 (EDT) Received: from imo16.mx.aol.com (imo16.mx.aol.com [152.163.225.6]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA10434 for ; Wed, 5 Apr 2000 10:15:12 -0400 (EDT) From: Telford001@aol.com Received: from Telford001@aol.com by imo16.mx.aol.com (mail_out_v25.3.) id c.37.368082d (3971); Wed, 5 Apr 2000 10:14:29 -0400 (EDT) Message-ID: <37.368082d.261ca444@aol.com> Date: Wed, 5 Apr 2000 10:14:28 EDT Subject: Re: [Diffserv] QOS, RSVP, Differential Services, Integrated Services and IPv6 To: fred@cisco.com CC: diffserv@ietf.org, rsvp@isi.edu, issll@lmcs.mit.edu, martillo@telfordtools.com MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit X-Mailer: AOL 5.0 for Windows sub 101 Content-Transfer-Encoding: 7bit Sender: diffserv-admin@ietf.org Errors-To: diffserv-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 a message dated 4/5/00 8:40:19 AM Eastern Daylight Time, fred@cisco.com writes: > In some cases, yes. On relatively low speed lines, some routers use PPP > Multilink, even on a single line, in order to get the fragmentation and > reassembly. VoIP data goes in the PPP IPCP stream, TCP data goes via the ML > LCP. Of course, such a procedure would not work for FR unless PPP were run over the FR or on a lot of the new wireless technologies. > The place where this becomes unnecessary is when the speed of the link is > fast enough that the jitter introduced by competing traffic is within > acceptable bounds. That rate is on the order of megabits per second; for > most equipment, T-1 links don't require this. Not obvious. Joachim Martillo President Telford Tools, Inc. 17 Pleasant Hill Ave. Boston, MA 02126-2813 V 617-298-4107, 298-1617 F 617-298-1745 E martillo@telfordtools.com U http://www.telfordtools.com _______________________________________________ diffserv mailing list diffserv@ietf.org http://www.ietf.org/mailman/listinfo/diffserv Archive: http://www-nrg.ee.lbl.gov/diff-serv-arch/ From diffserv-admin@ietf.org Wed Apr 5 13:16:08 2000 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA13153 for ; Wed, 5 Apr 2000 13:16:07 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id MAA17779; Wed, 5 Apr 2000 12:50:47 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id MAA17748 for ; Wed, 5 Apr 2000 12:50:42 -0400 (EDT) Received: from mail-gw.hursley.ibm.com (mail-gw.hursley.ibm.com [194.196.110.15]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA12787 for ; Wed, 5 Apr 2000 12:53:05 -0400 (EDT) Received: from sp3at21.hursley.ibm.com (sp3at21.hursley.ibm.com [9.20.45.21]) by mail-gw.hursley.ibm.com (AIX4.3/UCB 8.8.8/8.8.8) with ESMTP id RAA18558; Wed, 5 Apr 2000 17:52:14 +0100 Received: from hursley.ibm.com (gsine02.us.sine.ibm.com [9.14.6.42]) by sp3at21.hursley.ibm.com (AIX4.2/UCB 8.7/8.7.3) with ESMTP id RAA30062; Wed, 5 Apr 2000 17:51:52 +0100 (BST) Message-ID: <38EB6F09.FE7D01B8@hursley.ibm.com> Date: Wed, 05 Apr 2000 11:51:21 -0500 From: Brian E Carpenter Organization: IBM X-Mailer: Mozilla 4.61 [en] (Win98; I) X-Accept-Language: en,fr MIME-Version: 1.0 To: Carlos Alberto Kamienski CC: diffserv@ietf.org Subject: Re: [Diffserv] Status of "A Framework for Differentiated Services" 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 Correct. It failed to get updated and we removed it from the charter. Brian Carpenter diffserv co-chair Carlos Alberto Kamienski wrote: > > I'd like to know the current stauts of the draft > "A Framework for Differentiated > Services" that wasn't updated since february 1999 and now was removed from > the Internet Draft section of diffserv charter. > Is the diffserv wg no more interested in this draft ? > > TIA > > Carlos > > _______________________________________________ > diffserv mailing list > diffserv@ietf.org > http://www.ietf.org/mailman/listinfo/diffserv > Archive: http://www-nrg.ee.lbl.gov/diff-serv-arch/ _______________________________________________ diffserv mailing list diffserv@ietf.org http://www.ietf.org/mailman/listinfo/diffserv Archive: http://www-nrg.ee.lbl.gov/diff-serv-arch/ From diffserv-admin@ietf.org Wed Apr 5 13:23:39 2000 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA13299 for ; Wed, 5 Apr 2000 13:23:39 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id MAA17670; Wed, 5 Apr 2000 12:41:14 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id MAA17640 for ; Wed, 5 Apr 2000 12:41:10 -0400 (EDT) Received: from mailgate.fore.com (mailgate.fore.com [169.144.68.6]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA12698 for ; Wed, 5 Apr 2000 12:43:34 -0400 (EDT) Received: from mailman.fore.com (mailman.fore.com [169.144.2.12]) by mailgate.fore.com (8.9.3/8.9.3) with ESMTP id MAA26912; Wed, 5 Apr 2000 12:41:31 -0400 (EDT) Received: from fore.com (dcharlap-pc.dc.fore.com [169.144.136.107]) by mailman.fore.com (8.9.3/8.9.3) with ESMTP id MAA09889; Wed, 5 Apr 2000 12:41:05 -0400 (EDT) Message-ID: <38EB6CA4.4C40C53F@fore.com> Date: Wed, 05 Apr 2000 12:41:08 -0400 From: David Charlap X-Mailer: Mozilla 4.7 [en] (WinNT; U) X-Accept-Language: en-US,en-GB,en MIME-Version: 1.0 To: Telford001@aol.com CC: fred@cisco.com, diffserv@ietf.org, rsvp@ISI.EDU, issll@lmcs.mit.edu, martillo@telfordtools.com Subject: Re: [Diffserv] QOS, RSVP, Differential Services, Integrated Servicesand IPv6 References: <4a.3a564ac.261c8789@aol.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 Telford001@aol.com wrote: >>> >>> I have been thinking about guaranteeing latencies in packet >>> delivery. If a WAN network provides transport for very large >>> packets, and if a reservation is made for video traffic that >>> requires a very low latency at high priority, would it not make >>> sense for intermediate routers to fragment very large packets so >>> that if a priority low latency packet arrived at an intermediate >>> router while that router is transmitting a lower priority packet, >>> the wait before the high priority low latency packet actually begins >>> to transmit would be low because as soon as the reservation had been >>> made, the router limited the transmit MTU size on the relevant >>> interfaces to decrease possible delays through an intermediate >>> router? >> >> In some cases, yes. On relatively low speed lines, some routers use >> PPP Multilink, even on a single line, in order to get the >> fragmentation and reassembly. VoIP data goes in the PPP IPCP stream, >> TCP data goes via the ML LCP. >> >> The place where this becomes unnecessary is when the speed of the >> link is fast enough that the jitter introduced by competing traffic >> is within acceptable bounds. That rate is on the order of megabits >> per second; for most equipment, T-1 links don't require this. > > It depends on maximum packet sizes and the number of hops. The size > of packets on some of the faster media have become quite large, and > supporting jumbograms has been rather common. Latencies can also > accumulate. With a sufficient number of hops small delays can cause a > lot of jitter. Yes. Let's take two examples here. A 9K frame transmitted over Gigabit ethernet (where 9K frames are commonly used) and a 1500-byte frame transmitted over a T1 line. If we ignore layer-1 and layer-2 bits and use an approximation of the speed, we can get the approximate time it takes to transmit a frame. 72us for the GigE frame (9KB = 72,000 bits divided by 1,000,000,000 bits/s), and 8ms for the T1 frame (1500 bytes = 12,000 bits divided by 1,500,000 bits/s). Neither of these delays are too bad. Most apps can deal with even an 8ms delay. But these delays may add up as the packet traverses many switches. Imagine a worst-case scenario where a low-latency packet goes through 30 switches and is queued for transmission just as a maximal-size packet has begun transmitting. This creates the maximal queuing delay - generating the worst-case for jitter. On the GigE network, the cumulative delay from being behind a 9K frame at every hop is 2160us - or approximately 2.2ms. This is probably acceptible. Especially when you consider that it's still significantly less than the delay caused by one 1500 byte frame on the T1 network. On the other hand, with the T1 switches, the cumulative delay from being behind a 1500 byte frame at each hop becomes 240ms - nearly 1/4 second. This may well be unacceptible for some applications. One possible solution (as was already proposed) is fragmentation to smaller sizes. Of course, this introduces other problems as well. (Incidentally, this is one of the reasons why ATM can enforce delay and jitter constraints over slow lines. The segmentation and reassembly of frames into cells reduces the transmission delay of a single cell down to 283us over a T1 line, or 8.4ms over a worst-case 30-hop route.) -- David _______________________________________________ diffserv mailing list diffserv@ietf.org http://www.ietf.org/mailman/listinfo/diffserv Archive: http://www-nrg.ee.lbl.gov/diff-serv-arch/ From diffserv-admin@ietf.org Wed Apr 5 13:40:54 2000 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA13608 for ; Wed, 5 Apr 2000 13:40:54 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id NAA18088; Wed, 5 Apr 2000 13:10:32 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id NAA18059 for ; Wed, 5 Apr 2000 13:10:28 -0400 (EDT) Received: from mail-gw.hursley.ibm.com (mail-gw.hursley.ibm.com [194.196.110.15]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA13127 for ; Wed, 5 Apr 2000 13:12:51 -0400 (EDT) Received: from sp3at21.hursley.ibm.com (sp3at21.hursley.ibm.com [9.20.45.21]) by mail-gw.hursley.ibm.com (AIX4.3/UCB 8.8.8/8.8.8) with ESMTP id SAA51506; Wed, 5 Apr 2000 18:12:20 +0100 Received: from hursley.ibm.com (gsine02.us.sine.ibm.com [9.14.6.42]) by sp3at21.hursley.ibm.com (AIX4.2/UCB 8.7/8.7.3) with ESMTP id SAA25474; Wed, 5 Apr 2000 18:12:19 +0100 (BST) Message-ID: <38EB73F8.CC5B0C56@hursley.ibm.com> Date: Wed, 05 Apr 2000 12:12:24 -0500 From: Brian E Carpenter Organization: IBM X-Mailer: Mozilla 4.61 [en] (Win98; I) X-Accept-Language: en,fr MIME-Version: 1.0 To: Jonathan.Buschmann@icn.siemens.it CC: diffserv@ietf.org Subject: Re: [Diffserv] Mail-list management References: <13745.000327@amt.ru> <38EB376C.3F4943F3@icn.siemens.it> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: diffserv-admin@ietf.org Errors-To: diffserv-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Diffserv Discussion List X-BeenThere: diffserv@ietf.org Content-Transfer-Encoding: 7bit Jonathan, Thanks for the diagnostic. I've asked the IETF secretariat to get this fixed ASAP. Brian Carpenter diffserv co-chair Jonathan Buschmann wrote: > > Alex Zinin wrote: > > > Hello, > > > > I can't access the address specified in the mailman's help > > output for some reason: > > > > http://www.ietf.org/mailman/listinfo/diffserv > > > > Does anyone know the correct URL? > > > > Alex. > > > > _______________________________________________ > > diffserv mailing list > > diffserv@ietf.org > > http://www.ietf.org/mailman/listinfo/diffserv > > Archive: http://www-nrg.ee.lbl.gov/diff-serv-arch/ > > Alex, > > Discovered this recently. > www.ietf.org is an alias for two names www1.ietf.org (the "Real" one in > reston) and a mirror www2.ietf.org. > If DNS resoves your name to the www2 IP address, mailman won't work > (apparantly it's not mirrored/installed on the other machine). So just > use www1.ietf.org to access mailman. > > jonathan > > _______________________________________________ > diffserv mailing list > diffserv@ietf.org > http://www.ietf.org/mailman/listinfo/diffserv > Archive: http://www-nrg.ee.lbl.gov/diff-serv-arch/ _______________________________________________ diffserv mailing list diffserv@ietf.org http://www.ietf.org/mailman/listinfo/diffserv Archive: http://www-nrg.ee.lbl.gov/diff-serv-arch/ From diffserv-admin@ietf.org Wed Apr 5 13:46:08 2000 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA13648 for ; Wed, 5 Apr 2000 13:46:08 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id NAA18280; Wed, 5 Apr 2000 13:20:01 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id NAA18250 for ; Wed, 5 Apr 2000 13:19:56 -0400 (EDT) Received: from mail-gw.hursley.ibm.com (mail-gw.hursley.ibm.com [194.196.110.15]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA13287 for ; Wed, 5 Apr 2000 13:22:18 -0400 (EDT) Received: from sp3at21.hursley.ibm.com (sp3at21.hursley.ibm.com [9.20.45.21]) by mail-gw.hursley.ibm.com (AIX4.3/UCB 8.8.8/8.8.8) with ESMTP id SAA17286; Wed, 5 Apr 2000 18:21:46 +0100 Received: from hursley.ibm.com (gsine02.us.sine.ibm.com [9.14.6.42]) by sp3at21.hursley.ibm.com (AIX4.2/UCB 8.7/8.7.3) with ESMTP id SAA25470; Wed, 5 Apr 2000 18:21:43 +0100 (BST) Message-ID: <38EB7629.88F11FF8@hursley.ibm.com> Date: Wed, 05 Apr 2000 12:21:45 -0500 From: Brian E Carpenter Organization: IBM X-Mailer: Mozilla 4.61 [en] (Win98; I) X-Accept-Language: en,fr MIME-Version: 1.0 To: Yoram Bernet CC: DIFFSERV WG Subject: Re: [Diffserv] Re: QOS, RSVP, Differential Services, Integrated Services and IPv6 References: <078292D50C98D2118D090008C7E9C6A60C2F4680@STAY.platinum.corp.microsoft.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: diffserv-admin@ietf.org Errors-To: diffserv-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Diffserv Discussion List X-BeenThere: diffserv@ietf.org Content-Transfer-Encoding: 7bit Yoram, The topic is outside the diffserv charter, but clearly related to ISSLL. RFC 2418 says "Moderate the WG email list The Chair should attempt to ensure that the discussions on this list are relevant..." Kathie and I share this job. Brian Yoram Bernet wrote: > > > On the diffserv list, this correspondence is now closed. > > > > Brian Carpenter > > diffserv co-chair > > > > So - is that official? Does it need concurrence of both chairs to close a > thread? Or are you operating autonomously? Where is the official 'thread > closing process doc'd"? :-)... _______________________________________________ diffserv mailing list diffserv@ietf.org http://www.ietf.org/mailman/listinfo/diffserv Archive: http://www-nrg.ee.lbl.gov/diff-serv-arch/ From diffserv-admin@ietf.org Wed Apr 5 21:13:10 2000 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA18523 for ; Wed, 5 Apr 2000 21:13:10 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id UAA22533; Wed, 5 Apr 2000 20:42:35 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id UAA22502 for ; Wed, 5 Apr 2000 20:42:31 -0400 (EDT) Received: from usc.edu (root@usc.edu [128.125.253.136]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA18262 for ; Wed, 5 Apr 2000 20:44:54 -0400 (EDT) Received: from aludra.usc.edu (demir@aludra.usc.edu [128.125.19.184]) by usc.edu (8.9.3.1/8.9.3/usc) with ESMTP id RAA19687 for ; Wed, 5 Apr 2000 17:44:53 -0700 (PDT) Received: from localhost (demir@localhost) by aludra.usc.edu (8.9.3.1/8.9.3/usc) with ESMTP id RAA22028 for ; Wed, 5 Apr 2000 17:44:52 -0700 (PDT) Date: Wed, 5 Apr 2000 17:44:52 -0700 (PDT) From: demir To: Diff Serv Subject: [Diffserv] Relationship between DS domain and Routing domain 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 all, Is there any assumption on relationship between DS domain and routing domain AS (autonomous system), such as an AS can have one or more DS domain, or a DS domain can be composed of one or more AS, etc...? Alper K. Demir _______________________________________________ diffserv mailing list diffserv@ietf.org http://www1.ietf.org/mailman/listinfo/diffserv Archive: http://www-nrg.ee.lbl.gov/diff-serv-arch/ From diffserv-admin@ietf.org Wed Apr 5 21: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 ESMTP id VAA18688 for ; Wed, 5 Apr 2000 21:26:18 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id UAA22676; Wed, 5 Apr 2000 20:58:35 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id UAA22645 for ; Wed, 5 Apr 2000 20:58:31 -0400 (EDT) Received: from omega.cisco.com (omega.cisco.com [171.69.63.141]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA18391 for ; Wed, 5 Apr 2000 21:00:53 -0400 (EDT) Received: from cisco.com (kmn-isdn1.cisco.com [171.70.228.26]) by omega.cisco.com (8.8.8-Cisco List Logging/8.8.8) with ESMTP id RAA29971; Wed, 5 Apr 2000 17:58:20 -0700 (PDT) Message-ID: <38EBE1DD.651DAB19@cisco.com> Date: Wed, 05 Apr 2000 18:01:17 -0700 From: Kathleen Nichols X-Mailer: Mozilla 4.61 [en] (Win98; U) X-Accept-Language: en MIME-Version: 1.0 To: demir CC: Diff Serv Subject: Re: [Diffserv] Relationship between DS domain and Routing domain References: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: diffserv-admin@ietf.org Errors-To: diffserv-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Diffserv Discussion List X-BeenThere: diffserv@ietf.org Content-Transfer-Encoding: 7bit demir wrote: > > Hi all, > Is there any assumption on relationship between DS domain and routing > domain AS (autonomous system), such as an AS can have one or more DS > domain, or a DS domain can be composed of one or more AS, etc...? > The RFC 2475 definition: "DS domain a DS-capable domain; a contiguous set of nodes which operate with a common set of service provisioning policies and PHB definitions." So, the "common set of service provisioning policies" leads me to say that a DS domain would NOT be composed of one or more ASs (not very "autonomous" to share provisioning, eh?) but that an AS may be composed of one or more DS domains since one might provision different subnetworks according to different rules. I suppose there might even be different PHB definitions within different DS domains of the same AS, though that would seem more likely. The "common set of service provisioning policies" is ensured by the DS boundary. Kathie _______________________________________________ diffserv mailing list diffserv@ietf.org http://www1.ietf.org/mailman/listinfo/diffserv Archive: http://www-nrg.ee.lbl.gov/diff-serv-arch/ From diffserv-admin@ietf.org Wed Apr 5 22:44:10 2000 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA21508 for ; Wed, 5 Apr 2000 22:44:10 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id WAA23595; Wed, 5 Apr 2000 22:20:52 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id WAA23557 for ; Wed, 5 Apr 2000 22:20:48 -0400 (EDT) Received: from sj-mailhub-3.cisco.com (sj-mailhub-3.cisco.com [171.68.224.215]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA20314 for ; Wed, 5 Apr 2000 22:23:11 -0400 (EDT) Received: from van-u5.cisco.com (van-u5.cisco.com [171.70.70.96]) by sj-mailhub-3.cisco.com (8.9.1a/8.9.1) with ESMTP id TAA21257 for ; Wed, 5 Apr 2000 19:23:58 -0700 (PDT) Received: from localhost (van@localhost) by van-u5.cisco.com (8.8.8+Sun/8.8.8) with ESMTP id TAA17102 for ; Wed, 5 Apr 2000 19:16:27 -0700 (PDT) Message-Id: <200004060216.TAA17102@van-u5.cisco.com> To: diffserv@ietf.org Date: Wed, 05 Apr 2000 19:16:26 -0700 From: Van Jacobson Subject: [Diffserv] the diffserv mail archive ... Sender: diffserv-admin@ietf.org Errors-To: diffserv-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Diffserv Discussion List X-BeenThere: diffserv@ietf.org ... should now be up to date & working again. If anyone finds otherwise please let me know. Thanks. - van@cisco.com _______________________________________________ diffserv mailing list diffserv@ietf.org http://www1.ietf.org/mailman/listinfo/diffserv Archive: http://www-nrg.ee.lbl.gov/diff-serv-arch/ From diffserv-admin@ietf.org Thu Apr 6 00:11:20 2000 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA22581 for ; Thu, 6 Apr 2000 00:11:20 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id XAA24391; Wed, 5 Apr 2000 23:47:14 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id XAA24361 for ; Wed, 5 Apr 2000 23:47:10 -0400 (EDT) Received: from hubbub.cisco.com (hubbub.cisco.com [171.69.11.2]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA22354 for ; Wed, 5 Apr 2000 23:49:33 -0400 (EDT) Received: from van-u5.cisco.com (van-u5.cisco.com [171.70.70.96]) by hubbub.cisco.com (8.8.5-Cisco.2-SunOS.5.5.1.sun4/CISCO.GATE.1.1) with ESMTP id UAA27262 for ; Wed, 5 Apr 2000 20:49:05 -0700 (PDT) Received: from localhost (van@localhost) by van-u5.cisco.com (8.8.8+Sun/8.8.8) with ESMTP id UAA17681 for ; Wed, 5 Apr 2000 20:48:31 -0700 (PDT) Message-Id: <200004060348.UAA17681@van-u5.cisco.com> To: diffserv@ietf.org Date: Wed, 05 Apr 2000 20:48:31 -0700 From: Van Jacobson Subject: [Diffserv] the diffserv mail archive ... Sender: diffserv-admin@ietf.org Errors-To: diffserv-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Diffserv Discussion List X-BeenThere: diffserv@ietf.org ... should be up to date & working again. If anyone finds otherwise please let me know. Thanks. - van@cisco.com _______________________________________________ diffserv mailing list diffserv@ietf.org http://www1.ietf.org/mailman/listinfo/diffserv Archive: http://www-nrg.ee.lbl.gov/diff-serv-arch/ From diffserv-admin@ietf.org Thu Apr 6 00:45:18 2000 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA22952 for ; Thu, 6 Apr 2000 00:45:18 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id AAA24740; Thu, 6 Apr 2000 00:20:08 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id AAA24710 for ; Thu, 6 Apr 2000 00:20:05 -0400 (EDT) Received: from kickme.cisco.com (kickme.cisco.com [198.92.30.42]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA22652 for ; Thu, 6 Apr 2000 00:22:29 -0400 (EDT) Received: from van-u5.cisco.com (van-u5.cisco.com [171.70.70.96]) by kickme.cisco.com (8.9.1a/8.9.1) with ESMTP id VAA15930 for ; Wed, 5 Apr 2000 21:21:10 -0700 (PDT) Received: from localhost (van@localhost) by van-u5.cisco.com (8.8.8+Sun/8.8.8) with ESMTP id UAA17650 for ; Wed, 5 Apr 2000 20:45:42 -0700 (PDT) Message-Id: <200004060345.UAA17650@van-u5.cisco.com> To: diffserv@ietf.org Date: Wed, 05 Apr 2000 20:45:42 -0700 From: Van Jacobson Subject: [Diffserv] the diffserv mail archive ... Sender: diffserv-admin@ietf.org Errors-To: diffserv-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Diffserv Discussion List X-BeenThere: diffserv@ietf.org ... should be up to date & working again. If anyone finds otherwise please let me know. Thanks. - van@cisco.com _______________________________________________ diffserv mailing list diffserv@ietf.org http://www1.ietf.org/mailman/listinfo/diffserv Archive: http://www-nrg.ee.lbl.gov/diff-serv-arch/ From diffserv-admin@ietf.org Thu Apr 6 06:08:50 2000 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA06388 for ; Thu, 6 Apr 2000 06:08:50 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id FAA02169; Thu, 6 Apr 2000 05:36:40 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id FAA02138 for ; Thu, 6 Apr 2000 05:36:36 -0400 (EDT) Received: from usc.edu (root@usc.edu [128.125.253.136]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA05989 for ; Thu, 6 Apr 2000 05:38:58 -0400 (EDT) Received: from aludra.usc.edu (demir@aludra.usc.edu [128.125.19.184]) by usc.edu (8.9.3.1/8.9.3/usc) with ESMTP id CAA19222; Thu, 6 Apr 2000 02:09:56 -0700 (PDT) Received: from localhost (demir@localhost) by aludra.usc.edu (8.9.3.1/8.9.3/usc) with ESMTP id CAA05203; Thu, 6 Apr 2000 02:09:54 -0700 (PDT) Date: Thu, 6 Apr 2000 02:09:54 -0700 (PDT) From: demir To: Lixia Zhang cc: diffserv@ietf.org Subject: Re: [Diffserv] question on resource allocation In-Reply-To: <200003302131.NAA01862@darkstar.iprg.nokia.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 > If you know Internet routing well: use an analogy to routing protocols, > there is BGP which controls routing across domains, and IGP which is one's > own choice (one can run RIP, or OSPF, or static routing --- any way one > chooses for himself) > > BB controls allocation across domains. What to do for BW allocation within > a domain is that domain's business, as long as that domain can fulfill its > service commitment. > > Lixia Above statement does not clarify if BB is also capable of allocating domain's internal resources. Referring to routing analogy, I would say like BGP is not used as an interior routing protocol, BB is not used for allocating domain's internal resources (?). What do you use in two-tier architecture to allocate domain's internal resources ? Alper K. Demir _______________________________________________ diffserv mailing list diffserv@ietf.org http://www1.ietf.org/mailman/listinfo/diffserv Archive: http://www-nrg.ee.lbl.gov/diff-serv-arch/ From diffserv-admin@ietf.org Thu Apr 6 10:13:50 2000 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA08723 for ; Thu, 6 Apr 2000 10:13:50 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id JAA04036; Thu, 6 Apr 2000 09:21:57 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id JAA04000 for ; Thu, 6 Apr 2000 09:21:44 -0400 (EDT) Received: from mail-gw.hursley.ibm.com (mail-gw.hursley.ibm.com [194.196.110.15]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA07940 for ; Thu, 6 Apr 2000 09:24:06 -0400 (EDT) Received: from sp3at21.hursley.ibm.com (sp3at21.hursley.ibm.com [9.20.45.21]) by mail-gw.hursley.ibm.com (AIX4.3/UCB 8.8.8/8.8.8) with ESMTP id OAA86988; Thu, 6 Apr 2000 14:23:32 +0100 Received: from hursley.ibm.com (gsine02.us.sine.ibm.com [9.14.6.42]) by sp3at21.hursley.ibm.com (AIX4.2/UCB 8.7/8.7.3) with ESMTP id OAA23860; Thu, 6 Apr 2000 14:23:30 +0100 (BST) Message-ID: <38EC8FDB.5709C225@hursley.ibm.com> Date: Thu, 06 Apr 2000 08:23:39 -0500 From: Brian E Carpenter Organization: IBM X-Mailer: Mozilla 4.61 [en] (Win98; I) X-Accept-Language: en,fr MIME-Version: 1.0 To: Kathleen Nichols CC: demir , Diff Serv Subject: Re: [Diffserv] Relationship between DS domain and Routing domain References: <38EBE1DD.651DAB19@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 There is certainly no 1:1 mapping. I tend to think of a complete campus network, or a complete ISP network, as the typical DS domain. But it's really a matter of choice, including where you choose to put MF classifiers. Brian Kathleen Nichols wrote: > > demir wrote: > > > > Hi all, > > Is there any assumption on relationship between DS domain and routing > > domain AS (autonomous system), such as an AS can have one or more DS > > domain, or a DS domain can be composed of one or more AS, etc...? > > > > The RFC 2475 definition: > > "DS domain a DS-capable domain; a contiguous set of > nodes which operate with a common set of > service provisioning policies and PHB > definitions." > > So, the "common set of service provisioning policies" leads > me to say that a DS domain would NOT be composed of one or > more ASs (not very "autonomous" to share provisioning, eh?) > but that an AS may be composed of one or more DS domains since > one might provision different subnetworks according to > different rules. I suppose there might even be different > PHB definitions within different DS domains of the same > AS, though that would seem more likely. > > The "common set of service provisioning policies" is > ensured by the DS boundary. > > Kathie > > _______________________________________________ > diffserv mailing list > diffserv@ietf.org > http://www1.ietf.org/mailman/listinfo/diffserv > Archive: http://www-nrg.ee.lbl.gov/diff-serv-arch/ _______________________________________________ diffserv mailing list diffserv@ietf.org http://www1.ietf.org/mailman/listinfo/diffserv Archive: http://www-nrg.ee.lbl.gov/diff-serv-arch/ From diffserv-admin@ietf.org Thu Apr 6 10:31:14 2000 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA09001 for ; Thu, 6 Apr 2000 10:31:13 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id KAA04601; Thu, 6 Apr 2000 10:00:44 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id KAA04570 for ; Thu, 6 Apr 2000 10:00:40 -0400 (EDT) Received: from aurora.cs.ucla.edu (Aurora.CS.UCLA.EDU [131.179.96.157]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA08531 for ; Thu, 6 Apr 2000 10:03:03 -0400 (EDT) Received: (from lixia@localhost) by aurora.cs.ucla.edu (8.9.3+Sun/UCLACS-5.0) id HAA10550; Thu, 6 Apr 2000 07:03:02 -0700 (PDT) From: Lixia Zhang Message-Id: <200004061403.HAA10550@aurora.cs.ucla.edu> Subject: Re: [Diffserv] question on resource allocation In-Reply-To: from demir at "Apr 6, 2000 02:09:54 am" To: demir Date: Thu, 6 Apr 2000 07:03:02 -0700 (PDT) CC: diffserv@ietf.org X-Mailer: ELM [version 2.4ME+ PL60 (25)] 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 > > If you know Internet routing well: use an analogy to routing protocols, > > there is BGP which controls routing across domains, and IGP which is one's > > own choice (one can run RIP, or OSPF, or static routing --- any way one > > chooses for himself) > > > > BB controls allocation across domains. What to do for BW allocation within > > a domain is that domain's business, as long as that domain can fulfill its > > service commitment. > > > > Lixia > > Above statement does not clarify if BB is also capable of allocating > domain's internal resources. Referring to routing analogy, I would say > like BGP is not used as an interior routing protocol, BB is not used for > allocating domain's internal resources (?). What do you use in > two-tier architecture to allocate domain's internal resources ? > > Alper K. Demir Let me answer your questions one by one. - whether BB is also capable of allocating internal resource: I'd repeat again that is the decision by the owner of the domain, not us. Use routing as analogy again: I hear hallway conversations about our dept's network, over the years I think we have changed from static to RIP, and we are in the process moving to a different router vendor, along the way the internal routing protocol may change as well. It's nobody else's business. - "BGP is not used as an interior routing protocol": are you sure? My vague memory says that there are indeed places that use BGP internally. Again it's nobody else's business. - What do I use: I dont own a net, so I use nothing :-) If I had a net? well, depending how big it is, I might do different things, static, use of SNMP to extend my arms, or even a stripped down version of RSVP (and I'm sure someone would tell me "MPLS"). in any case, not your business :-) Lixia _______________________________________________ diffserv mailing list diffserv@ietf.org http://www1.ietf.org/mailman/listinfo/diffserv Archive: http://www-nrg.ee.lbl.gov/diff-serv-arch/ From diffserv-admin@ietf.org Thu Apr 6 11:20:36 2000 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA09704 for ; Thu, 6 Apr 2000 11:20:36 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id KAA05199; Thu, 6 Apr 2000 10:40:17 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id KAA05168 for ; Thu, 6 Apr 2000 10:40:13 -0400 (EDT) Received: from dfssl.exchange.microsoft.com ([131.107.88.59]) by ietf.org (8.9.1a/8.9.1a) with SMTP id KAA09192 for ; Thu, 6 Apr 2000 10:42:35 -0400 (EDT) Received: from 127.0.0.1 by dfssl.exchange.microsoft.com (InterScan E-Mail VirusWall NT); Thu, 06 Apr 2000 07:35:14 -0700 (Pacific Daylight Time) Received: by dfssl with Internet Mail Service (5.5.2650.21) id <2L7FVBR9>; Thu, 6 Apr 2000 07:35:14 -0700 Message-ID: <078292D50C98D2118D090008C7E9C6A60C2F4A99@STAY.platinum.corp.microsoft.com> From: Yoram Bernet To: Lixia Zhang , demir Cc: diffserv@ietf.org Subject: RE: [Diffserv] question on resource allocation Date: Thu, 6 Apr 2000 07:35:11 -0700 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: text/plain; charset="iso-8859-1" Sender: diffserv-admin@ietf.org Errors-To: diffserv-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Diffserv Discussion List X-BeenThere: diffserv@ietf.org > - What do I use: I dont own a net, so I use nothing :-) > If I had a net? well, depending how big it is, I might do different > things, static, use of SNMP to extend my arms, or even a > stripped down > version of RSVP (and I'm sure someone would tell me "MPLS"). > in any case, not your business :-) > I agree with Lixia. A diffserv network needs to provide SLAs at its periphery and doesn't hae to tell anyone how it provisions its interior to support these SLAs. That said - the job does have to be done. There have been several proposals for doing so. MPLS is one of them. Aggregated RSVP bwetween edges of the provider's network (per the draft in the issll WG) is another. Selection of an internal mechanism depends on whether the SLAs to be proided are static (much easier, but less efficient) or dynamic (harder to do, but more efficient since resources can more readily be moved around to accommodate changing rqmts). But - back to the BB... Your initial question was along the lines of whether the BB is going to do internal provisioning. Here's the way I see it - There are two corenr cases when it comes to internal provisioning. One extreme is fully centralized. In this model, there is an oracle that sits at the top of the domain and understands its topology and the current availability of resources at each service level, along each part of the network. When the provider wants to add a new SLA or change an existing one, the BB knows just how much the SLA can change without compromising pre-existing SLAs. The other extreme is the fully distributed model. In the fully distributed model, requests to change an SLA pass through each of the devices impacted by the change and these locally assess the impact of the SLA change on their resources at that time. This is of course, RSVP, probably in its aggregated form. What are the tradeoffs to consider when determining which model to use? By cenrtralizing in an oracle, one achieves the benefit of relieving network devices from the need to participate in aggreagte RSVP signaling. Instead, the (roughly) equivalent functionality is concentrated in a single device (the oracle). On the other hand, that single device now needs to understand the network topology and needs to track committed resources and needs to understand the impact of admitting new SLAs (and therefore the routing). By centralizing in an oracle, one is gambling that the benefits of relieving individual devices from participating in whatever provisioning process is used, outwiegh the detriment of requiring the oracle to understand the routing and resource availability within the domain. A few observations: 1. The need to understand the routing and resource availability is more important for higher quality committments. If you're just planning on offering "better than joe" service, then - you don't need to accurately understand the routing and the resource availability within the domain. Then again - you're not offering all that much. If you're offering virtual leased line type of service, then this knowledge will be quite important. 2. You can always overprovision to make up for any lack of knowledge about routing and committed reosurces. This can get expensive. 3. In my opinion, the choice of whether to centralize (as in an oracle) or distribute (as in RSVP) the provisioning and admission control for the domain will forever remain a religious issue. I argue that we should design an architecture that would enable the network manager to 'dial-in' their preferred level of 'density of admission control/provisioning agents'. We should not offer one mechanism for fully centralized a/c/provisioning and another for fully distributed. They are special cases of the same general problem. We should enable a continuum from fully distirbuted to fully centralized (with the space in between allowing for the task to be distributed between some set of a/c/provisioning agents strategically located within the domain. Each agent then has a scope of a/c/provisioning responsibility. In the fully snetralized case, the single agent's scope is the entire diffserv domain. In the fully distributed case, each agent's scope is the interfaces attached directly to it. In interim cases, scopes could be 'a subnet consisting of 6 adjacent routers'. The network manager, by choosing more or less distribution (a denser or sparsere distribution of admission control agents) can choose how he/she wants to operate his/her network. Of course - then we look for a protocol that's suitable for this architecture. I maintaint hat that is some form of RSVP, probably pretty close to what has been defined in the issll WG as aggregate RSVP. Yoram > Lixia > > > > _______________________________________________ > diffserv mailing list > diffserv@ietf.org > http://www1.ietf.org/mailman/listinfo/diffserv > Archive: http://www-nrg.ee.lbl.gov/diff-serv-arch/ > _______________________________________________ diffserv mailing list diffserv@ietf.org http://www1.ietf.org/mailman/listinfo/diffserv Archive: http://www-nrg.ee.lbl.gov/diff-serv-arch/ From diffserv-admin@ietf.org Thu Apr 6 14: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 ESMTP id OAA12339 for ; Thu, 6 Apr 2000 14:24:26 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id NAA07347; Thu, 6 Apr 2000 13:54:35 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id NAA07317 for ; Thu, 6 Apr 2000 13:54:32 -0400 (EDT) Received: from procyon.pmc-sierra.bc.ca (procyon.pmc-sierra.bc.ca [134.87.115.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA12026 for ; Thu, 6 Apr 2000 13:56:53 -0400 (EDT) Received: from nt-exchange1.pmc-sierra.bc.ca (nt-exchange1.pmc-sierra.bc.ca [134.87.116.183]) by procyon.pmc-sierra.bc.ca (6.6.6/6.6.6) with ESMTP id KAA05438 for ; Thu, 6 Apr 2000 10:56:52 -0700 (PDT) Received: by nt-exchange1.pmc-sierra.bc.ca with Internet Mail Service (5.5.2650.21) id <2J27TJR8>; Thu, 6 Apr 2000 10:56:52 -0700 Message-ID: <336ECDAFDF7DD311B9E30090277AEE4101B40496@nt-exchange-bby.pmc-sierra.bc.ca> From: Shahram Davari To: "'diffserv@ietf.org'" Date: Thu, 6 Apr 2000 10:54:15 -0700 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: text/plain; charset="iso-8859-1" Subject: [Diffserv] EF 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, RFC-2598 says: "EF 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" Lets assume 2 PHB queues: an EF and a BE each of rate R (both nicely shaped). Let's assume the output link rate is 2R so that 50% of the link BW (=R) is assigned to EF and 50% (=R) to BE. Let's also assume that packet sizes are all MTU size. Now on the output link we will have EF and BE packets one after another as following: ---------------------------------------------------------------------------- - | BE | EF | BE | EF | BE | EF | ..... | ---------------------------------------------------------------------------- - <-----------------------> 3T The duration of each packet at the output link is T= MTU/2R. Now assume the time from the beginning of a BE packet to the end of another BE packet; this time = 3T (notice that there is only one EF packet in this interval). Also the time to send an MTU size packet at EF configured rate is MTU/R = 2T. Since 3T > 2T then according to RFC-2598 we should average the configured rate in the 3T interval. But as you can see the average EF rate in the 3T interval is MTU/3T = 2R/3 which is 2/3 of the EF configured rate R. Either I am missing something or there is a problem with the RFC-2598. Any comments? Shahram Davari Systems Engineer, Product Research PMC-Sierra Inc. 555 Legget drive, Suit 834, Tower B, Ottawa, ON K2K 2X3, Canada Phone: +1 (613) 271-4018 Fax : +1 (613) 271-7007 _______________________________________________ diffserv mailing list diffserv@ietf.org http://www1.ietf.org/mailman/listinfo/diffserv Archive: http://www-nrg.ee.lbl.gov/diff-serv-arch/ From diffserv-admin@ietf.org Thu Apr 6 14: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 ESMTP id OAA12545 for ; Thu, 6 Apr 2000 14:35:21 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id OAA07552; Thu, 6 Apr 2000 14:07:48 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id OAA07521 for ; Thu, 6 Apr 2000 14:07:43 -0400 (EDT) Received: from procyon.pmc-sierra.bc.ca (procyon.pmc-sierra.bc.ca [134.87.115.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA12206 for ; Thu, 6 Apr 2000 14:10:05 -0400 (EDT) Received: from nt-exchange1.pmc-sierra.bc.ca (nt-exchange1.pmc-sierra.bc.ca [134.87.116.183]) by procyon.pmc-sierra.bc.ca (6.6.6/6.6.6) with ESMTP id LAA06819 for ; Thu, 6 Apr 2000 11:10:06 -0700 (PDT) Received: by nt-exchange1.pmc-sierra.bc.ca with Internet Mail Service (5.5.2650.21) id <2J27TJZZ>; Thu, 6 Apr 2000 11:10:07 -0700 Message-ID: <336ECDAFDF7DD311B9E30090277AEE4101B40497@nt-exchange-bby.pmc-sierra.bc.ca> From: Shahram Davari To: "'Diffserv@ietf.org'" Subject: FW: [Diffserv] EF question !!! Date: Thu, 6 Apr 2000 11:07:31 -0700 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: text/plain; charset="iso-8859-1" Sender: diffserv-admin@ietf.org Errors-To: diffserv-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Diffserv Discussion List X-BeenThere: diffserv@ietf.org "The figure was messed up in previous email. Please use this one:" Hi, RFC-2598 says: "EF 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" Lets assume 2 PHB queues: an EF and a BE each of rate R (both nicely shaped). Let's assume the output link rate is 2R so that 50% of the link BW (=R) is assigned to EF and 50% (=R) to BE. Let's also assume that packet sizes are all MTU size. Now on the output link we will have EF and BE packets one after another as following: ---------------------------------------------------------- | BE | EF | BE | EF | BE | EF | ..... | ---------------------------------------------------------- <-------------------> 3T The duration of each packet at the output link is T= MTU/2R. Now assume the time from the beginning of a BE packet to the end of another BE packet; this time = 3T (notice that there is only one EF packet in this interval). Also the time to send an MTU size packet at EF configured rate is MTU/R = 2T. Since 3T > 2T then according to RFC-2598 we should average the configured rate in the 3T interval. But as you can see the average EF rate in the 3T interval is MTU/3T = 2R/3 which is 2/3 of the EF configured rate R. Either I am missing something or there is a problem with the RFC-2598. Any comments? Shahram Davari Systems Engineer, Product Research PMC-Sierra Inc. 555 Legget drive, Suit 834, Tower B, Ottawa, ON K2K 2X3, Canada Phone: +1 (613) 271-4018 Fax : +1 (613) 271-7007 _______________________________________________ diffserv mailing list diffserv@ietf.org http://www1.ietf.org/mailman/listinfo/diffserv Archive: http://www-nrg.ee.lbl.gov/diff-serv-arch/ _______________________________________________ diffserv mailing list diffserv@ietf.org http://www1.ietf.org/mailman/listinfo/diffserv Archive: http://www-nrg.ee.lbl.gov/diff-serv-arch/ From diffserv-admin@ietf.org Thu Apr 6 15:07:14 2000 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA13204 for ; Thu, 6 Apr 2000 15:07:14 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id OAA07991; Thu, 6 Apr 2000 14:34:29 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id OAA07962 for ; Thu, 6 Apr 2000 14:34:25 -0400 (EDT) Received: from alpo.casc.com (alpo.casc.com [152.148.10.6]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA12573 for ; Thu, 6 Apr 2000 14:36:46 -0400 (EDT) Received: from ascend.com ([152.148.89.11]) by alpo.casc.com (8.9.1a/8.9.1) with ESMTP id OAA14869; Thu, 6 Apr 2000 14:35:49 -0400 (EDT) Message-ID: <38ECD819.959C85C0@ascend.com> Date: Thu, 06 Apr 2000 14:31:53 -0400 From: Siamack Ayandeh X-Mailer: Mozilla 4.5 [en] (WinNT; U) X-Accept-Language: en MIME-Version: 1.0 To: Shahram Davari CC: diffserv@ietf.org Subject: Re: [Diffserv] ID-VW-BA, questions on jitter References: <336ECDAFDF7DD311B9E30090277AEE4101B40489@nt-exchange-bby.pmc-sierra.bc.ca> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: diffserv-admin@ietf.org Errors-To: diffserv-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Diffserv Discussion List X-BeenThere: diffserv@ietf.org Content-Transfer-Encoding: 7bit Shahram, Thanks for the reply. My comments are inserted below. Regards, Siamack Shahram Davari wrote: > Hi Siamak, > > Please see my comments below: > > >-----Original Message----- > >From: Siamack Ayandeh [mailto:sayandeh@ascend.com] > >Sent: Wednesday, March 22, 2000 3:28 PM > >To: diffserv@ietf.org > >Subject: [Diffserv] ID-VW-BA, questions on jitter > > > > > >I appreciate if the authors of the draft would comment > >on the following factors impacting jitter for virtual wire > >behavior aggregate (VW-BA). > > > >1. Neither RFC 2598 nor VW deal with the jitter induced by inband > >control > >and routing traffic which may be of higher priority than EF. Relative > >to "network" precedence is EF > > > >a) at a higher priority? > >b) Is it of the same priority where each Class Selector CP > > is limited to emitting one packet using a token bucket. > >c) Or of lower priority. > > I think a higher priority (than EF) class is acceptable only if it does not > emit more than 1 MTU size packet at a time. As you mentioned one way of > ensuring this property is probably to shape the higher priority flow to MTU > size packets. Even this scenario would lead to packet inter leaving of "network" and "EF". This would not be acceptable according to the VW-BA definitions. I guess the definitions assume "ideal" conditions. > > > > > >2. Related question is that ID-VW-BA page-5 talks of "EF's priority > >queuing model". RFC 2598 does not impose such a requirement. > > > >3. Given that the MTU size is likely to be >> than (fixed) EF packet > >size (S), "n" in equation-1 should be at least 2 x MTU/S. > >Leading to the need for fragmentation on slow links carrying EF. > >This limits the plausible share of EF to 5% of link bandwidth or > >less. > > > > Although your computation is a little off (in fact n > 1 + MTU/S, because > MTU/B < S/R - S/B), but your point is valid, and this limitation exist in > low speed links. My computation simply followed the logic of the draft since I was seeking clarification. > > > >4. Does this residual service time of (2 x MTU/S) also arise in the > >context > >of non-prority schedulers such as non-bursty WFQ? Is the new > >limit k x 2 xMTU/S where k+1 is the number of scheduling classes. > > > > When WFQ is going to be used to emulate Priority Queing (PQ), the weight > assigned to EF should not correspond to its configured rate, but the weight > should be much higher ( W >> R/B). For example if 5% of the link is EF, the > weight of the EF queue should be set to 90% not 5%. Your point is valid to > some extent if improper weight is used. But with proper selection of weight > the jitter (due to other queues) can be limited to 1 MTU size packet at > output rate. So you are agreeing that "k" has be kept small. In general the scheduler needs to visit the EF queue after visiting every other queue. For EF queue the burst limit is the number of active flows, while for the other classes it would be one packet. For similar size packets the share of the EF would be 50% in the scenario you described above (no need to set it to 90%). I guess this is how the factor of 2 shows up in the equation. > > > >5. Given that "k" may be of order of 10s if not hundreds (of > >class-queues), > >what guidelines do authors suggest should be followed in terms of > >limiting > >"k". > > > >6. If this limit on "k" is not acceptable, then is EF-PHB and the VW > >behavior > >aggregate limiting scheduler implementations? > > > >7. Given that S, the packet size would be different for various EF > >flows, the > >jitter window discussed in the draft is an upper bound based on the > >largest > >packet size. How does this bound on jitter window effect the idea of a > >virtual wire for flows carrying the smaller packets? > > > >Many thanks, Siamack > > > > > > > > > > > >_______________________________________________ > >diffserv mailing list > >diffserv@ietf.org > >http://www.ietf.org/mailman/listinfo/diffserv > >Archive: http://www-nrg.ee.lbl.gov/diff-serv-arch/ > > _______________________________________________ diffserv mailing list diffserv@ietf.org http://www1.ietf.org/mailman/listinfo/diffserv Archive: http://www-nrg.ee.lbl.gov/diff-serv-arch/ From diffserv-admin@ietf.org Thu Apr 6 15:36:38 2000 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA13725 for ; Thu, 6 Apr 2000 15:36:38 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id PAA08532; Thu, 6 Apr 2000 15:00:21 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id PAA08500 for ; Thu, 6 Apr 2000 15:00:17 -0400 (EDT) Received: from omega.cisco.com (omega.cisco.com [171.69.63.141]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA13127 for ; Thu, 6 Apr 2000 15:02:38 -0400 (EDT) Received: from cisco.com (dhcp-o-38-206.cisco.com [171.71.38.206]) by omega.cisco.com (8.8.8-Cisco List Logging/8.8.8) with ESMTP id MAA05935 for ; Thu, 6 Apr 2000 12:02:08 -0700 (PDT) Message-ID: <38ECE004.FC48F47@cisco.com> Date: Thu, 06 Apr 2000 12:05:40 -0700 From: Kathleen Nichols X-Mailer: Mozilla 4.61 [en] (Win98; U) X-Accept-Language: en MIME-Version: 1.0 To: diffserv@ietf.org Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Subject: [Diffserv] On RED in a Diffserv MIB Sender: diffserv-admin@ietf.org Errors-To: diffserv-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Diffserv Discussion List X-BeenThere: diffserv@ietf.org Content-Transfer-Encoding: 7bit This note is most definitely with my WG co-chair hat OFF and Brian will probably ding me for rambling on about a non-DS topic. I do have concerns that a detailed discussion of RED is NOT a DS topic. However, the MIB discussion keeps pulling it in and I have been asked to post my individual thinking on the topic. I still believe that much of this is not relevant to the Diffserv MIB, but with many reservations, I will weigh in (and without consulting my collaborators). My context is that I've been working with Van Jacobson and Kedar Poduri on "rethinking" RED since late 1997. (More recently, Li Fan has been involved in the RED work.) We did some internal Bay reports on early work and Van used some of this in an early 98 email exchange with Sean Doran on parameter-setting for the 93RED. I believe that Van's suggestions worked out, but you'd have to talk to Sean. We had started to develop a different control law for RED as well as several other changes and work on why we did this. Van gave a talk at the June 98 Nanog (which I assume is still available in their archives) on the development of a new control law and why and how to think of RED as a controller which is somewhat key to understanding where we're coming from. We have a draft paper that's been pretty much in the same form since January of 99 (embarassingly enough) that quite a number of people have seen and is semi-public, but I won't post the URL until Van is ready. Although the development and much of the "how to" is rather different from the 93 RED work, I believe the same set of parameters could be used, though they would be set to different values and used a bit differently. Namely, a "filter gain" or "queue weight", a "min_thresh" or just "threshold" for the control region, and a "max_thresh" or range of the control region. This seems to cover most of the known flavors of RED and seems reasonable for a MIB. I don't think it makes sense to specify the algorithm via a MIB since I don't think a box will let you choose. It may make sense to *report* what algorithm that box uses, but having been at two companies that make boxes, I can say that there are many flavors of flavors when engineers get down to implementing, so I don't know how useful or accurate that can be. (This paragraph is the one that is relevant to the MIB discussion.) The work that Kwok referenced from Firiou and Borden appears to borrow from our work in some of its early sections, specifically Van's control law discussions and my math on the step response (Victor and Marty had seen our draft, of course, as colleague and boss of Kedar), but as that paper uses one of those "mythical Internet" simulations of a few long-lived TCPs of the same known RTTs, they reached erroneous conclusions about useful parameters. This is what Van meant when he said in the DS WG that if you used those parameters, you'd be in trouble. (You know how everyone says to add "multicast" to some problem to make it a lot harder? When it comes to analyzing how something works with network traffic, I say add HTTP and varied RTTs to make it a lot harder. But then it would take too long for the people who want to turn out papers.) We felt, as active researchers in this area, some duty to say "don't do it!" when Kwok recommended that paper and those settings of the traditional parameters. For full disclosure, I should say that our draft paper was rejected by Sigcomm 99. A major complaint was that it was too long and unfinished (that's Van's fault!) and that we didn't understand the 93 RED paper (so I guess we share that). Thus, you can take my thoughts on this subject with a grain of salt if you are so inclined. On the other hand, our "RED in a different light" (or RED-light) work has been presented/discussed with folks at Torrent, Bay (pre-NortelNetworks), Argon, and Cisco. I don't know what, if anything, the former three have done with it. A variety of things are going on at Cisco. One of these is that Fred Baker did an implementation of it in something like Fall of 98 and I believe he's gotten good results with it, but I won't speak for Fred. At Cisco, we've done work on RED-light for high bandwidth links, multiple queues, and a couple of other things that perhaps should not be said publically yet. It seems promising. All it needs for setting is the three parameters (in fact, we could probably have them all derived from one parameter, but then that would exclude other RED implementations). I also want to note that we simulate with a much wider range of traffic conditions than I've seen discussed anywhere. Kathie _______________________________________________ diffserv mailing list diffserv@ietf.org http://www1.ietf.org/mailman/listinfo/diffserv Archive: http://www-nrg.ee.lbl.gov/diff-serv-arch/ From diffserv-admin@ietf.org Thu Apr 6 16:57:16 2000 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA14594 for ; Thu, 6 Apr 2000 16:57:16 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id QAA09622; Thu, 6 Apr 2000 16:31:06 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id QAA09591 for ; Thu, 6 Apr 2000 16:31:02 -0400 (EDT) Received: from mail-gw.hursley.ibm.com (mail-gw.hursley.ibm.com [194.196.110.15]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA14362 for ; Thu, 6 Apr 2000 16:33:24 -0400 (EDT) Received: from sp3at21.hursley.ibm.com (sp3at21.hursley.ibm.com [9.20.45.21]) by mail-gw.hursley.ibm.com (AIX4.3/UCB 8.8.8/8.8.8) with ESMTP id VAA49552; Thu, 6 Apr 2000 21:32:24 +0100 Received: from hursley.ibm.com (gsine02.us.sine.ibm.com [9.14.6.42]) by sp3at21.hursley.ibm.com (AIX4.2/UCB 8.7/8.7.3) with ESMTP id VAA11008; Thu, 6 Apr 2000 21:32:20 +0100 (BST) Message-ID: <38ECF460.E5311852@hursley.ibm.com> Date: Thu, 06 Apr 2000 15:32:32 -0500 From: Brian E Carpenter Organization: IBM X-Mailer: Mozilla 4.61 [en] (Win98; I) X-Accept-Language: en,fr MIME-Version: 1.0 To: Kwok Ho Chan CC: kmn@cisco.com, diffserv@ietf.org, fred@cisco.com, andrew@extremenetworks.com, Michael Fine , Van Jacobson References: <3.0.32.20000406133304.00cdb940@pobox.engeast.baynetworks.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Subject: [Diffserv] Re: 47th IETF DiffServ WG Session Presentation Slides Sender: diffserv-admin@ietf.org Errors-To: diffserv-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Diffserv Discussion List X-BeenThere: diffserv@ietf.org Content-Transfer-Encoding: 7bit Thanks Kwok. I'm not sure everybody wanted them in their inbox though. Could the others who presented slides to diffserv in Adelaide also send me the files please? No need to copy the whole list. (David Black, I have your slides of course). Thanks Brian Kwok Ho Chan wrote: > > Brian, Kathie: > Attached is the MSPowerPoint Slides for my presentation in the > 47th IETF DiffServ WG Session at Adelaide. Please include them > in the Minutes and Proceedings. > Thanks! > -- Kwok -- _______________________________________________ diffserv mailing list diffserv@ietf.org http://www1.ietf.org/mailman/listinfo/diffserv Archive: http://www-nrg.ee.lbl.gov/diff-serv-arch/ From diffserv-admin@ietf.org Thu Apr 6 17:21:33 2000 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA15038 for ; Thu, 6 Apr 2000 17:21:33 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id QAA09809; Thu, 6 Apr 2000 16:50:26 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id QAA09769 for ; Thu, 6 Apr 2000 16:50:22 -0400 (EDT) Received: from smtprch1.nortel.com (smtprch1.nortelnetworks.com [192.135.215.14]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA14539 for ; Thu, 6 Apr 2000 16:52:44 -0400 (EDT) Message-Id: <200004062052.QAA14539@ietf.org> Received: from zcard00n.ca.nortel.com (actually zcard00n) by smtprch1.nortel.com; Thu, 6 Apr 2000 15:01:59 -0500 Received: from zcard00f.ca.nortel.com ([47.129.30.8]) by zcard00n.ca.nortel.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2650.21) id 2M70JB7B; Thu, 6 Apr 2000 15:58:35 -0400 Received: from zcarh014 (zcarh014.ca.nortel.com [47.23.81.6]) by zcard00f.ca.nortel.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2650.21) id HNNLWC5C; Thu, 6 Apr 2000 15:58:35 -0400 Date: Thu, 6 Apr 2000 15:58:07 -0400 (EDT) X-Sybari-Space: 00000000 00000000 00000000 From: "Nabil Seddigh" Reply-To: "Nabil Seddigh" Subject: re:[Diffserv] On RED in a Diffserv MIB To: Kathleen Nichols cc: diffserv@ietf.org X-Mailer: Rosa 2.1 HP-UXB.10.20 X-Rosa-Trace: nseddigh@zcarh014 <47.23.81.6> MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-ID: Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by optimus.ietf.org id QAA09770 Sender: diffserv-admin@ietf.org Errors-To: 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 Kathie For those of us not present in Adelaide, can you provide the context for your comments below. I get the sense that it's related to MIB definition but am unusure of the exact connection. Thanks Nabil Seddigh > >This note is most definitely with my WG co-chair hat OFF and Brian will >probably ding me for rambling on about a non-DS topic. I do have >concerns that a detailed discussion of RED is NOT a DS topic. However, >the MIB discussion keeps pulling it in and I have been asked to post >my individual thinking on the topic. I still believe that much of >this is not relevant to the Diffserv MIB, but with many reservations, >I will weigh in (and without consulting my collaborators). > > > _______________________________________________ diffserv mailing list diffserv@ietf.org http://www1.ietf.org/mailman/listinfo/diffserv Archive: http://www-nrg.ee.lbl.gov/diff-serv-arch/ From diffserv-admin@ietf.org Thu Apr 6 17:23:18 2000 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA15081 for ; Thu, 6 Apr 2000 17:23:18 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id QAA09839; Thu, 6 Apr 2000 16:50:30 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id QAA09782 for ; Thu, 6 Apr 2000 16:50:23 -0400 (EDT) Received: from baynet.baynetworks.com (ns1.BayNetworks.COM [134.177.3.20]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA14543 for ; Thu, 6 Apr 2000 16:52:45 -0400 (EDT) Received: from mailhost.BayNetworks.COM (h8754.s84f5.BayNetworks.COM [132.245.135.84]) by baynet.baynetworks.com (8.9.1/8.9.1) with ESMTP id NAA24481; Thu, 6 Apr 2000 13:50:33 -0700 (PDT) Received: from pobox.engeast.BayNetworks.COM (pobox.engeast.baynetworks.com [192.32.61.6]) by mailhost.BayNetworks.COM (8.9.1/8.8.8) with ESMTP id QAA01735; Thu, 6 Apr 2000 16:56:42 -0400 (EDT) Received: from aoife (dhcp223-152 [192.32.223.152]) by pobox.engeast.BayNetworks.COM (SMI-8.6/BNET-97/04/24-S) with SMTP id QAA26306; Thu, 6 Apr 2000 16:51:58 -0400 for Message-Id: <3.0.32.20000406165140.0110ec70@pobox.engeast.baynetworks.com> X-Sender: khchan@pobox.engeast.baynetworks.com X-Mailer: Windows Eudora Pro Version 3.0 (32) Date: Thu, 06 Apr 2000 16:51:40 -0400 To: Brian E Carpenter From: Kwok Ho Chan Cc: "Chan, Kwok-Ho (K.C.) [BAY:BL60:470]" , kmn@cisco.com, diffserv@ietf.org, fred@cisco.com, andrew@extremenetworks.com, Michael Fine , Van Jacobson Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Subject: [Diffserv] Re: 47th IETF DiffServ WG Session Presentation Slides Sender: diffserv-admin@ietf.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 was thinking of putting the presentation on a FTP server, but our FTP server blocks cisco access, so I don't think I should put it there. If you have a place to put all the presentation slides for everyone to access and send pointers to it, that will be great. Thanks! -- Kwok -- At 03:32 PM 4/6/00 -0500, Brian E Carpenter wrote: >Thanks Kwok. I'm not sure everybody wanted them in their inbox though. > >Could the others who presented slides to diffserv in Adelaide also >send me the files please? No need to copy the whole list. >(David Black, I have your slides of course). > >Thanks > > Brian > >Kwok Ho Chan wrote: >> >> Brian, Kathie: >> Attached is the MSPowerPoint Slides for my presentation in the >> 47th IETF DiffServ WG Session at Adelaide. Please include them >> in the Minutes and Proceedings. >> Thanks! >> -- Kwok -- > > _______________________________________________ diffserv mailing list diffserv@ietf.org http://www1.ietf.org/mailman/listinfo/diffserv Archive: http://www-nrg.ee.lbl.gov/diff-serv-arch/ From diffserv-admin@ietf.org Thu Apr 6 17:39:55 2000 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA15391 for ; Thu, 6 Apr 2000 17:39:55 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id RAA10283; Thu, 6 Apr 2000 17:07:57 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id RAA10254 for ; Thu, 6 Apr 2000 17:07:53 -0400 (EDT) Received: from mail-gw.hursley.ibm.com (mail-gw.hursley.ibm.com [194.196.110.15]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA14853 for ; Thu, 6 Apr 2000 17:10:14 -0400 (EDT) Received: from sp3at21.hursley.ibm.com (sp3at21.hursley.ibm.com [9.20.45.21]) by mail-gw.hursley.ibm.com (AIX4.3/UCB 8.8.8/8.8.8) with ESMTP id WAA39774; Thu, 6 Apr 2000 22:09:45 +0100 Received: from hursley.ibm.com (gsine02.us.sine.ibm.com [9.14.6.42]) by sp3at21.hursley.ibm.com (AIX4.2/UCB 8.7/8.7.3) with ESMTP id WAA17726; Thu, 6 Apr 2000 22:09:44 +0100 (BST) Message-ID: <38ECFD20.B751A34A@hursley.ibm.com> Date: Thu, 06 Apr 2000 16:09:52 -0500 From: Brian E Carpenter Organization: IBM X-Mailer: Mozilla 4.61 [en] (Win98; I) X-Accept-Language: en,fr MIME-Version: 1.0 To: Kathleen Nichols CC: diffserv@ietf.org Subject: Re: [Diffserv] On RED in a Diffserv MIB References: <38ECE004.FC48F47@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 Wow! A chance to keep my co-chair in check! While the details of RED control laws are rather out of scope, there is an important point for the diffserv MIB here: it's obvious that as long as there is theoretical debate about the form of the law, carving a RED control law in stone in the MIB would be a mistake. So, Andrew, please consider that in revising the MIB . (I'm hoping the PIB will avoid that level of detail, but if it can't, obviously the same applies.) I guess the RED details are better discussed on e2e-interest or somwhere like that. Brian Kathleen Nichols wrote: > > This note is most definitely with my WG co-chair hat OFF and Brian will > probably ding me for rambling on about a non-DS topic. I do have > concerns that a detailed discussion of RED is NOT a DS topic. However, > the MIB discussion keeps pulling it in and I have been asked to post > my individual thinking on the topic. I still believe that much of > this is not relevant to the Diffserv MIB, but with many reservations, > I will weigh in (and without consulting my collaborators). > > My context is that I've been working with Van Jacobson and Kedar Poduri > on "rethinking" RED since late 1997. (More recently, Li Fan has been > involved in the RED work.) We did some internal Bay reports on early > work and Van used some of this in an early 98 email exchange with Sean > Doran on parameter-setting for the 93RED. I believe that Van's > suggestions > worked out, but you'd have to talk to Sean. We had started to develop > a different control law for RED as well as several other changes > and work on why we did this. Van gave a talk at the June 98 Nanog > (which I assume is still available in their archives) on the development > of a new control law and why and how to think of RED as a controller > which is somewhat key to understanding where we're coming from. > > We have a draft paper that's been pretty much in the same form since > January of 99 (embarassingly enough) that quite a number of people > have seen and is semi-public, but I won't post the URL until Van > is ready. Although the development and much of the "how to" is > rather different from the 93 RED work, I believe the same set of > parameters could be used, though they would be set to different > values and used a bit differently. Namely, a "filter gain" or > "queue weight", a "min_thresh" or just "threshold" for the > control region, and a "max_thresh" or range of the control region. > This seems to cover most of the known flavors of RED and seems > reasonable for a MIB. I don't think it makes sense to specify > the algorithm via a MIB since I don't think a box will let you > choose. It may make sense to *report* what algorithm that box > uses, but having been at two companies that make boxes, I can > say that there are many flavors of flavors when engineers get > down to implementing, so I don't know how useful or accurate > that can be. (This paragraph is the one that is relevant to > the MIB discussion.) > > The work that Kwok referenced from Firiou and Borden appears > to borrow from our work in some of its early sections, > specifically Van's control law discussions and my math on > the step response (Victor and Marty had seen our draft, > of course, as colleague and boss of Kedar), but as that > paper uses one of those "mythical Internet" simulations > of a few long-lived TCPs of the same known RTTs, they > reached erroneous conclusions about useful parameters. This > is what Van meant when he said in the DS WG that if you > used those parameters, you'd be in trouble. (You know how > everyone says to add "multicast" to some problem to make > it a lot harder? When it comes to analyzing how something > works with network traffic, I say add HTTP and varied > RTTs to make it a lot harder. But then it would take too > long for the people who want to turn out papers.) We felt, > as active researchers in this area, some duty to say "don't > do it!" when Kwok recommended that paper and those settings > of the traditional parameters. > > For full disclosure, I should say that our draft paper was > rejected by Sigcomm 99. A major complaint was that it was > too long and unfinished (that's Van's fault!) and that we > didn't understand the 93 RED paper (so I guess we share that). > Thus, you can take my thoughts on this subject with a grain > of salt if you are so inclined. > > On the other hand, our "RED in a different light" (or RED-light) > work has been presented/discussed with folks at Torrent, Bay > (pre-NortelNetworks), Argon, and Cisco. I don't know what, if > anything, the former three have done with it. A variety of things > are going on at Cisco. One of these is that Fred Baker did an > implementation of it in something like Fall of 98 and I believe > he's gotten good results with it, but I won't speak for Fred. At > Cisco, we've done work on RED-light for high bandwidth links, > multiple queues, and a couple of other things that perhaps should > not be said publically yet. It seems promising. All it needs > for setting is the three parameters (in fact, we could probably > have them all derived from one parameter, but then that would > exclude other RED implementations). I also want to note that > we simulate with a much wider range of traffic conditions than > I've seen discussed anywhere. > > Kathie > > _______________________________________________ > diffserv mailing list > diffserv@ietf.org > http://www1.ietf.org/mailman/listinfo/diffserv > Archive: http://www-nrg.ee.lbl.gov/diff-serv-arch/ _______________________________________________ diffserv mailing list diffserv@ietf.org http://www1.ietf.org/mailman/listinfo/diffserv Archive: http://www-nrg.ee.lbl.gov/diff-serv-arch/ From diffserv-admin@ietf.org Thu Apr 6 17:45:24 2000 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA15478 for ; Thu, 6 Apr 2000 17:45:23 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id RAA10501; Thu, 6 Apr 2000 17:16:47 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id RAA10473 for ; Thu, 6 Apr 2000 17:16:42 -0400 (EDT) Received: from mail-gw.hursley.ibm.com (mail-gw.hursley.ibm.com [194.196.110.15]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA15014 for ; Thu, 6 Apr 2000 17:19:04 -0400 (EDT) Received: from sp3at21.hursley.ibm.com (sp3at21.hursley.ibm.com [9.20.45.21]) by mail-gw.hursley.ibm.com (AIX4.3/UCB 8.8.8/8.8.8) with ESMTP id WAA55978; Thu, 6 Apr 2000 22:18:28 +0100 Received: from hursley.ibm.com (gsine02.us.sine.ibm.com [9.14.6.42]) by sp3at21.hursley.ibm.com (AIX4.2/UCB 8.7/8.7.3) with ESMTP id WAA23334; Thu, 6 Apr 2000 22:18:13 +0100 (BST) Message-ID: <38ECFF19.4717A2E6@hursley.ibm.com> Date: Thu, 06 Apr 2000 16:18:17 -0500 From: Brian E Carpenter Organization: IBM X-Mailer: Mozilla 4.61 [en] (Win98; I) X-Accept-Language: en,fr MIME-Version: 1.0 To: Kwok Ho Chan CC: "Chan, Kwok-Ho (K.C.) [BAY:BL60:470]" , kmn@cisco.com, diffserv@ietf.org, fred@cisco.com, andrew@extremenetworks.com, Michael Fine , Van Jacobson References: <3.0.32.20000406165140.0110ec70@pobox.engeast.baynetworks.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Subject: [Diffserv] Re: 47th IETF DiffServ WG Session Presentation Slides Sender: diffserv-admin@ietf.org Errors-To: diffserv-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 slides will appear on the IETF minutes site (eventually...). That's why I need them. Brian Kwok Ho Chan wrote: > > Brian: > I was thinking of putting the presentation on a FTP server, > but our FTP server blocks cisco access, so I don't think > I should put it there. If you have a place to put all the > presentation slides for everyone to access and send pointers > to it, that will be great. > Thanks! > -- Kwok -- > > At 03:32 PM 4/6/00 -0500, Brian E Carpenter wrote: > >Thanks Kwok. I'm not sure everybody wanted them in their inbox though. > > > >Could the others who presented slides to diffserv in Adelaide also > >send me the files please? No need to copy the whole list. > >(David Black, I have your slides of course). > > > >Thanks > > > > Brian > > > >Kwok Ho Chan wrote: > >> > >> Brian, Kathie: > >> Attached is the MSPowerPoint Slides for my presentation in the > >> 47th IETF DiffServ WG Session at Adelaide. Please include them > >> in the Minutes and Proceedings. > >> Thanks! > >> -- Kwok -- > > > > _______________________________________________ diffserv mailing list diffserv@ietf.org http://www1.ietf.org/mailman/listinfo/diffserv Archive: http://www-nrg.ee.lbl.gov/diff-serv-arch/ From diffserv-admin@ietf.org Thu Apr 6 18:19:40 2000 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA15893 for ; Thu, 6 Apr 2000 18:19:40 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id RAA11171; Thu, 6 Apr 2000 17:49:47 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id RAA11140 for ; Thu, 6 Apr 2000 17:49:43 -0400 (EDT) Received: from omega.cisco.com (omega.cisco.com [171.69.63.141]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA15557 for ; Thu, 6 Apr 2000 17:52:04 -0400 (EDT) Received: from cisco.com (dhcp-o-38-206.cisco.com [171.71.38.206]) by omega.cisco.com (8.8.8-Cisco List Logging/8.8.8) with ESMTP id OAA02032; Thu, 6 Apr 2000 14:51:35 -0700 (PDT) Message-ID: <38ED07BB.B18DFA17@cisco.com> Date: Thu, 06 Apr 2000 14:55:07 -0700 From: Kathleen Nichols X-Mailer: Mozilla 4.61 [en] (Win98; U) X-Accept-Language: en MIME-Version: 1.0 To: Nabil Seddigh CC: diffserv@ietf.org Subject: Re: [Diffserv] On RED in a Diffserv MIB References: <200004062052.QAA14539@ietf.org> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: diffserv-admin@ietf.org Errors-To: diffserv-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Diffserv Discussion List X-BeenThere: diffserv@ietf.org Content-Transfer-Encoding: 7bit Context: the minutes will be posted tomorrow apparently. Short context: there was discussion about MIB parameters for RED for the diffserv MIB and Kwok made a presentation with his suggestion. Some discussion ensued but was regretably shortened by running out of time. Nabil Seddigh wrote: > > Kathie > > For those of us not present in Adelaide, can you provide > the context for your comments below. I get the sense > that it's related to MIB definition but am unusure > of the exact connection. > > Thanks > Nabil Seddigh > _______________________________________________ diffserv mailing list diffserv@ietf.org http://www1.ietf.org/mailman/listinfo/diffserv Archive: http://www-nrg.ee.lbl.gov/diff-serv-arch/ From diffserv-admin@ietf.org Thu Apr 6 19:01:29 2000 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA16514 for ; Thu, 6 Apr 2000 19:01:29 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id SAA11636; Thu, 6 Apr 2000 18:29:32 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id SAA11606 for ; Thu, 6 Apr 2000 18:29:28 -0400 (EDT) Received: from kickme.cisco.com (kickme.cisco.com [198.92.30.42]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA16016 for ; Thu, 6 Apr 2000 18:31:49 -0400 (EDT) Received: from rhino (rhino.cisco.com [172.20.9.57]) by kickme.cisco.com (8.9.1a/8.9.1) with ESMTP id PAA27285; Thu, 6 Apr 2000 15:30:27 -0700 (PDT) Received: from p7020-img-nt.cisco.com (rtp-dial-1-5.cisco.com [161.44.116.5]) by rhino (SMI-8.6/CISCO.WS.1.1) with ESMTP id PAA02018; Thu, 6 Apr 2000 15:36:25 -0700 Message-Id: <4.3.1.2.20000406183057.024bf9b0@flipper.cisco.com> X-Sender: fred@flipper.cisco.com X-Mailer: QUALCOMM Windows Eudora Version 4.3.1 Date: Thu, 06 Apr 2000 18:31:14 -0400 To: Kathleen Nichols From: Fred Baker Subject: Re: [Diffserv] On RED in a Diffserv MIB Cc: diffserv@ietf.org In-Reply-To: <38ECE004.FC48F47@cisco.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: diffserv-admin@ietf.org Errors-To: diffserv-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Diffserv Discussion List X-BeenThere: diffserv@ietf.org At 12:05 PM 4/6/00 -0700, Kathleen Nichols wrote: >One of these is that Fred Baker did an >implementation of it in something like Fall of 98 and I believe >he's gotten good results with it, but I won't speak for Fred. Yes, much better results than I got with RED-93 _______________________________________________ diffserv mailing list diffserv@ietf.org http://www1.ietf.org/mailman/listinfo/diffserv Archive: http://www-nrg.ee.lbl.gov/diff-serv-arch/ From diffserv-admin@ietf.org Thu Apr 6 19:04:54 2000 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA16531 for ; Thu, 6 Apr 2000 19:04:54 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id SAA11856; Thu, 6 Apr 2000 18:35:47 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id SAA11825 for ; Thu, 6 Apr 2000 18:35:42 -0400 (EDT) Received: from usc.edu (root@usc.edu [128.125.253.136]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA16065 for ; Thu, 6 Apr 2000 18:38:03 -0400 (EDT) Received: from aludra.usc.edu (demir@aludra.usc.edu [128.125.19.184]) by usc.edu (8.9.3.1/8.9.3/usc) with ESMTP id PAA21447; Thu, 6 Apr 2000 15:36:58 -0700 (PDT) Received: from localhost (demir@localhost) by aludra.usc.edu (8.9.3.1/8.9.3/usc) with ESMTP id PAA08858; Thu, 6 Apr 2000 15:36:58 -0700 (PDT) Date: Thu, 6 Apr 2000 15:36:58 -0700 (PDT) From: demir To: Lixia Zhang cc: diffserv@ietf.org Subject: Re: [Diffserv] question on resource allocation In-Reply-To: <200004061403.HAA10550@aurora.cs.ucla.edu> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: diffserv-admin@ietf.org Errors-To: diffserv-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Diffserv Discussion List X-BeenThere: diffserv@ietf.org Hi, Thank you very much. I agree with your statements. However: > Let me answer your questions one by one. > > - whether BB is also capable of allocating internal resource: I'd repeat > again that is the decision by the owner of the domain, not us. I agree (and I know). My "ORIGINAL" question was: if BB is capable of doing this internal resource allocation or not. Of course, the decision is made by the owner of the domain. > - "BGP is not used as an interior routing protocol": are you sure? > My vague memory says that there are indeed places that use BGP > internally. Again it's nobody else's business. I am not sure. If it is used, my guess would be: between subdomains of a large domain. I guess this discussion does not belong here. > - What do I use: I dont own a net, so I use nothing :-) > If I had a net? well, depending how big it is, I might do different > things, static, use of SNMP to extend my arms, or even a stripped down > version of RSVP (and I'm sure someone would tell me "MPLS"). > in any case, not your business :-) I didn't ask what you use. I asked in "Two-tier architecture" what you use. I know it is not my business. I thought it is a research project, that's why I asked. Alper K. Demir _______________________________________________ diffserv mailing list diffserv@ietf.org http://www1.ietf.org/mailman/listinfo/diffserv Archive: http://www-nrg.ee.lbl.gov/diff-serv-arch/ From diffserv-admin@ietf.org Fri Apr 7 04:02:42 2000 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA04454 for ; Fri, 7 Apr 2000 04:02:42 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id DAA21121; Fri, 7 Apr 2000 03:33:58 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id DAA21015 for ; Fri, 7 Apr 2000 03:33:51 -0400 (EDT) Received: from dv.op.dlr.de (dv.op.dlr.de [129.247.188.46]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA04160 for ; Fri, 7 Apr 2000 03:36:12 -0400 (EDT) Received: from dlr.de ([129.247.173.188]) by dv.op.dlr.de (8.9.3/8.9.3) with ESMTP id JAA61152; Fri, 7 Apr 2000 09:36:08 +0200 Message-ID: <38ED8FE7.8F43A084@dlr.de> Date: Fri, 07 Apr 2000 09:36:08 +0200 From: Carlo Matarasso Organization: DLR X-Mailer: Mozilla 4.7 [en] (WinNT; I) X-Accept-Language: en,de MIME-Version: 1.0 To: Shahram Davari CC: "'Diffserv@ietf.org'" Subject: Re: FW: [Diffserv] EF question !!! References: <336ECDAFDF7DD311B9E30090277AEE4101B40497@nt-exchange-bby.pmc-sierra.bc.ca> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: diffserv-admin@ietf.org Errors-To: diffserv-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Diffserv Discussion List X-BeenThere: diffserv@ietf.org Content-Transfer-Encoding: 7bit Shahram, when you calculate average values in steady state, the time interval you consider has to be independent from its position on the time axis. Yours is not: if you take the 3T interval right after yours, you' ll have 2 EF MTU and 1 BE, that will even up the previous average. In you example you have to consider an interval that contains an evan amount of Ts. If you consider int. = 6T, in this interval the EF rate is 3MTU/6T = MTU/2T = R Carlo Shahram Davari wrote: > "The figure was messed up in previous email. Please use this one:" > > Hi, > > RFC-2598 says: > "EF 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" > > Lets assume 2 PHB queues: an EF and a BE each of rate R (both nicely > shaped). Let's assume the output link rate is 2R so that 50% of the link BW > (=R) is assigned to EF and 50% (=R) to BE. Let's also assume that packet > sizes are all MTU size. Now on the output link we will have EF and BE > packets one after another as following: > > > ---------------------------------------------------------- > | BE | EF | BE | EF | BE | EF | ..... | > ---------------------------------------------------------- > > <-------------------> > 3T > > The duration of each packet at the output link is T= MTU/2R. Now assume the > time from the beginning of a BE packet to the end of another BE packet; this > time = 3T (notice that there is only one EF packet in this interval). Also > the time to send an MTU size packet at EF configured rate is MTU/R = 2T. > > Since 3T > 2T then according to RFC-2598 we should average the configured > rate in the 3T interval. But as you can see the average EF rate in the 3T > interval is MTU/3T = 2R/3 which is 2/3 of the EF configured rate R. > > Either I am missing something or there is a problem with the RFC-2598. > > Any comments? > > > Shahram Davari > Systems Engineer, Product Research > PMC-Sierra Inc. > 555 Legget drive, > Suit 834, Tower B, > Ottawa, ON K2K 2X3, Canada > Phone: +1 (613) 271-4018 > Fax : +1 (613) 271-7007 > > > _______________________________________________ > diffserv mailing list > diffserv@ietf.org > http://www1.ietf.org/mailman/listinfo/diffserv > Archive: http://www-nrg.ee.lbl.gov/diff-serv-arch/ > > _______________________________________________ > diffserv mailing list > diffserv@ietf.org > http://www1.ietf.org/mailman/listinfo/diffserv > Archive: http://www-nrg.ee.lbl.gov/diff-serv-arch/ -- ------------------------------------------------------------------------------------------- DOTT. ING. CARLO MATARASSO carlo.matarasso@dlr.de TEL. +49 8153 28 2848 FAX +49 8153 28 2844 DLR - DEUTSCHES ZENTRUM FUER LUFT UND RAUMFAHRT GERMAN AEROSPACE CENTER www.dlr.de POSTFACH 1116 D - 82230 WESSLING - GERMANY ------------------------------------------------------------------------------------------- _______________________________________________ diffserv mailing list diffserv@ietf.org http://www1.ietf.org/mailman/listinfo/diffserv Archive: http://www-nrg.ee.lbl.gov/diff-serv-arch/ From diffserv-admin@ietf.org Fri Apr 7 11:25:16 2000 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA10322 for ; Fri, 7 Apr 2000 11:25:16 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id KAA25075; Fri, 7 Apr 2000 10:44:35 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id KAA25044 for ; Fri, 7 Apr 2000 10:44:31 -0400 (EDT) Received: from pilgrim.cisco.com (pilgrim.cisco.com [171.69.204.12]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA09416 for ; Fri, 7 Apr 2000 10:46:55 -0400 (EDT) Received: from acharny_pc2 (ch2-dhcp134-226.cisco.com [161.44.134.226]) by pilgrim.cisco.com (8.8.8-Cisco List Logging/8.8.8) with ESMTP id KAA17192; Fri, 7 Apr 2000 10:45:25 -0400 (EDT) Message-Id: <4.2.0.58.20000407103952.00cc5c50@pilgrim.cisco.com> X-Sender: acharny@pilgrim.cisco.com X-Mailer: QUALCOMM Windows Eudora Pro Version 4.2.0.58 Date: Fri, 07 Apr 2000 10:48:37 -0700 To: Carlo Matarasso , Shahram Davari From: Anna Charny Subject: Re: FW: [Diffserv] EF question !!! Cc: "'Diffserv@ietf.org'" In-Reply-To: <38ED8FE7.8F43A084@dlr.de> References: <336ECDAFDF7DD311B9E30090277AEE4101B40497@nt-exchange-bby.pmc-sierra.bc.ca> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: diffserv-admin@ietf.org Errors-To: diffserv-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Diffserv Discussion List X-BeenThere: diffserv@ietf.org Carlo, At 09:36 AM 4/7/00 +0200, Carlo Matarasso wrote: >Shahram, > >when you calculate average values in steady state, the time interval you >consider has to be independent from its position on the time axis. Yours >is not: >if you take the 3T interval right after yours, you' ll have 2 EF MTU and 1 BE, >that will even up the previous average. >In you example you have to consider an interval that contains an evan >amount of >Ts. > >If you consider int. = 6T, in this interval the EF rate is 3MTU/6T = >MTU/2T = R > >Carlo It would seem to me that the requirement that statement "X must /should be true for any interval of length Y or longer" means that whatever interval of length Y or longer you choose to take, statement X must indeed hold in this interval. The fact that you can find *some* intervals for which X is true does not yet mean that X must hold for *any* interval of length Y or longer. Hence your objection to Sharams's observation does not appear to be valid. Did I misunderstand what you wanted to say? Regards, Anna >Shahram Davari wrote: > > > "The figure was messed up in previous email. Please use this one:" > > > > Hi, > > > > RFC-2598 says: > > "EF 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" > > > > Lets assume 2 PHB queues: an EF and a BE each of rate R (both nicely > > shaped). Let's assume the output link rate is 2R so that 50% of the link BW > > (=R) is assigned to EF and 50% (=R) to BE. Let's also assume that packet > > sizes are all MTU size. Now on the output link we will have EF and BE > > packets one after another as following: > > > > > > ---------------------------------------------------------- > > | BE | EF | BE | EF | BE | EF | ..... | > > ---------------------------------------------------------- > > > > <-------------------> > > 3T > > > > The duration of each packet at the output link is T= MTU/2R. Now assume the > > time from the beginning of a BE packet to the end of another BE packet; > this > > time = 3T (notice that there is only one EF packet in this interval). Also > > the time to send an MTU size packet at EF configured rate is MTU/R = 2T. > > > > Since 3T > 2T then according to RFC-2598 we should average the configured > > rate in the 3T interval. But as you can see the average EF rate in the 3T > > interval is MTU/3T = 2R/3 which is 2/3 of the EF configured rate R. > > > > Either I am missing something or there is a problem with the RFC-2598. > > > > Any comments? > > > > > > Shahram Davari > > Systems Engineer, Product Research > > PMC-Sierra Inc. > > 555 Legget drive, > > Suit 834, Tower B, > > Ottawa, ON K2K 2X3, Canada > > Phone: +1 (613) 271-4018 > > Fax : +1 (613) 271-7007 > > > > > > _______________________________________________ > > diffserv mailing list > > diffserv@ietf.org > > http://www1.ietf.org/mailman/listinfo/diffserv > > Archive: http://www-nrg.ee.lbl.gov/diff-serv-arch/ > > > > _______________________________________________ > > diffserv mailing list > > diffserv@ietf.org > > http://www1.ietf.org/mailman/listinfo/diffserv > > Archive: http://www-nrg.ee.lbl.gov/diff-serv-arch/ > >-- >--------------------------------------------------------------------------- >---------------- > >DOTT. ING. CARLO MATARASSO > >carlo.matarasso@dlr.de >TEL. +49 8153 28 2848 >FAX +49 8153 28 2844 > >DLR - DEUTSCHES ZENTRUM FUER LUFT UND RAUMFAHRT >GERMAN AEROSPACE CENTER >www.dlr.de >POSTFACH 1116 >D - 82230 WESSLING - GERMANY > >--------------------------------------------------------------------------- >---------------- > > > > >_______________________________________________ >diffserv mailing list >diffserv@ietf.org >http://www1.ietf.org/mailman/listinfo/diffserv >Archive: http://www-nrg.ee.lbl.gov/diff-serv-arch/ > _______________________________________________ diffserv mailing list diffserv@ietf.org http://www1.ietf.org/mailman/listinfo/diffserv Archive: http://www-nrg.ee.lbl.gov/diff-serv-arch/ From diffserv-admin@ietf.org Fri Apr 7 11:39:25 2000 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA10686 for ; Fri, 7 Apr 2000 11:39:25 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id LAA25445; Fri, 7 Apr 2000 11:07:27 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id LAA25416 for ; Fri, 7 Apr 2000 11:07:22 -0400 (EDT) Received: from procyon.pmc-sierra.bc.ca (procyon.pmc-sierra.bc.ca [134.87.115.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA10026 for ; Fri, 7 Apr 2000 11:09:45 -0400 (EDT) Received: from nt-exchange1.pmc-sierra.bc.ca (nt-exchange1.pmc-sierra.bc.ca [134.87.116.183]) by procyon.pmc-sierra.bc.ca (6.6.6/6.6.6) with ESMTP id IAA08476; Fri, 7 Apr 2000 08:08:44 -0700 (PDT) Received: by nt-exchange1.pmc-sierra.bc.ca with Internet Mail Service (5.5.2650.21) id <2J27TSM9>; Fri, 7 Apr 2000 08:08:43 -0700 Message-ID: <336ECDAFDF7DD311B9E30090277AEE4101B4049E@nt-exchange-bby.pmc-sierra.bc.ca> From: Shahram Davari To: "'Carlo Matarasso'" , Shahram Davari Cc: "'Diffserv@ietf.org'" Subject: RE: FW: [Diffserv] EF question !!! Date: Fri, 7 Apr 2000 08:06:04 -0700 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: text/plain; charset="iso-8859-1" Sender: diffserv-admin@ietf.org Errors-To: diffserv-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Diffserv Discussion List X-BeenThere: diffserv@ietf.org Hi Carlo, I don't understand what you mean by "the time interval should be independent from its position in time?". Do you mean that I should slide the time interval and average it over all the time scale? That doesn't make sense because by doing so you will get your configured rate whether you use EF or not! This example may be solved by requiring a "multiple" of the time that it takes to send an MTU size packet (as you and Siamak also have mentioned). But here is another example where the "multiple" requirement won't help either: Assume "2" EF flow each having a rate of "R" and one BE flow having a rate of "8R". Assume that the output link rate is "10R" to accommodate these flows. Further assume that all packets are of MTU size and the EF flows are shaped and exactly identical. Now using priority queuing (as suggested by RFC-2598) and looking at the time scale, we will have: <--------------------------- time increase ---------------- BE-BE-BE-BE-BE-BE-BE-BE-EF-EF-BE-BE-BE-BE-BE-BE-BE-BE-EF-EF <---------------------><----> 8T 2T The interval of each packet in output link is T=MTU/10R. The time that it takes to send an MTU size packet at the EF configured rate is MTU/2R = 4T. Since the interval 8T shown in the picture is greater than 4T, according to RFC-2598 we should get at least the EF configured rate. But as you can see there is no EF packet in this interval!!! (also note that 8T is a multiple of 4T). Regards, -Shahram >-----Original Message----- >From: Carlo Matarasso [mailto:Carlo.Matarasso@dlr.de] >Sent: Friday, April 07, 2000 3:36 AM >To: Shahram Davari >Cc: 'Diffserv@ietf.org' >Subject: Re: FW: [Diffserv] EF question !!! > > >Shahram, > >when you calculate average values in steady state, the time >interval you >consider has to be independent from its position on the time >axis. Yours is not: >if you take the 3T interval right after yours, you' ll have 2 >EF MTU and 1 BE, >that will even up the previous average. >In you example you have to consider an interval that contains >an evan amount of >Ts. > >If you consider int. = 6T, in this interval the EF rate is >3MTU/6T = MTU/2T = R > >Carlo > >Shahram Davari wrote: > >> "The figure was messed up in previous email. Please use this one:" >> >> Hi, >> >> RFC-2598 says: >> "EF 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" >> >> Lets assume 2 PHB queues: an EF and a BE each of rate R (both nicely >> shaped). Let's assume the output link rate is 2R so that 50% >of the link BW >> (=R) is assigned to EF and 50% (=R) to BE. Let's also assume >that packet >> sizes are all MTU size. Now on the output link we will have EF and BE >> packets one after another as following: >> >> >> ---------------------------------------------------------- >> | BE | EF | BE | EF | BE | EF | ..... | >> ---------------------------------------------------------- >> >> <-------------------> >> 3T >> >> The duration of each packet at the output link is T= MTU/2R. >Now assume the >> time from the beginning of a BE packet to the end of another >BE packet; this >> time = 3T (notice that there is only one EF packet in this >interval). Also >> the time to send an MTU size packet at EF configured rate is >MTU/R = 2T. >> >> Since 3T > 2T then according to RFC-2598 we should average >the configured >> rate in the 3T interval. But as you can see the average EF >rate in the 3T >> interval is MTU/3T = 2R/3 which is 2/3 of the EF configured rate R. >> >> Either I am missing something or there is a problem with the >RFC-2598. >> >> Any comments? >> >> >> Shahram Davari >> Systems Engineer, Product Research >> PMC-Sierra Inc. >> 555 Legget drive, >> Suit 834, Tower B, >> Ottawa, ON K2K 2X3, Canada >> Phone: +1 (613) 271-4018 >> Fax : +1 (613) 271-7007 >> >> >> _______________________________________________ >> diffserv mailing list >> diffserv@ietf.org >> http://www1.ietf.org/mailman/listinfo/diffserv >> Archive: http://www-nrg.ee.lbl.gov/diff-serv-arch/ >> >> _______________________________________________ >> diffserv mailing list >> diffserv@ietf.org >> http://www1.ietf.org/mailman/listinfo/diffserv >> Archive: http://www-nrg.ee.lbl.gov/diff-serv-arch/ > >-- >--------------------------------------------------------------- >---------------------------- > >DOTT. ING. CARLO MATARASSO > >carlo.matarasso@dlr.de >TEL. +49 8153 28 2848 >FAX +49 8153 28 2844 > >DLR - DEUTSCHES ZENTRUM FUER LUFT UND RAUMFAHRT >GERMAN AEROSPACE CENTER >www.dlr.de >POSTFACH 1116 >D - 82230 WESSLING - GERMANY > >--------------------------------------------------------------- >---------------------------- > > > > >_______________________________________________ >diffserv mailing list >diffserv@ietf.org >http://www1.ietf.org/mailman/listinfo/diffserv >Archive: http://www-nrg.ee.lbl.gov/diff-serv-arch/ > _______________________________________________ diffserv mailing list diffserv@ietf.org http://www1.ietf.org/mailman/listinfo/diffserv Archive: http://www-nrg.ee.lbl.gov/diff-serv-arch/ From diffserv-admin@ietf.org Fri Apr 7 12:11:47 2000 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA11301 for ; Fri, 7 Apr 2000 12:11:47 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id LAA25733; Fri, 7 Apr 2000 11:28:54 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id LAA25698 for ; Fri, 7 Apr 2000 11:28:49 -0400 (EDT) Received: from procyon.pmc-sierra.bc.ca (procyon.pmc-sierra.bc.ca [134.87.115.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA10527 for ; Fri, 7 Apr 2000 11:31:13 -0400 (EDT) Received: from nt-exchange1.pmc-sierra.bc.ca (nt-exchange1.pmc-sierra.bc.ca [134.87.116.183]) by procyon.pmc-sierra.bc.ca (6.6.6/6.6.6) with ESMTP id IAA10187; Fri, 7 Apr 2000 08:30:26 -0700 (PDT) Received: by nt-exchange1.pmc-sierra.bc.ca with Internet Mail Service (5.5.2650.21) id <2J27TSV2>; Fri, 7 Apr 2000 08:29:11 -0700 Message-ID: <336ECDAFDF7DD311B9E30090277AEE4101B4049F@nt-exchange-bby.pmc-sierra.bc.ca> From: Shahram Davari To: "'ROBERTS James FTRD/DAC/ISS'" , Jean-Yves Le Boudec , "'Kathleen Nichols'" Cc: diffserv@ietf.org Subject: RE: [Diffserv] problems with Virtual Wire and RFC2598 Date: Fri, 7 Apr 2000 08:26:25 -0700 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: text/plain; charset="iso-8859-1" Sender: diffserv-admin@ietf.org Errors-To: diffserv-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Diffserv Discussion List X-BeenThere: diffserv@ietf.org Hi, I think Roberts has a point here. This case can't be explained by RFC-2598 either. Regards, -Shahram >-----Original Message----- >From: ROBERTS James FTRD/DAC/ISS >[mailto:james.roberts@rd.francetelecom.fr] >Sent: Tuesday, March 28, 2000 8:18 AM >To: Jean-Yves Le Boudec; 'Kathleen Nichols' >Cc: diffserv@ietf.org >Subject: RE: [Diffserv] problems with Virtual Wire and RFC2598 > > >I share Jean-Yves' doubts. One specific problem is the >condition applied in >the draft to explain why an EF packet cannot wait behind >another packet from >the same customer. > >It is stated that the EF property ensures that a customer EF >stream of rate >R is served at rate R, averaged over any time scale of S/R or >longer. In >fact, the EF property in question in RFC 2598 applies to the >configured rate >for the EF traffic aggregate. > >To say each customer stream is served at its nominal rate in >any interval as >short as its interpacket interval seems to imply synchronous >switching: the >period must be conserved exactly. > >Applying the EF property as in RFC 2598 (ie, for the >aggregate) does not >keep all the packets of one stream in their jitter window in >the following >case. >One stream of rate R is aggregated with m streams of rate r<aggregate is served at rate X > R+mr. Assume constant packet >size. Suppose >all the little streams generate one packet just before a >packet arrives from >the big stream so that the latter is delayed by m packet slots. It is >sufficient that m/X >1/R for the succeeding big stream packet >to catch up >and be delayed by its predecessor. The delay is proportional >to m and can be >made as big as we like by choosing r sufficiently small. > >Jim > > > > >> ---------- >> De : Kathleen Nichols[SMTP:kmn@cisco.com] >> Date : mardi 28 mars 2000 03:13 >> A : Jean-Yves Le Boudec >> Cc : diffserv@ietf.org >> Objet : Re: [Diffserv] problems with Virtual Wire and RFC2598 >> >> >> >> Jean-Yves Le Boudec wrote: >> > >> > I have some problems understanding RFC2598 and >> > draft-ietf-diffserv-ba-vw-00 >> > >> > a) RFC2598 requires that the service given to an aggregate flow >> > guarantees a rate down to a small time scale and further gives as >> > example >> > "A simple priority queue will give the appropriate >behavior as long as >> > there is no higher priority queue that could preempt the >EF for more >> > than a packet time at the configured rate. " >> > >> > I have the impression that this statement ignores the phenomenon of >> > jitter accumulation due to aggregate multiplexing. When >several flows >> > share their fate in a multiplex, then there is >accumulation of jitter >> > from network node to network node, well beyond the bounds given in >> > this internet draft. The fact that flows are shaped at the network >> > input does not guarantee a bound on jitter after several hops. Some >> > bounds do exist, but they are not straightforward, and it >is not even >> > clear whether finite bounds exist in all cases where the maximum >> > network utilization factor is less than 1. In the particular case >> > where the network topology is a ring, the answer is yes, >however, in >> > general, it is unknown (as far as I know). See for example the >> > references below. >> > >> >> So this is what a lot of the discussion in the vw draft is >> attempting to address. We've tried to spell out what >> the assumptions are and how they get used. I'm hoping >> that in today's meeting we can figure out what is >> missing in the explanation so the next roll can make >> this clearer. Anna Charney's work uses a different set >> of assumptions. >> >> There are some university folks who believe they can work >> out the analysis under the assumptions we work under. >> Hopefully, they'll get something worked out and made >> publically available. >> >> > It seems to me that the only way to guarantee the requirement >> > described in RFC2598 is to shape every aggregate at the output of >> > *every* network node, a solution that requires per aggregate >> > information which is not compatible with diffserv. >> >> This comes out under Charney's assumptions since they are >> no more restrictive than the rules we assume for individual >> domains. Thus this is like the rules for shaping at the >> edge of every domain. >> >> Kathie >> >> _______________________________________________ >> diffserv mailing list >> diffserv@ietf.org >> http://www.ietf.org/mailman/listinfo/diffserv >> Archive: http://www-nrg.ee.lbl.gov/diff-serv-arch/ >> > >_______________________________________________ >diffserv mailing list >diffserv@ietf.org >http://www.ietf.org/mailman/listinfo/diffserv >Archive: http://www-nrg.ee.lbl.gov/diff-serv-arch/ > _______________________________________________ diffserv mailing list diffserv@ietf.org http://www1.ietf.org/mailman/listinfo/diffserv Archive: http://www-nrg.ee.lbl.gov/diff-serv-arch/ From diffserv-admin@ietf.org Fri Apr 7 12:24:45 2000 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA11608 for ; Fri, 7 Apr 2000 12:24:45 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id LAA26163; Fri, 7 Apr 2000 11:52:38 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id LAA26104 for ; Fri, 7 Apr 2000 11:52:33 -0400 (EDT) Received: from smtprtp1.ntcom.nortel.net (smtprtp1.ntcom.nortel.net [137.118.22.14]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA10897 for ; Fri, 7 Apr 2000 11:54:57 -0400 (EDT) Received: from zcard00n.ca.nortel.com (actually zcard00n) by smtprtp1.ntcom.nortel.net; Fri, 7 Apr 2000 11:27:28 -0400 Received: from zbl6c002.corpeast.baynetworks.com ([132.245.205.52]) by zcard00n.ca.nortel.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2650.21) id 2M70K9LL; Fri, 7 Apr 2000 11:27:27 -0400 Received: from nortelnetworks.com (dhcp223-154.engeast.baynetworks.com [192.32.223.154]) by zbl6c002.corpeast.baynetworks.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2650.21) id HNW5F06R; Fri, 7 Apr 2000 11:27:23 -0400 Message-ID: <38EDFE73.4ED1E9AC@nortelnetworks.com> Date: Fri, 07 Apr 2000 11:27:47 -0400 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: [Diffserv] On RED in a Diffserv MIB References: <38ECE004.FC48F47@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 Dear diffserv-ers, we apologize for abusing this list with an out-of-scope message, but we feel obligated to respond to a recent message that has a work of ours as a direct target. First, we strongly reject all allegations of borrowing of any kind. Our paper: "A study of active queue management for congestion control" by Victor Firoiu and Marty Borden, published in Infocom 2000, http://www.ieee-infocom.org/2000/papers/405.pdf is based only on the widely accepted model for TCP throughput: "Modeling TCP throughput: a simple model and its empirical validation" by J.Padhye,V.Firoiu,D.Towsley, J.Kurose, published in Sigcomm 1998. http://www.acm.org/sigcomm/sigcomm98/tp/abs_25.html and on our extensive experiments both simulated and implemented. Our results relevant to the DS MIB discussion have been reinforced and confirmed by many other contributions including: Floyd, S., Recommendation on using the "gentle_" variant of RED http://www.aciri.org/floyd/red/gentle.html V. Rosolen, Bonaventure, O., and G. Leduc, A RED discard strategy for ATM networks and its performance evaluation with TCP/IP traffic, ACM Computer Communication Review, July 1999, http://www.info.fundp.ac.be/~obo/biblio.html Impact of cell discard strategies on TCP/IP in ATM UBR networks, Proc. of the 6th Workshop on Performance Modelling and Evaluation of ATM Networks (IFIP ATM'98) Ilkley, UK, July 98. http://www-run.montefiore.ulg.ac.be/publications/papers/abstract-PP98-02.html Analytic Evaluation of RED Performance Martin May (INRIA), Thomas Bonald (INRIA), Jean Bolot(ENSIM) http://www.ieee-infocom.org/2000/papers/369.ps Regarding the technical merits of different studies and architectures for queue management, we are open for discussions. Probably a good place is the end2end-interest mail list, where we have submitted and discussed our above works. Sincerely yours -- Victor Firoiu and Marty Borden _______________________________________________ diffserv mailing list diffserv@ietf.org http://www1.ietf.org/mailman/listinfo/diffserv Archive: http://www-nrg.ee.lbl.gov/diff-serv-arch/ From diffserv-admin@ietf.org Fri Apr 7 12: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 ESMTP id MAA11986 for ; Fri, 7 Apr 2000 12:41:20 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id MAA26766; Fri, 7 Apr 2000 12:14:33 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id MAA26733 for ; Fri, 7 Apr 2000 12:14:23 -0400 (EDT) Received: from shultz.argon.com (shultz.argon.com [208.234.161.2]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA11379 for ; Fri, 7 Apr 2000 12:16:46 -0400 (EDT) Received: from argon.com ([10.10.0.191]) by shultz.argon.com (8.10.0/8.10.0) with ESMTP id e37GFFg14741; Fri, 7 Apr 2000 12:15:15 -0400 (EDT) Message-ID: <38EE0998.4BAF10E3@argon.com> Date: Fri, 07 Apr 2000 12:15:20 -0400 From: Qin Zheng X-Mailer: Mozilla 4.72 [en] (WinNT; U) X-Accept-Language: en MIME-Version: 1.0 To: Shahram Davari CC: "'Carlo Matarasso'" , "'Diffserv@ietf.org'" Subject: Re: FW: [Diffserv] EF question !!! References: <336ECDAFDF7DD311B9E30090277AEE4101B4049E@nt-exchange-bby.pmc-sierra.bc.ca> Content-Type: text/plain; charset=gb2312 Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: diffserv-admin@ietf.org Errors-To: diffserv-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 adding that the time interval to measure an EF flow throughput should alway start at a time when a packet of the EF flow is sent? Qin Shahram Davari wrote: > Hi Carlo, > > I don't understand what you mean by "the time interval should be independent > from its position in time?". Do you mean that I should slide the time > interval and average it over all the time scale? That doesn't make sense > because by doing so you will get your configured rate whether you use EF or > not! > > This example may be solved by requiring a "multiple" of the time that it > takes to send an MTU size packet (as you and Siamak also have mentioned). > But here is another example where the "multiple" requirement won't help > either: > > Assume "2" EF flow each having a rate of "R" and one BE flow having a rate > of "8R". Assume that the output link rate is "10R" to accommodate these > flows. Further assume that all packets are of MTU size and the EF flows are > shaped and exactly identical. Now using priority queuing (as suggested by > RFC-2598) and looking at the time scale, we will have: > > <--------------------------- time increase ---------------- > > BE-BE-BE-BE-BE-BE-BE-BE-EF-EF-BE-BE-BE-BE-BE-BE-BE-BE-EF-EF > <---------------------><----> > 8T 2T > > The interval of each packet in output link is T=MTU/10R. The time that it > takes to send an MTU size packet at the EF configured rate is MTU/2R = 4T. > Since the interval 8T shown in the picture is greater than 4T, according to > RFC-2598 we should get at least the EF configured rate. But as you can see > there is no EF packet in this interval!!! (also note that 8T is a multiple > of 4T). > > Regards, > > -Shahram > > > > >-----Original Message----- > >From: Carlo Matarasso [mailto:Carlo.Matarasso@dlr.de] > >Sent: Friday, April 07, 2000 3:36 AM > >To: Shahram Davari > >Cc: 'Diffserv@ietf.org' > >Subject: Re: FW: [Diffserv] EF question !!! > > > > > >Shahram, > > > >when you calculate average values in steady state, the time > >interval you > >consider has to be independent from its position on the time > >axis. Yours is not: > >if you take the 3T interval right after yours, you' ll have 2 > >EF MTU and 1 BE, > >that will even up the previous average. > >In you example you have to consider an interval that contains > >an evan amount of > >Ts. > > > >If you consider int. = 6T, in this interval the EF rate is > >3MTU/6T = MTU/2T = R > > > >Carlo > > > >Shahram Davari wrote: > > > >> "The figure was messed up in previous email. Please use this one:" > >> > >> Hi, > >> > >> RFC-2598 says: > >> "EF 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" > >> > >> Lets assume 2 PHB queues: an EF and a BE each of rate R (both nicely > >> shaped). Let's assume the output link rate is 2R so that 50% > >of the link BW > >> (=R) is assigned to EF and 50% (=R) to BE. Let's also assume > >that packet > >> sizes are all MTU size. Now on the output link we will have EF and BE > >> packets one after another as following: > >> > >> > >> ---------------------------------------------------------- > >> | BE | EF | BE | EF | BE | EF | ..... | > >> ---------------------------------------------------------- > >> > >> <-------------------> > >> 3T > >> > >> The duration of each packet at the output link is T= MTU/2R. > >Now assume the > >> time from the beginning of a BE packet to the end of another > >BE packet; this > >> time = 3T (notice that there is only one EF packet in this > >interval). Also > >> the time to send an MTU size packet at EF configured rate is > >MTU/R = 2T. > >> > >> Since 3T > 2T then according to RFC-2598 we should average > >the configured > >> rate in the 3T interval. But as you can see the average EF > >rate in the 3T > >> interval is MTU/3T = 2R/3 which is 2/3 of the EF configured rate R. > >> > >> Either I am missing something or there is a problem with the > >RFC-2598. > >> > >> Any comments? > >> > >> > >> Shahram Davari > >> Systems Engineer, Product Research > >> PMC-Sierra Inc. > >> 555 Legget drive, > >> Suit 834, Tower B, > >> Ottawa, ON K2K 2X3, Canada > >> Phone: +1 (613) 271-4018 > >> Fax : +1 (613) 271-7007 > >> > >> > >> _______________________________________________ > >> diffserv mailing list > >> diffserv@ietf.org > >> http://www1.ietf.org/mailman/listinfo/diffserv > >> Archive: http://www-nrg.ee.lbl.gov/diff-serv-arch/ > >> > >> _______________________________________________ > >> diffserv mailing list > >> diffserv@ietf.org > >> http://www1.ietf.org/mailman/listinfo/diffserv > >> Archive: http://www-nrg.ee.lbl.gov/diff-serv-arch/ > > > >-- > >--------------------------------------------------------------- > >---------------------------- > > > >DOTT. ING. CARLO MATARASSO > > > >carlo.matarasso@dlr.de > >TEL. +49 8153 28 2848 > >FAX +49 8153 28 2844 > > > >DLR - DEUTSCHES ZENTRUM FUER LUFT UND RAUMFAHRT > >GERMAN AEROSPACE CENTER > >www.dlr.de > >POSTFACH 1116 > >D - 82230 WESSLING - GERMANY > > > >--------------------------------------------------------------- > >---------------------------- > > > > > > > > > >_______________________________________________ > >diffserv mailing list > >diffserv@ietf.org > >http://www1.ietf.org/mailman/listinfo/diffserv > >Archive: http://www-nrg.ee.lbl.gov/diff-serv-arch/ > > > > _______________________________________________ > diffserv mailing list > diffserv@ietf.org > http://www1.ietf.org/mailman/listinfo/diffserv > Archive: http://www-nrg.ee.lbl.gov/diff-serv-arch/ _______________________________________________ diffserv mailing list diffserv@ietf.org http://www1.ietf.org/mailman/listinfo/diffserv Archive: http://www-nrg.ee.lbl.gov/diff-serv-arch/ From diffserv-admin@ietf.org Fri Apr 7 12:46:46 2000 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA12067 for ; Fri, 7 Apr 2000 12:46:46 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id MAA26919; Fri, 7 Apr 2000 12:21:04 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id MAA26883 for ; Fri, 7 Apr 2000 12:20:51 -0400 (EDT) Received: from kuma.upv.es (kuma.cc.upv.es [158.42.4.6]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA11567 for ; Fri, 7 Apr 2000 12:23:00 -0400 (EDT) Received: from vega.upv.es (vega.cc.upv.es [158.42.4.1]) by kuma.upv.es (8.9.3/8.9.3) with ESMTP id SAA05575; Fri, 7 Apr 2000 18:22:32 +0200 Received: from dcom.upv.es (cdma.dcom.upv.es [158.42.32.84]) by vega.upv.es (8.8.4/8.8.5) with ESMTP id SAA12004; Fri, 7 Apr 2000 18:22:32 +0200 (METDST) Message-ID: <38EDFE1E.179D4419@dcom.upv.es> Date: Fri, 07 Apr 2000 17:26:22 +0200 From: Vicent Pla X-Mailer: Mozilla 4.6 [en] (X11; I; Linux 2.0.34 i686) X-Accept-Language: en MIME-Version: 1.0 To: Shahram Davari CC: "'Diffserv@ietf.org'" Subject: Re: FW: [Diffserv] EF question !!! References: <336ECDAFDF7DD311B9E30090277AEE4101B40497@nt-exchange-bby.pmc-sierra.bc.ca> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: diffserv-admin@ietf.org Errors-To: diffserv-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Diffserv Discussion List X-BeenThere: diffserv@ietf.org Content-Transfer-Encoding: 7bit Shahram Davari wrote: > "The figure was messed up in previous email. Please use this one:" > > Hi, > > RFC-2598 says: > "EF 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" > > Lets assume 2 PHB queues: an EF and a BE each of rate R (both nicely > shaped). Let's assume the output link rate is 2R so that 50% of the link BW > (=R) is assigned to EF and 50% (=R) to BE. Let's also assume that packet > sizes are all MTU size. Now on the output link we will have EF and BE > packets one after another as following: > > > ---------------------------------------------------------- > | BE | EF | BE | EF | BE | EF | ..... | > ---------------------------------------------------------- > > <-------------------> > 3T > > The duration of each packet at the output link is T= MTU/2R. Now assume the > time from the beginning of a BE packet to the end of another BE packet; this > time = 3T (notice that there is only one EF packet in this interval). Also > the time to send an MTU size packet at EF configured rate is MTU/R = 2T. > > Since 3T > 2T then according to RFC-2598 we should average the configured > rate in the 3T interval. But as you can see the average EF rate in the 3T > interval is MTU/3T = 2R/3 which is 2/3 of the EF configured rate R. > > Either I am missing something or there is a problem with the RFC-2598. > > Any comments? When I read RFC-2598 I assumed EF queue didn't empty during the measured time interval. I think the case you described above doesn't fit this requirement. Indeed, if such constraint isn't assumed, a much simpler EF traffic arrival pattern, namely, no EF arrivals for an "interval equal to or longer than the time it takes to send an output link MTU sized packet at the configured rate" will contradict the RFC-2598 requirement. -- Vicent _______________________________________________ diffserv mailing list diffserv@ietf.org http://www1.ietf.org/mailman/listinfo/diffserv Archive: http://www-nrg.ee.lbl.gov/diff-serv-arch/ From diffserv-admin@ietf.org Fri Apr 7 12:56:39 2000 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA12428 for ; Fri, 7 Apr 2000 12:56:39 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id MAA27050; Fri, 7 Apr 2000 12:28:58 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id MAA27021 for ; Fri, 7 Apr 2000 12:28:54 -0400 (EDT) Received: from pilgrim.cisco.com (pilgrim.cisco.com [171.69.204.12]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA11786 for ; Fri, 7 Apr 2000 12:31:16 -0400 (EDT) Received: from acharny_pc2 (ch2-dhcp134-226.cisco.com [161.44.134.226]) by pilgrim.cisco.com (8.8.8-Cisco List Logging/8.8.8) with ESMTP id MAA03228; Fri, 7 Apr 2000 12:30:21 -0400 (EDT) Message-Id: <4.2.0.58.20000407110638.00cdd6e0@pilgrim.cisco.com> X-Sender: acharny@pilgrim.cisco.com X-Mailer: QUALCOMM Windows Eudora Pro Version 4.2.0.58 Date: Fri, 07 Apr 2000 12:33:32 -0700 To: Shahram Davari , "'Diffserv@ietf.org'" From: Anna Charny Subject: Re: FW: [Diffserv] EF question !!! In-Reply-To: <336ECDAFDF7DD311B9E30090277AEE4101B40497@nt-exchange-bby.p mc-sierra.bc.ca> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: diffserv-admin@ietf.org Errors-To: diffserv-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Diffserv Discussion List X-BeenThere: diffserv@ietf.org Shahram, At 11:07 AM 4/6/00 -0700, Shahram Davari wrote: >"The figure was messed up in previous email. Please use this one:" > >Hi, > >RFC-2598 says: >"EF 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" > >Lets assume 2 PHB queues: an EF and a BE each of rate R (both nicely >shaped). Let's assume the output link rate is 2R so that 50% of the link BW >(=R) is assigned to EF and 50% (=R) to BE. Let's also assume that packet >sizes are all MTU size. Now on the output link we will have EF and BE >packets one after another as following: > > >---------------------------------------------------------- >| BE | EF | BE | EF | BE | EF | ..... | >---------------------------------------------------------- > > <-------------------> > 3T > > >The duration of each packet at the output link is T= MTU/2R. Now assume the >time from the beginning of a BE packet to the end of another BE packet; this >time = 3T (notice that there is only one EF packet in this interval). Also >the time to send an MTU size packet at EF configured rate is MTU/R = 2T. > >Since 3T > 2T then according to RFC-2598 we should average the configured >rate in the 3T interval. But as you can see the average EF rate in the 3T >interval is MTU/3T = 2R/3 which is 2/3 of the EF configured rate R. > >Either I am missing something or there is a problem with the RFC-2598. It seems to me that in this particular example there is really no actual problem, because in the interval of length 3T you consider there is only a single EF packet in the queue, assuming the packets arrive ideally space at the rate, as I think you have done. I think the statement that a queue must receive some service X only applies to the case when there are actually packets in that queue to send. Otherwise it is impossible in principle to guarantee this even if there is just a single EF stream on a link with absolutely no contention from BE (That is, just remove BE packets in your example - if EF packets arrive ideally spaced, they will also leave ideally spaced, since there is no contention, but it would still be the case that there will be intervals of length 3T where only one EF packet will be served). I think that as far as the *total* aggregate of all EF "streams" on a given link goes, it does receive the service R (in the case of priority FIFO implementation) over any interval of length MTU/R or longer *as long as the EF queue is continuously backlogged during that interval*, and as long as rate of EF does not exceed C/2, where C is the capacity of the link. To see this, consider some a busy period (t1, t2) of the EF queue, where t1 is the time when the queue changed its state from being empty to being busy, and t2 is the first time after t1 when the queue became empty again (we do not care here whether t2 is finite or not). In the case of strict priority queueing, the EF queue will be continuously served from time t1 <= t3 <=t1 + MTU/C until the queue becomes empty. That is because a BE packet may be served in the interval (t1, t3). So for any interval of the form (t4, t5) of length > MTU/R , where t3<=t4<=t5<=t2, the EF queue receives the service equal to (t5-t4)C bits which is strictly greater than its ideal service (t5-t4)R that it should have received in this interval. So for any such interval the statement of RFC 2598 is correct. Now consider any interval (t6, t7) such that t1<=t6<=t3 <=t7<=t2. (Note that in order for (t6, t7) be longer than MTU/R, t7 must be greater than t3). In any such interval the EF queue is continuously backlogged, but in the interval (t1, t3) no EF bits are served. So the amount of service that will be received by the EF queue in the interval (t6, t7) is at least (t7-t3)C >= (t7-t6)C - MTU bits. So the average rate that the EF aggregate will get over (t6, t7) is equal to C - MTU/(t7-t6) >= C - MTU/(MTU/R) = C-R >= 2R - R >= R. Since (t1, t2) is an arbitrary busy period, this covers all possible cases of continuously busy intervals of length MTU/R or greater. This shows that in any interval of time longer than or equal to MTU/R *in which the priority queue is continuously backlogged* AND the EF rate does not exceed 50% of the speed of the link, the EF queue does receive its average rate R. Now, as I argued above, it does not seem reasonable to request that this holds for *ANY* interval MTU/R or longer in which the queue is *not* necessarily continuously backlogged - as your example shows - so it seems that a reasonable thing to do might be to put a clarification in RFC 2598 that it only requires the rate for "busy" intervals only, and that the 50% rate limitation is necessary. I am not sure what the procedure is of updating RFC's , though. Note that if the EF queue is not served at highest priority (such as in the case of a class-based WFQ scheduler) , the start time of service for a busy queue may be longer than MTU/C, which would lead to a tighter than 50% limitation on Ef aggregate rate. Finally, it seems important to emphasize that while the above is true for a total EF aggregate on the link (subject to 50% limitation and the requirement that the service is computed over busy periods only) , it is no longer true for individual "EF streams" of which the total EF aggregate on a link is composed. Jim Robert's example and Jean-Yves Le Boudec's concerns in an earlier message relate to those "streams", or "edge-to-edge aggregates", as discussed in the VW draft. But RFC 2598 seems to apply to EF BA understood as *total link* EF aggregates, as defined in RFC 2475: DS behavior aggregate a collection of packets with the same DS codepoint crossing a link in a particular direction. I hope this helps. Regards, Anna >Any comments? > > >Shahram Davari >Systems Engineer, Product Research >PMC-Sierra Inc. >555 Legget drive, >Suit 834, Tower B, >Ottawa, ON K2K 2X3, Canada >Phone: +1 (613) 271-4018 >Fax : +1 (613) 271-7007 > > > >_______________________________________________ >diffserv mailing list >diffserv@ietf.org >http://www1.ietf.org/mailman/listinfo/diffserv >Archive: http://www-nrg.ee.lbl.gov/diff-serv-arch/ > >_______________________________________________ >diffserv mailing list >diffserv@ietf.org >http://www1.ietf.org/mailman/listinfo/diffserv >Archive: http://www-nrg.ee.lbl.gov/diff-serv-arch/ > _______________________________________________ diffserv mailing list diffserv@ietf.org http://www1.ietf.org/mailman/listinfo/diffserv Archive: http://www-nrg.ee.lbl.gov/diff-serv-arch/ From diffserv-admin@ietf.org Fri Apr 7 18:39:39 2000 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA20590 for ; Fri, 7 Apr 2000 18:39:39 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id RAA01422; Fri, 7 Apr 2000 17:50:01 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id RAA01393 for ; Fri, 7 Apr 2000 17:49:57 -0400 (EDT) Received: from rerun.lucentctc.com (rerun.lucentctc.com [199.93.237.2]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA19867 for ; Fri, 7 Apr 2000 17:51:51 -0400 (EDT) Received: by rerun.lucentctc.com with Internet Mail Service (5.5.2448.0) id ; Fri, 7 Apr 2000 17:51:21 -0400 Message-ID: <75ADD7496F0BD211ADC000104B8846CF019116BA@rerun.lucentctc.com> From: "Weiss, Walter" To: diffserv@ietf.org Cc: "'Brian E Carpenter'" , "'Kathleen Nichols'" Date: Fri, 7 Apr 2000 17:51:13 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2448.0) Content-Type: text/plain; charset="iso-8859-1" Subject: [Diffserv] DiffServ minutes (draft version) Sender: diffserv-admin@ietf.org Errors-To: diffserv-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Diffserv Discussion List X-BeenThere: diffserv@ietf.org Meeting minutes for the DiffServ WG meetings in Adelaide, AU Brian Carpenter (for David Black) presented a draft for Tunnels with DiffServ. Changes from previous draft. This version is shorter. It also recommended that tunnels be able to require that exiting traffic undergo diffserv traffic conditioning. There was also significant cleanup of the text. The tunnel egress node has to decide whether to use the inner or outer codepoint. There was an earlier proposal to use DSCP 0 as an indicator of whether to use the inner or outer codepoint value. The conclusion was that this was the wrong approach and that this choice should be determined through configuration of the egress node. Additional issue: Suitably configured/provisioned VPN tunnel makes ingress and egress nodes "virtually contiguous". Currently this concept is described using the term "same diffserv domain" but this may not be the right phrase. This should not require an RFC update because RFC 2475 requires that the ingress and egress be in the same domain. An additional question was whether to add a list of tunnel types. Tunnels are discussed in numerous RFCs including IPSEC and NGTRANS. Should references to these various RFCs be included in David's draft? This will take a while and involve other WGs. Current text does not update EF RFC to eliminate EF requirement in outer header, should it? John Wroclawski pointed out that this was not unique to EF. This will be input to eventual revision of RFC 2475. Brian asked whether this draft should be a standards track or informational. Juha suggested that this work should be considered in a larger context (MPLS). John W. argued that if the draft is informational, the SHOULDs and REQUIREDs need to be removed. Fred suggested that the choice of egress header determination is sufficient as a sentence in a future rev of the header document. Joel thought that this clarification is deserving of a RFC because there was confusion on the topic. Someone mentioned that the MPLS folks are referring to this document. Juha thought that the document should be generalized beyond specifically specifying IP. He would prefer to see a draft describing the mappings of DSCPs in generic tunnels. General consensus was that this document could be moved on an informational RFC track with appropriate adjustments and support from the TSV area directors. Andrew Smith discussed the alignment of the conceptual model with the MIB and the PIB. Some issues relate to terminology (discarder vs. dropper). There are also some structural issues that are being worked. Andrew is suggesting that many of the inconsistent concepts need to be moved from the MIB to the model. There are a number of open issues: 1. There is a difference in interpretation of the token bucket behavior between the model and the MIB. Kathie indicated that the problem was that one description allows a packet to be sent when there are some tokens but not enough for the full packet size while the other description only allows a packet to be sent when there are enough packets for the full packet. Fred implemented the partial token approach in the MIB to cover the case where the bucket size was smaller than the packet size. Fred also pointed out that his description was of a meter (ingress) while Kathie was talking about a shaper (egress). Kathie and John W. wanted to define the conservative definition (requiring a token value greater than the packet size). Kathie indicated that she wanted the model (as opposed to the MIB) to be more conservative. There was agreement to continue this on the mailing list. 2. Should a classifier be part of a TCB? Model assumes yes while the MIB assumes no. Andrew will make the model align with the MIB. 3. Should MPLS be discussed in either document? General discussion suggested that less focus should be given to MPLS. 4. Should the model include discussion of non-DSCP markers? Loosen wording in the model document to allow other markers (802.1, or labels). Because the MIB is specific to DiffServ, the MIB document should not be loosened. 5. The meter in [SRTCM] cannot be precisely modeled using two two-parameter token buckets because its two buckets do not accumulate credits independently. Do we need to show how the [TRTCM] meter should be implemented? There was no time to discuss this. 6. Are the current examples for queues, scheduling and buffer management sufficient? Kathie stated that as these are still areas of research and that we ought to be less precise about specifying particular algorithms. 7. Is the description of a shaper sufficient? Andrew would like additional comments on section 7.2. Juha suggested that there are some boxes that can shape both on the ingress and the egress. A number of people agreed and Andrew said he would clarify the text. 8. Does the concept of a Queue Set belong in the model (and the MIB). Dan Grossman would prefer to see the Queue Set concept removed. Andrew believes that Queue Sets allow information to be shared between queues such as shared buffering. DiffServ MIB Open Issues (Andrew) Breakdown of objects into: core, optional and "no way". Each attribute needs to be evaluated to determine its status. There needs to be agreement on conformance statements. Closer alignment with the Conceptual Model is also an issue: 0. One example is difference in terminology (discarder vs. dropper). Brian would like to see the two converge. The justification for the difference in terminology is that the organization of the components is different between the MIB and the model. The dropper was for AF traffic that does not conform. A discarder drops all packets. Yoram suggested that this was a special case of a dropper. John W. wanted to name everything a dropper (absolute and algorithmic). Another terminology item was 'counter' vs. 'monitor'. John W. noted that "a monitor is a lizard". Consensus was that all references should be to counters. 1. Cascaded token-buckets are not equivalent to a multi-rate token-bucket: do we need to fix this by allowing a multi-rate TB in the MIB or by defining cascaded buckets to mean "multi-rate"? John W. believes they are not the same thing. Fred and Andrew will discuss this further. 2. Markers were resolved earlier in the discussion where it was agreed that the MIB would only define DSCP markers. 3. Counters: be part of various modules (dropping, scheduling, etc.) or should a separate monitor block be specified. This issue was not given any discussion time. 4. Queue Sets: already discussed previously. 5. Do we need scheduling units of 'packets' (as opposed to KBPS or BPS)? Not discussed. 6. Are absolute rates sufficient or should we include "relative to line speed" ones as well? Not discussed. 7. Scheduler parameters defined in weights vs. rates vs. priorities: the proposed text is confusing. Andrew wanted to use only rates and priorities. Not discussed in the meeting. DiffServ PIB Issues (Michael Fine) Michael reviewed the benefits of the PIB. He then discussed the need for 'roles'. There are 4 fundamental PIB elements: Interface Types/Capabilities, Filters/Classifiers, Meters/Actions, and Queues/Thresholds. There are Capability Policy Rule Classes for specifying the capabilities of classification, policing, and scheduling components in devices. Joel was concerned that the classification was too implementation specific and inconsistent with the conceptual model. This discussion was not concluded and will be moved to the list. (second session) Brian noted that folks were confused about why behavior aggregate work was part of the charter, even though this was agreed to in December. Kathie presented an overview of the BA draft. The intent of the BA draft is to expand on the BA definition that has been used loosely in DiffServ to date. Another desire was to put in place a process for defining generally useful BAs. Kathie wanted to have the group consider whether these BA documents should be experimental or informational RFCs. A BA should define what Traffic Conditioning is used and how per-hop-behaviors should be specified. Juha questioned the need for this work. Kathie argued that BA definition was a useful step toward defining services and that particular BA defnitions were not required of network operators. Van provided a review of the virtual wire BA draft. The purpose of the VW BA is to support circuit-oriented traffic over an IP backbone. The jitter window for any packet in the VW BA is a function of the time slots in the circuit switched network at the egress of the IP network. Therefore, higher link speeds in the IP network will allow larger jitter windows at the egress of the IP network. This additional jitter window allows the order of packet processing due to collisions between different customer packets within the same BA to be immaterial to the service. Dan Grossman is still confused about the use and scope of BAs in DiffServ. Scott Brim believes that BAs are a good thing to do, but he agrees with Dan that the BA doc is poorly specified. Fred asked whether the BA specification are to be used to help construct domain specific services. Kathie indicated that this was the intent of these drafts. This discussion will continue on the list. Kwok reviewed current changes to the MIB. Kwok spent most of the time discussing the dropper model being proposed in the MIB. Van commented that a dropper curve should not be specified. Van also believes the parameters proposed in the Firiou and Borden paper referenced by Kwok will result in a poorly functioning RED. _______________________________________________ diffserv mailing list diffserv@ietf.org http://www1.ietf.org/mailman/listinfo/diffserv Archive: http://www-nrg.ee.lbl.gov/diff-serv-arch/ From diffserv-admin@ietf.org Fri Apr 7 19:29:36 2000 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA21021 for ; Fri, 7 Apr 2000 19:29:36 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id TAA02400; Fri, 7 Apr 2000 19:06:53 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id TAA02298 for ; Fri, 7 Apr 2000 19:06:47 -0400 (EDT) Received: from dv.op.dlr.de (dv.op.dlr.de [129.247.188.46]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA20851 for ; Fri, 7 Apr 2000 19:09:11 -0400 (EDT) Received: from zeus.nt.op.dlr.de (zeus.nt.op.dlr.de [129.247.173.3]) by dv.op.dlr.de (8.9.3/8.9.3) with ESMTP id BAA20142; Sat, 8 Apr 2000 01:09:03 +0200 Received: from dlr.de (pcdn188_nt_op [129.247.173.188]) by zeus.nt.op.dlr.de (8.9.1b+Sun/8.9.1) with ESMTP id SAA10324; Fri, 7 Apr 2000 18:29:44 +0200 (MET DST) Message-ID: <38EE0C6F.91A00026@dlr.de> Date: Fri, 07 Apr 2000 18:27:28 +0200 From: Carlo Matarasso Organization: DLR X-Mailer: Mozilla 4.7 [en] (WinNT; I) X-Accept-Language: en,de MIME-Version: 1.0 To: Shahram Davari CC: "'Diffserv@ietf.org'" , Anna Charny Subject: Re: FW: [Diffserv] EF question !!! References: <336ECDAFDF7DD311B9E30090277AEE4101B4049E@nt-exchange-bby.pmc-sierra.bc.ca> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: diffserv-admin@ietf.org Errors-To: diffserv-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Diffserv Discussion List X-BeenThere: diffserv@ietf.org Content-Transfer-Encoding: 7bit Shahram, my observation is that the output signal is periodic with period = 2T. Averages should be made on time intervals that are integer multiple of its period (2T,4T,6T.....). regarding your second example, again you have a periodic signal with period = 10T, so correct time intervals are, in my opinion, 10T, 20T..... Let me also point out that in your second example you write "The interval of each packet in output link is T=MTU/10R" then you write "MTU/2R = 4T" but if T=MTU/10R then MTU/2R = 5T but if you consider 5T you violate the Nyquist principle and you get aliasing in your result. again I think that only 10T, 20T...... give significant results. please correct me if I'm wrong ! have a nice weekend Carlo Shahram Davari wrote: > Hi Carlo, > > I don't understand what you mean by "the time interval should be independent > from its position in time?". Do you mean that I should slide the time > interval and average it over all the time scale? That doesn't make sense > because by doing so you will get your configured rate whether you use EF or > not! > > This example may be solved by requiring a "multiple" of the time that it > takes to send an MTU size packet (as you and Siamak also have mentioned). > But here is another example where the "multiple" requirement won't help > either: > > Assume "2" EF flow each having a rate of "R" and one BE flow having a rate > of "8R". Assume that the output link rate is "10R" to accommodate these > flows. Further assume that all packets are of MTU size and the EF flows are > shaped and exactly identical. Now using priority queuing (as suggested by > RFC-2598) and looking at the time scale, we will have: > > <--------------------------- time increase ---------------- > > BE-BE-BE-BE-BE-BE-BE-BE-EF-EF-BE-BE-BE-BE-BE-BE-BE-BE-EF-EF > <---------------------><----> > 8T 2T > > The interval of each packet in output link is T=MTU/10R. The time that it > takes to send an MTU size packet at the EF configured rate is MTU/2R = 4T. > Since the interval 8T shown in the picture is greater than 4T, according to > RFC-2598 we should get at least the EF configured rate. But as you can see > there is no EF packet in this interval!!! (also note that 8T is a multiple > of 4T). > > Regards, > > -Shahram > > > > >-----Original Message----- > >From: Carlo Matarasso [mailto:Carlo.Matarasso@dlr.de] > >Sent: Friday, April 07, 2000 3:36 AM > >To: Shahram Davari > >Cc: 'Diffserv@ietf.org' > >Subject: Re: FW: [Diffserv] EF question !!! > > > > > >Shahram, > > > >when you calculate average values in steady state, the time > >interval you > >consider has to be independent from its position on the time > >axis. Yours is not: > >if you take the 3T interval right after yours, you' ll have 2 > >EF MTU and 1 BE, > >that will even up the previous average. > >In you example you have to consider an interval that contains > >an evan amount of > >Ts. > > > >If you consider int. = 6T, in this interval the EF rate is > >3MTU/6T = MTU/2T = R > > > >Carlo > > > >Shahram Davari wrote: > > > >> "The figure was messed up in previous email. Please use this one:" > >> > >> Hi, > >> > >> RFC-2598 says: > >> "EF 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" > >> > >> Lets assume 2 PHB queues: an EF and a BE each of rate R (both nicely > >> shaped). Let's assume the output link rate is 2R so that 50% > >of the link BW > >> (=R) is assigned to EF and 50% (=R) to BE. Let's also assume > >that packet > >> sizes are all MTU size. Now on the output link we will have EF and BE > >> packets one after another as following: > >> > >> > >> ---------------------------------------------------------- > >> | BE | EF | BE | EF | BE | EF | ..... | > >> ---------------------------------------------------------- > >> > >> <-------------------> > >> 3T > >> > >> The duration of each packet at the output link is T= MTU/2R. > >Now assume the > >> time from the beginning of a BE packet to the end of another > >BE packet; this > >> time = 3T (notice that there is only one EF packet in this > >interval). Also > >> the time to send an MTU size packet at EF configured rate is > >MTU/R = 2T. > >> > >> Since 3T > 2T then according to RFC-2598 we should average > >the configured > >> rate in the 3T interval. But as you can see the average EF > >rate in the 3T > >> interval is MTU/3T = 2R/3 which is 2/3 of the EF configured rate R. > >> > >> Either I am missing something or there is a problem with the > >RFC-2598. > >> > >> Any comments? > >> > >> > >> Shahram Davari > >> Systems Engineer, Product Research > >> PMC-Sierra Inc. > >> 555 Legget drive, > >> Suit 834, Tower B, > >> Ottawa, ON K2K 2X3, Canada > >> Phone: +1 (613) 271-4018 > >> Fax : +1 (613) 271-7007 > >> > >> > >> _______________________________________________ > >> diffserv mailing list > >> diffserv@ietf.org > >> http://www1.ietf.org/mailman/listinfo/diffserv > >> Archive: http://www-nrg.ee.lbl.gov/diff-serv-arch/ > >> > >> _______________________________________________ > >> diffserv mailing list > >> diffserv@ietf.org > >> http://www1.ietf.org/mailman/listinfo/diffserv > >> Archive: http://www-nrg.ee.lbl.gov/diff-serv-arch/ > > > >-- > >--------------------------------------------------------------- > >---------------------------- > > > >DOTT. ING. CARLO MATARASSO > > > >carlo.matarasso@dlr.de > >TEL. +49 8153 28 2848 > >FAX +49 8153 28 2844 > > > >DLR - DEUTSCHES ZENTRUM FUER LUFT UND RAUMFAHRT > >GERMAN AEROSPACE CENTER > >www.dlr.de > >POSTFACH 1116 > >D - 82230 WESSLING - GERMANY > > > >--------------------------------------------------------------- > >---------------------------- > > > > > > > > > >_______________________________________________ > >diffserv mailing list > >diffserv@ietf.org > >http://www1.ietf.org/mailman/listinfo/diffserv > >Archive: http://www-nrg.ee.lbl.gov/diff-serv-arch/ > > -- ------------------------------------------------------------------------------------------- DOTT. ING. CARLO MATARASSO carlo.matarasso@dlr.de TEL. +49 8153 28 2848 FAX +49 8153 28 2844 DLR - DEUTSCHES ZENTRUM FUER LUFT UND RAUMFAHRT GERMAN AEROSPACE CENTER www.dlr.de POSTFACH 1116 D - 82230 WESSLING - GERMANY ------------------------------------------------------------------------------------------- _______________________________________________ diffserv mailing list diffserv@ietf.org http://www1.ietf.org/mailman/listinfo/diffserv Archive: http://www-nrg.ee.lbl.gov/diff-serv-arch/ From diffserv-admin@ietf.org Mon Apr 10 05:39:24 2000 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA03962 for ; Mon, 10 Apr 2000 05:39:24 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id EAA09603; Mon, 10 Apr 2000 04:44:20 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id EAA09572 for ; Mon, 10 Apr 2000 04:44:12 -0400 (EDT) Received: from warp.seabridge.co.il (warp.seabridge.co.il [212.25.127.242]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA03550 for ; Mon, 10 Apr 2000 04:46:39 -0400 (EDT) Received: from tiger.seabridge.co.il (tiger.seabridge.co.il [172.30.10.1]) by warp.seabridge.co.il (8.9.3/8.9.3) with ESMTP id MAA28823 for ; Mon, 10 Apr 2000 12:58:00 +0300 Received: by tiger.seabridge.co.il with Internet Mail Service (5.5.2650.21) id <2MHFH5R8>; Mon, 10 Apr 2000 10:43:42 +0200 Message-ID: From: Doron Hirsch To: diffserv@ietf.org Date: Mon, 10 Apr 2000 10:43:35 +0200 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01BFA2C8.DF8CA3C0" Subject: [Diffserv] Status of "A Fair Marker" Sender: diffserv-admin@ietf.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_01BFA2C8.DF8CA3C0 Content-Type: text/plain; charset="iso-8859-1" Hi, Could you please tell me what is the status of the draft "A Fair Marker". The draft wasn't updated since April 1999 and expired on October 1999. Thanks in advance, Doron. Hirsch Doron doron.hirsch@seabridge.co.il ------_=_NextPart_001_01BFA2C8.DF8CA3C0 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Status of "A Fair Marker"

Hi,

Could you please tell me what is the status of the = draft <draft-kim-fairmarker-diffserv-00.txt> "A Fair = Marker".
The draft wasn't updated since April 1999 and = expired on October 1999.

Thanks in advance,

Doron.


Hirsch Doron
doron.hirsch@seabridge.co.il

------_=_NextPart_001_01BFA2C8.DF8CA3C0-- _______________________________________________ diffserv mailing list diffserv@ietf.org http://www1.ietf.org/mailman/listinfo/diffserv Archive: http://www-nrg.ee.lbl.gov/diff-serv-arch/ From diffserv-admin@ietf.org Mon Apr 10 10: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 ESMTP id KAA13468 for ; Mon, 10 Apr 2000 10:18:23 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id JAA12334; Mon, 10 Apr 2000 09:30:50 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id JAA12308 for ; Mon, 10 Apr 2000 09:30:45 -0400 (EDT) Received: from procyon.pmc-sierra.bc.ca (procyon.pmc-sierra.bc.ca [134.87.115.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA10841 for ; Mon, 10 Apr 2000 09:33:14 -0400 (EDT) Received: from nt-exchange1.pmc-sierra.bc.ca (nt-exchange1.pmc-sierra.bc.ca [134.87.116.183]) by procyon.pmc-sierra.bc.ca (6.6.6/6.6.6) with ESMTP id GAA00653; Mon, 10 Apr 2000 06:33:08 -0700 (PDT) Received: by nt-exchange1.pmc-sierra.bc.ca with Internet Mail Service (5.5.2650.21) id <2J274CSD>; Mon, 10 Apr 2000 06:33:08 -0700 Message-ID: <336ECDAFDF7DD311B9E30090277AEE4101B404AA@nt-exchange-bby.pmc-sierra.bc.ca> From: Shahram Davari To: "'Carlo Matarasso'" , Shahram Davari Cc: "'Diffserv@ietf.org'" , Anna Charny Subject: RE: FW: [Diffserv] EF question !!! Date: Mon, 10 Apr 2000 06:30:30 -0700 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: text/plain; charset="iso-8859-1" Sender: diffserv-admin@ietf.org Errors-To: diffserv-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Diffserv Discussion List X-BeenThere: diffserv@ietf.org Hi Carlo, Apart from the little mistake that I had in my 2nd example, I think I prefer Anna's explanation: "EF should average its configured rate over any interval greater than the time that takes to send an MTU size packet with configured rate, provided that the EF queue is not empty" Because it can explain the rule even when the configured EF rate is higher that the actual EF rate. Probably the second part of the sentence: "... provided that the EF queue is not empty" is implicit in RFC-2598! Regards, -Shahram >-----Original Message----- >From: Carlo Matarasso [mailto:Carlo.Matarasso@dlr.de] >Sent: Friday, April 07, 2000 12:27 PM >To: Shahram Davari >Cc: 'Diffserv@ietf.org'; Anna Charny >Subject: Re: FW: [Diffserv] EF question !!! > > >Shahram, >my observation is that the output signal is periodic with >period = 2T. Averages >should be made on time intervals that are integer multiple of >its period >(2T,4T,6T.....). > >regarding your second example, again you have a periodic >signal with period = >10T, so correct time intervals are, in my opinion, 10T, 20T..... >Let me also point out that in your second example you write > >"The interval of each packet in output link is T=MTU/10R" > >then you write > >"MTU/2R = 4T" > >but if T=MTU/10R then MTU/2R = 5T > >but if you consider 5T you violate the Nyquist principle and >you get aliasing in >your result. > >again I think that only 10T, 20T...... give significant results. > >please correct me if I'm wrong ! > >have a nice weekend > >Carlo > > >Shahram Davari wrote: > >> Hi Carlo, >> >> I don't understand what you mean by "the time interval >should be independent >> from its position in time?". Do you mean that I should slide the time >> interval and average it over all the time scale? That >doesn't make sense >> because by doing so you will get your configured rate >whether you use EF or >> not! >> >> This example may be solved by requiring a "multiple" of the >time that it >> takes to send an MTU size packet (as you and Siamak also >have mentioned). >> But here is another example where the "multiple" requirement >won't help >> either: >> >> Assume "2" EF flow each having a rate of "R" and one BE flow >having a rate >> of "8R". Assume that the output link rate is "10R" to >accommodate these >> flows. Further assume that all packets are of MTU size and >the EF flows are >> shaped and exactly identical. Now using priority queuing (as >suggested by >> RFC-2598) and looking at the time scale, we will have: >> >> <--------------------------- time increase ---------------- >> >> BE-BE-BE-BE-BE-BE-BE-BE-EF-EF-BE-BE-BE-BE-BE-BE-BE-BE-EF-EF >> <---------------------><----> >> 8T 2T >> >> The interval of each packet in output link is T=MTU/10R. The >time that it >> takes to send an MTU size packet at the EF configured rate >is MTU/2R = 4T. >> Since the interval 8T shown in the picture is greater than >4T, according to >> RFC-2598 we should get at least the EF configured rate. But >as you can see >> there is no EF packet in this interval!!! (also note that 8T >is a multiple >> of 4T). >> >> Regards, >> >> -Shahram >> >> >> >> >-----Original Message----- >> >From: Carlo Matarasso [mailto:Carlo.Matarasso@dlr.de] >> >Sent: Friday, April 07, 2000 3:36 AM >> >To: Shahram Davari >> >Cc: 'Diffserv@ietf.org' >> >Subject: Re: FW: [Diffserv] EF question !!! >> > >> > >> >Shahram, >> > >> >when you calculate average values in steady state, the time >> >interval you >> >consider has to be independent from its position on the time >> >axis. Yours is not: >> >if you take the 3T interval right after yours, you' ll have 2 >> >EF MTU and 1 BE, >> >that will even up the previous average. >> >In you example you have to consider an interval that contains >> >an evan amount of >> >Ts. >> > >> >If you consider int. = 6T, in this interval the EF rate is >> >3MTU/6T = MTU/2T = R >> > >> >Carlo >> > >> >Shahram Davari wrote: >> > >> >> "The figure was messed up in previous email. Please use this one:" >> >> >> >> Hi, >> >> >> >> RFC-2598 says: >> >> "EF 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" >> >> >> >> Lets assume 2 PHB queues: an EF and a BE each of rate R >(both nicely >> >> shaped). Let's assume the output link rate is 2R so that 50% >> >of the link BW >> >> (=R) is assigned to EF and 50% (=R) to BE. Let's also assume >> >that packet >> >> sizes are all MTU size. Now on the output link we will >have EF and BE >> >> packets one after another as following: >> >> >> >> >> >> ---------------------------------------------------------- >> >> | BE | EF | BE | EF | BE | EF | ..... | >> >> ---------------------------------------------------------- >> >> >> >> <-------------------> >> >> 3T >> >> >> >> The duration of each packet at the output link is T= MTU/2R. >> >Now assume the >> >> time from the beginning of a BE packet to the end of another >> >BE packet; this >> >> time = 3T (notice that there is only one EF packet in this >> >interval). Also >> >> the time to send an MTU size packet at EF configured rate is >> >MTU/R = 2T. >> >> >> >> Since 3T > 2T then according to RFC-2598 we should average >> >the configured >> >> rate in the 3T interval. But as you can see the average EF >> >rate in the 3T >> >> interval is MTU/3T = 2R/3 which is 2/3 of the EF >configured rate R. >> >> >> >> Either I am missing something or there is a problem with the >> >RFC-2598. >> >> >> >> Any comments? >> >> >> >> >> >> Shahram Davari >> >> Systems Engineer, Product Research >> >> PMC-Sierra Inc. >> >> 555 Legget drive, >> >> Suit 834, Tower B, >> >> Ottawa, ON K2K 2X3, Canada >> >> Phone: +1 (613) 271-4018 >> >> Fax : +1 (613) 271-7007 >> >> >> >> >> >> _______________________________________________ >> >> diffserv mailing list >> >> diffserv@ietf.org >> >> http://www1.ietf.org/mailman/listinfo/diffserv >> >> Archive: http://www-nrg.ee.lbl.gov/diff-serv-arch/ >> >> >> >> _______________________________________________ >> >> diffserv mailing list >> >> diffserv@ietf.org >> >> http://www1.ietf.org/mailman/listinfo/diffserv >> >> Archive: http://www-nrg.ee.lbl.gov/diff-serv-arch/ >> > >> >-- >> >--------------------------------------------------------------- >> >---------------------------- >> > >> >DOTT. ING. CARLO MATARASSO >> > >> >carlo.matarasso@dlr.de >> >TEL. +49 8153 28 2848 >> >FAX +49 8153 28 2844 >> > >> >DLR - DEUTSCHES ZENTRUM FUER LUFT UND RAUMFAHRT >> >GERMAN AEROSPACE CENTER >> >www.dlr.de >> >POSTFACH 1116 >> >D - 82230 WESSLING - GERMANY >> > >> >--------------------------------------------------------------- >> >---------------------------- >> > >> > >> > >> > >> >_______________________________________________ >> >diffserv mailing list >> >diffserv@ietf.org >> >http://www1.ietf.org/mailman/listinfo/diffserv >> >Archive: http://www-nrg.ee.lbl.gov/diff-serv-arch/ >> > > >-- >--------------------------------------------------------------- >---------------------------- > >DOTT. ING. CARLO MATARASSO > >carlo.matarasso@dlr.de >TEL. +49 8153 28 2848 >FAX +49 8153 28 2844 > >DLR - DEUTSCHES ZENTRUM FUER LUFT UND RAUMFAHRT >GERMAN AEROSPACE CENTER >www.dlr.de >POSTFACH 1116 >D - 82230 WESSLING - GERMANY > >--------------------------------------------------------------- >---------------------------- > > > > >_______________________________________________ >diffserv mailing list >diffserv@ietf.org >http://www1.ietf.org/mailman/listinfo/diffserv >Archive: http://www-nrg.ee.lbl.gov/diff-serv-arch/ > _______________________________________________ diffserv mailing list diffserv@ietf.org http://www1.ietf.org/mailman/listinfo/diffserv Archive: http://www-nrg.ee.lbl.gov/diff-serv-arch/ From diffserv-admin@ietf.org Mon Apr 10 11:33:57 2000 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA18313 for ; Mon, 10 Apr 2000 11:33:57 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id LAA13526; Mon, 10 Apr 2000 11:05:22 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id LAA13495 for ; Mon, 10 Apr 2000 11:05:18 -0400 (EDT) Received: from sj-msg-core-crit.cisco.com (sj-msg-core-crit.cisco.com [171.71.163.10]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA16339 for ; Mon, 10 Apr 2000 11:07:46 -0400 (EDT) Received: from proxy1.cisco.com (proxy1.cisco.com [192.31.7.88]) by sj-msg-core-crit.cisco.com (8.9.3/8.9.1) with SMTP id IAA02764 for ; Mon, 10 Apr 2000 08:07:15 -0700 (PDT) Received: from smtp1.cluster.oleane.net (smtp1.cluster.oleane.net [195.25.12.16]) by proxy1.cisco.com with SMTP (MailShield v1.5); Mon, 10 Apr 2000 08:07:16 -0700 Received: from oleane (dyn-1-1-040.Vin.dialup.oleane.fr [195.25.4.40]) by smtp1.cluster.oleane.net with SMTP id RAA97418 for ; Mon, 10 Apr 2000 17:05:58 +0200 (CEST) Message-ID: <00ee01bfa2fd$994191a0$0401a8c0@oleane.com> From: "Peter Lewis" To: Date: Mon, 10 Apr 2000 17:01:06 +0200 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_00EB_01BFA30E.5C873E20" 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 X-SMTP-HELO: smtp1.cluster.oleane.net X-SMTP-MAIL-FROM: peter.lewis@upperside.fr X-SMAP-Received-From: outside X-SMTP-PEER-INFO: smtp1.cluster.oleane.net [195.25.12.16] Subject: [Diffserv] IP Policing 2000 Sender: diffserv-admin@ietf.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_00EB_01BFA30E.5C873E20 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable IP Policing 2000, Paris, 12-15 September =20 The need to police IP networks has grown in importance with the rise of = a new generation of applications such as VPNs, VoIP or IPSec. Approaches under consideration include COPS, DEN/LDAP and PIB, but their = ultimate potential remains undecided. =20 See: http://www.upperside.fr/baippol.htm ------=_NextPart_000_00EB_01BFA30E.5C873E20 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
IP Policing 2000, Paris, = 12-15=20 September
 
The need to police IP = networks has=20 grown in importance with the rise of a new generation of applications = such as=20 VPNs, VoIP or IPSec.
Approaches under consideration include COPS, = DEN/LDAP=20 and PIB, but their ultimate potential remains undecided.
 
See:
http://www.upperside.fr/baip= pol.htm
 
------=_NextPart_000_00EB_01BFA30E.5C873E20-- _______________________________________________ diffserv mailing list diffserv@ietf.org http://www1.ietf.org/mailman/listinfo/diffserv Archive: http://www-nrg.ee.lbl.gov/diff-serv-arch/ From diffserv-admin@ietf.org Mon Apr 10 11:35:06 2000 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA18428 for ; Mon, 10 Apr 2000 11:35:05 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id LAA13618; Mon, 10 Apr 2000 11:10:55 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id LAA13586 for ; Mon, 10 Apr 2000 11:10:51 -0400 (EDT) Received: from mail-gw.hursley.ibm.com (mail-gw.hursley.ibm.com [194.196.110.15]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA16631 for ; Mon, 10 Apr 2000 11:13:14 -0400 (EDT) Received: from sp3at21.hursley.ibm.com (sp3at21.hursley.ibm.com [9.20.45.21]) by mail-gw.hursley.ibm.com (AIX4.3/UCB 8.8.8/8.8.8) with ESMTP id QAA21408; Mon, 10 Apr 2000 16:12:38 +0100 Received: from hursley.ibm.com (gsine02.us.sine.ibm.com [9.14.6.42]) by sp3at21.hursley.ibm.com (AIX4.2/UCB 8.7/8.7.3) with ESMTP id QAA18622; Mon, 10 Apr 2000 16:12:42 +0100 (BST) Message-ID: <38F1EF4A.F962A4B@hursley.ibm.com> Date: Mon, 10 Apr 2000 10:12:10 -0500 From: Brian E Carpenter Organization: IBM X-Mailer: Mozilla 4.61 [en] (Win98; I) X-Accept-Language: en,fr MIME-Version: 1.0 To: Doron Hirsch CC: diffserv@ietf.org Subject: Re: [Diffserv] Status of "A Fair Marker" 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 It's not a work item of the diffserv WG. Brian Carpenter diffserv co-chair > Doron Hirsch wrote: > > Hi, > > Could you please tell me what is the status of the draft "A Fair Marker". > The draft wasn't updated since April 1999 and expired on October 1999. > > Thanks in advance, > > Doron. > > Hirsch Doron > doron.hirsch@seabridge.co.il _______________________________________________ diffserv mailing list diffserv@ietf.org http://www1.ietf.org/mailman/listinfo/diffserv Archive: http://www-nrg.ee.lbl.gov/diff-serv-arch/ From diffserv-admin@ietf.org Mon Apr 10 17:50:26 2000 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA05386 for ; Mon, 10 Apr 2000 17:50:26 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id RAA17783; Mon, 10 Apr 2000 17:19:38 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id RAA17752 for ; Mon, 10 Apr 2000 17:19:34 -0400 (EDT) Received: from sol.extremenetworks.com (sol.extremenetworks.com [216.52.8.2]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA04884 for ; Mon, 10 Apr 2000 17:22:02 -0400 (EDT) Received: by SOL with Internet Mail Service (5.5.2650.21) id ; Mon, 10 Apr 2000 14:19:31 -0700 Message-ID: <808F64DDB492D3119D3C00508B5D8D733EC723@SOL> From: Andrew Smith To: "Diffserv (E-mail)" Date: Mon, 10 Apr 2000 14:19:30 -0700 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: text/plain; charset="iso-8859-1" Subject: [Diffserv] My slides from IETF-47 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 ftp://ftp.extremenetworks.com/pub/outgoing/docs/andrew/smith-diffserv-model- 0300.ppt ftp://ftp.extremenetworks.com/pub/outgoing/docs/andrew/smith-diffserv-mib-03 00.ppt These will get converted into PDF in due course, for inclusion in the proceedings [Note: you will probably need to re-assemble split lines in the URLs above]. Andrew **************************************************************** Andrew Smith tel: +1 (408) 579-2821 Extreme Networks fax: +1 (408) 579-3000 3585 Monroe St. http://www.extremenetworks.com Santa Clara CA 95051-1450 em: andrew@extremenetworks.com **************************************************************** _______________________________________________ diffserv mailing list diffserv@ietf.org http://www1.ietf.org/mailman/listinfo/diffserv Archive: http://www-nrg.ee.lbl.gov/diff-serv-arch/ From diffserv-admin@ietf.org Mon Apr 10 19: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 ESMTP id TAA06411 for ; Mon, 10 Apr 2000 19:08:22 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id SAA18534; Mon, 10 Apr 2000 18:31:08 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id SAA18509 for ; Mon, 10 Apr 2000 18:31:04 -0400 (EDT) Received: from howler.tri.sbc.com (howler.tri.sbc.com [205.173.58.4]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA06000 for ; Mon, 10 Apr 2000 18:33:32 -0400 (EDT) Received: from sbctri.tri.sbc.com (sbctri [144.60.1.10]) by howler.tri.sbc.com (8.9.3/8.9.3) with ESMTP id RAA05803; Mon, 10 Apr 2000 17:35:13 -0500 (CDT) Received: from trimail2.tri.sbc.com (trimail2 [144.60.55.227]) by sbctri.tri.sbc.com (8.9.3/8.9.3) with ESMTP id RAA10328; Mon, 10 Apr 2000 17:33:02 -0500 (CDT) Received: by trimail2.tri.sbc.com with Internet Mail Service (5.5.2448.0) id <142AB89W>; Mon, 10 Apr 2000 17:33:02 -0500 Message-ID: <4D45BA2A58A7D3119E050008C7E69E29055DA7@trimail2.tri.sbc.com> From: "Zhao, Yongdong" To: "'Anna Charny'" Cc: "'Diffserv@ietf.org'" Subject: RE: FW: [Diffserv] EF question !!! Date: Mon, 10 Apr 2000 17:32:59 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2448.0) Content-Type: text/plain; charset="iso-8859-1" Sender: diffserv-admin@ietf.org Errors-To: diffserv-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Diffserv Discussion List X-BeenThere: diffserv@ietf.org Hi, It seems to me that there are still problems on the service rate definition even if you only consider busy period. Here is an example. First some assumptions: (1) queue is built up from time T_0=0, i.e. queue is empty before time T_0, (2) EF packet size is L, (3) it takes S(second) for a packet being switched into the queue, (e.g. s=L/C, C is the fabric bandwidth) (4) it takes R(second) to pull a packet out of the queue, (e.g. r=L/D, D is the port bandwidth) (5) a packet can be served only after the entire packet has been saved in the queue. Now from T_0=0 to T_1=S, The first packet is put into the queue. The EF queue cannot be served even though the queue is continuously built up. From T_1=S to T_2=S+R, the EF queue receives service. Now assume that right before the queue is about to be empty, i.e. at time T_2 -e where e<<1, another packet starts to arrive the queue. The second will be fully in the queue at time T_3=S+R-e+S. Now from T_0=0 to T_3=2S+R-e, the EF queue is served for T_2-T_1=R (second). Certainly T_3-T_1 is larger than the MTU/Port_bandwidth=R, and the queue is not empty during this period of time. But if the service rate is measured over this time interval, the percentage of bandwidth received by EF queue is R/(2S+R-e)=1/(1+2S/R-e/R). Assume that e/R<<1, the percentage of bandwidth received by the EF queue becomes approximately 1/(1+2S/R). Now with situation of S/R=1, such as in routers where one line card can host only one port, only 1/3 of the port bandwidth is received by the EF queue. It seems that the EF service rate should be measured over "practically interesting" time scale. Is the time scale of serving a single packet of the MTU size the "practically interesting" time scale for EF service, probably not. Best regards, Yongdong Zhao SBC Technology Resources, Inc. -----Original Message----- From: Anna Charny [mailto:acharny@cisco.com] Sent: Friday, April 07, 2000 2:34 PM To: Shahram Davari; 'Diffserv@ietf.org' Subject: Re: FW: [Diffserv] EF question !!! Shahram, At 11:07 AM 4/6/00 -0700, Shahram Davari wrote: >"The figure was messed up in previous email. Please use this one:" > >Hi, > >RFC-2598 says: >"EF 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" > >Lets assume 2 PHB queues: an EF and a BE each of rate R (both nicely >shaped). Let's assume the output link rate is 2R so that 50% of the link BW >(=R) is assigned to EF and 50% (=R) to BE. Let's also assume that packet >sizes are all MTU size. Now on the output link we will have EF and BE >packets one after another as following: > > >---------------------------------------------------------- >| BE | EF | BE | EF | BE | EF | ..... | >---------------------------------------------------------- > > <-------------------> > 3T > > >The duration of each packet at the output link is T= MTU/2R. Now assume the >time from the beginning of a BE packet to the end of another BE packet; this >time = 3T (notice that there is only one EF packet in this interval). Also >the time to send an MTU size packet at EF configured rate is MTU/R = 2T. > >Since 3T > 2T then according to RFC-2598 we should average the configured >rate in the 3T interval. But as you can see the average EF rate in the 3T >interval is MTU/3T = 2R/3 which is 2/3 of the EF configured rate R. > >Either I am missing something or there is a problem with the RFC-2598. It seems to me that in this particular example there is really no actual problem, because in the interval of length 3T you consider there is only a single EF packet in the queue, assuming the packets arrive ideally space at the rate, as I think you have done. I think the statement that a queue must receive some service X only applies to the case when there are actually packets in that queue to send. Otherwise it is impossible in principle to guarantee this even if there is just a single EF stream on a link with absolutely no contention from BE (That is, just remove BE packets in your example - if EF packets arrive ideally spaced, they will also leave ideally spaced, since there is no contention, but it would still be the case that there will be intervals of length 3T where only one EF packet will be served). I think that as far as the *total* aggregate of all EF "streams" on a given link goes, it does receive the service R (in the case of priority FIFO implementation) over any interval of length MTU/R or longer *as long as the EF queue is continuously backlogged during that interval*, and as long as rate of EF does not exceed C/2, where C is the capacity of the link. To see this, consider some a busy period (t1, t2) of the EF queue, where t1 is the time when the queue changed its state from being empty to being busy, and t2 is the first time after t1 when the queue became empty again (we do not care here whether t2 is finite or not). In the case of strict priority queueing, the EF queue will be continuously served from time t1 <= t3 <=t1 + MTU/C until the queue becomes empty. That is because a BE packet may be served in the interval (t1, t3). So for any interval of the form (t4, t5) of length > MTU/R , where t3<=t4<=t5<=t2, the EF queue receives the service equal to (t5-t4)C bits which is strictly greater than its ideal service (t5-t4)R that it should have received in this interval. So for any such interval the statement of RFC 2598 is correct. Now consider any interval (t6, t7) such that t1<=t6<=t3 <=t7<=t2. (Note that in order for (t6, t7) be longer than MTU/R, t7 must be greater than t3). In any such interval the EF queue is continuously backlogged, but in the interval (t1, t3) no EF bits are served. So the amount of service that will be received by the EF queue in the interval (t6, t7) is at least (t7-t3)C >= (t7-t6)C - MTU bits. So the average rate that the EF aggregate will get over (t6, t7) is equal to C - MTU/(t7-t6) >= C - MTU/(MTU/R) = C-R >= 2R - R >= R. Since (t1, t2) is an arbitrary busy period, this covers all possible cases of continuously busy intervals of length MTU/R or greater. This shows that in any interval of time longer than or equal to MTU/R *in which the priority queue is continuously backlogged* AND the EF rate does not exceed 50% of the speed of the link, the EF queue does receive its average rate R. Now, as I argued above, it does not seem reasonable to request that this holds for *ANY* interval MTU/R or longer in which the queue is *not* necessarily continuously backlogged - as your example shows - so it seems that a reasonable thing to do might be to put a clarification in RFC 2598 that it only requires the rate for "busy" intervals only, and that the 50% rate limitation is necessary. I am not sure what the procedure is of updating RFC's , though. Note that if the EF queue is not served at highest priority (such as in the case of a class-based WFQ scheduler) , the start time of service for a busy queue may be longer than MTU/C, which would lead to a tighter than 50% limitation on Ef aggregate rate. Finally, it seems important to emphasize that while the above is true for a total EF aggregate on the link (subject to 50% limitation and the requirement that the service is computed over busy periods only) , it is no longer true for individual "EF streams" of which the total EF aggregate on a link is composed. Jim Robert's example and Jean-Yves Le Boudec's concerns in an earlier message relate to those "streams", or "edge-to-edge aggregates", as discussed in the VW draft. But RFC 2598 seems to apply to EF BA understood as *total link* EF aggregates, as defined in RFC 2475: DS behavior aggregate a collection of packets with the same DS codepoint crossing a link in a particular direction. I hope this helps. Regards, Anna >Any comments? > > >Shahram Davari >Systems Engineer, Product Research >PMC-Sierra Inc. >555 Legget drive, >Suit 834, Tower B, >Ottawa, ON K2K 2X3, Canada >Phone: +1 (613) 271-4018 >Fax : +1 (613) 271-7007 > > > >_______________________________________________ >diffserv mailing list >diffserv@ietf.org >http://www1.ietf.org/mailman/listinfo/diffserv >Archive: http://www-nrg.ee.lbl.gov/diff-serv-arch/ > >_______________________________________________ >diffserv mailing list >diffserv@ietf.org >http://www1.ietf.org/mailman/listinfo/diffserv >Archive: http://www-nrg.ee.lbl.gov/diff-serv-arch/ > _______________________________________________ diffserv mailing list diffserv@ietf.org http://www1.ietf.org/mailman/listinfo/diffserv Archive: http://www-nrg.ee.lbl.gov/diff-serv-arch/ _______________________________________________ diffserv mailing list diffserv@ietf.org http://www1.ietf.org/mailman/listinfo/diffserv Archive: http://www-nrg.ee.lbl.gov/diff-serv-arch/ From diffserv-admin@ietf.org Mon Apr 10 19:45:31 2000 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA07021 for ; Mon, 10 Apr 2000 19:45:31 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id TAA18940; Mon, 10 Apr 2000 19:14:02 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id TAA18909 for ; Mon, 10 Apr 2000 19:13:58 -0400 (EDT) Received: from pilgrim.cisco.com (pilgrim.cisco.com [171.69.204.12]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA06486 for ; Mon, 10 Apr 2000 19:16:26 -0400 (EDT) Received: from acharny_pc2 ([161.44.189.106]) by pilgrim.cisco.com (8.8.8-Cisco List Logging/8.8.8) with ESMTP id TAA15094; Mon, 10 Apr 2000 19:15:21 -0400 (EDT) Message-Id: <4.2.0.58.20000410190430.00cd4660@pilgrim.cisco.com> X-Sender: acharny@pilgrim.cisco.com X-Mailer: QUALCOMM Windows Eudora Pro Version 4.2.0.58 Date: Mon, 10 Apr 2000 19:18:34 -0700 To: "Zhao, Yongdong" , "'Anna Charny'" From: Anna Charny Subject: RE: FW: [Diffserv] EF question !!! Cc: "'Diffserv@ietf.org'" In-Reply-To: <4D45BA2A58A7D3119E050008C7E69E29055DA7@trimail2.tri.sbc.co m> 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 Hi, At 05:32 PM 4/10/00 -0500, Zhao, Yongdong wrote: >Hi, > >It seems to me that there are still problems on the service rate definition >even if you only consider busy period. Here is an example. First some >assumptions: >(1) queue is built up from time T_0=0, i.e. queue is empty before time T_0, >(2) EF packet size is L, >(3) it takes S(second) for a packet being switched into the queue, (e.g. >s=L/C, C is the fabric bandwidth) >(4) it takes R(second) to pull a packet out of the queue, (e.g. r=L/D, D is >the port bandwidth) >(5) a packet can be served only after the entire packet has been saved in >the queue. > >Now from T_0=0 to T_1=S, The first packet is put into the queue. The EF >queue cannot be served even though the queue is continuously built up. From >T_1=S to T_2=S+R, the EF queue receives service. Now assume that right >before the queue is about to be empty, i.e. at time T_2 -e where e<<1, >another packet starts to arrive the queue. The second will be fully in the >queue at time >T_3=S+R-e+S. Now from T_0=0 to T_3=2S+R-e, the EF queue is served for >T_2-T_1=R (second). Certainly T_3-T_1 is larger than the >MTU/Port_bandwidth=R, and the queue is not empty during this period of time. >But if the service rate is measured over this time interval, the percentage >of bandwidth received by EF queue is >R/(2S+R-e)=1/(1+2S/R-e/R). >Assume that e/R<<1, the percentage of bandwidth received by the EF queue >becomes approximately 1/(1+2S/R). Now with situation of S/R=1, such as in >routers where one line card can host only one port, only 1/3 of the port >bandwidth is received by the EF queue. I was using the standard convention that a packet arrives to the queue when its last bit arrives to the queue. In that case in you example above the queue is technically empty after the last bit of the previous packet left, and before the first bit of the next packet arrived. >It seems that the EF service rate should be measured over "practically >interesting" time scale. Is the time scale of serving a single packet of the >MTU size the "practically interesting" time scale for EF service, probably >not. I think it really depends on what you mean by "practically interesting". If you want to have minimal jitter, then the smaller the timescale you can guarantee, the better. If all you want is average bandwidth, then you can live with longer timescales. Regards, Anna >Best regards, > >Yongdong Zhao > >SBC Technology Resources, Inc. > >-----Original Message----- >From: Anna Charny [mailto:acharny@cisco.com] >Sent: Friday, April 07, 2000 2:34 PM >To: Shahram Davari; 'Diffserv@ietf.org' >Subject: Re: FW: [Diffserv] EF question !!! > > >Shahram, > >At 11:07 AM 4/6/00 -0700, Shahram Davari wrote: > >"The figure was messed up in previous email. Please use this one:" > > > >Hi, > > > >RFC-2598 says: > >"EF 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" > > > >Lets assume 2 PHB queues: an EF and a BE each of rate R (both nicely > >shaped). Let's assume the output link rate is 2R so that 50% of the link BW > >(=R) is assigned to EF and 50% (=R) to BE. Let's also assume that packet > >sizes are all MTU size. Now on the output link we will have EF and BE > >packets one after another as following: > > > > > >---------------------------------------------------------- > >| BE | EF | BE | EF | BE | EF | ..... | > >---------------------------------------------------------- > > > > <-------------------> > > 3T > > > > > >The duration of each packet at the output link is T= MTU/2R. Now assume the > >time from the beginning of a BE packet to the end of another BE packet; >this > >time = 3T (notice that there is only one EF packet in this interval). Also > >the time to send an MTU size packet at EF configured rate is MTU/R = 2T. > > > >Since 3T > 2T then according to RFC-2598 we should average the configured > >rate in the 3T interval. But as you can see the average EF rate in the 3T > >interval is MTU/3T = 2R/3 which is 2/3 of the EF configured rate R. > > > >Either I am missing something or there is a problem with the RFC-2598. > >It seems to me that in this particular example there is really no actual >problem, because in the interval of length 3T you consider there is only a >single EF packet in the queue, assuming the packets arrive ideally space at >the rate, as I think you have done. I think the statement that a queue >must receive some service X only applies to the case when there are >actually packets in that queue to send. Otherwise it is impossible in >principle to guarantee this even if there is just a single EF stream on a >link with absolutely no contention from BE (That is, just remove BE packets >in your example - if EF packets arrive ideally spaced, they will also leave >ideally spaced, since there is no contention, but it would still be the >case that there will be intervals of length 3T where only one EF packet >will be served). > >I think that as far as the *total* aggregate of all EF "streams" on a given >link goes, it does receive the service R (in the case of priority FIFO >implementation) over any interval of length MTU/R or longer *as long as >the EF queue is continuously backlogged during that interval*, and as long >as rate of EF does not exceed C/2, where C is the capacity of the link. To >see this, consider some a busy period (t1, t2) of the EF queue, where t1 is >the time when the queue changed its state from being empty to being busy, >and t2 is the first time after t1 when the queue became empty again (we do >not care here whether t2 is finite or not). In the case of strict priority >queueing, the EF queue will be continuously served from time >t1 <= t3 <=t1 + MTU/C until the queue becomes empty. That is because a >BE packet may be served in the interval (t1, t3). > >So for any interval of the form (t4, t5) of length > MTU/R , where >t3<=t4<=t5<=t2, the EF queue receives the service equal to (t5-t4)C bits >which is strictly greater than its ideal service (t5-t4)R that it should >have received in this interval. So for any such interval the statement of >RFC 2598 is correct. > >Now consider any interval (t6, t7) such that t1<=t6<=t3 <=t7<=t2. (Note >that in order for (t6, t7) be longer than MTU/R, t7 must be greater than >t3). In any such interval the EF queue is continuously backlogged, but in >the interval (t1, t3) no EF bits are served. So the amount of service that >will be received by the EF queue in the interval (t6, t7) is at least >(t7-t3)C >= (t7-t6)C - MTU bits. So the average rate that the EF aggregate >will get over (t6, t7) is equal to C - MTU/(t7-t6) >= C - MTU/(MTU/R) = >C-R >= 2R - R >= R. > >Since (t1, t2) is an arbitrary busy period, this covers all possible cases >of continuously busy intervals of length MTU/R or greater. > >This shows that in any interval of time longer than or equal to MTU/R *in >which the priority queue is continuously backlogged* AND the EF rate does >not exceed 50% of the speed of the link, the EF queue does receive its >average rate R. > >Now, as I argued above, it does not seem reasonable to request that this >holds for *ANY* interval MTU/R or longer in which the queue is *not* >necessarily continuously backlogged - as your example shows - so it seems >that a reasonable thing to do might be to put a clarification in RFC 2598 >that it only requires the rate for "busy" intervals only, and that the 50% >rate limitation is necessary. I am not sure what the procedure is of >updating RFC's , though. > >Note that if the EF queue is not served at highest priority (such as in >the case of a class-based WFQ scheduler) , the start time of service for a >busy queue may be longer than MTU/C, which would lead to a tighter than 50% >limitation on Ef aggregate rate. > >Finally, it seems important to emphasize that while the above is true for >a total EF aggregate on the link (subject to 50% limitation and the >requirement that the service is computed over busy periods only) , it is no >longer true for individual "EF streams" of which the total EF aggregate on >a link is composed. Jim Robert's example and Jean-Yves Le Boudec's >concerns in an earlier message relate to those "streams", or "edge-to-edge >aggregates", as discussed in the VW draft. But RFC 2598 seems to apply >to EF BA understood as *total link* EF aggregates, as defined in RFC 2475: > > DS behavior aggregate a collection of packets with the same DS > codepoint crossing a link in a particular > direction. > >I hope this helps. > >Regards, >Anna > > > > > > >Any comments? > > > > > >Shahram Davari > >Systems Engineer, Product Research > >PMC-Sierra Inc. > >555 Legget drive, > >Suit 834, Tower B, > >Ottawa, ON K2K 2X3, Canada > >Phone: +1 (613) 271-4018 > >Fax : +1 (613) 271-7007 > > > > > > > >_______________________________________________ > >diffserv mailing list > >diffserv@ietf.org > >http://www1.ietf.org/mailman/listinfo/diffserv > >Archive: http://www-nrg.ee.lbl.gov/diff-serv-arch/ > > > >_______________________________________________ > >diffserv mailing list > >diffserv@ietf.org > >http://www1.ietf.org/mailman/listinfo/diffserv > >Archive: http://www-nrg.ee.lbl.gov/diff-serv-arch/ > > > > >_______________________________________________ >diffserv mailing list >diffserv@ietf.org >http://www1.ietf.org/mailman/listinfo/diffserv >Archive: http://www-nrg.ee.lbl.gov/diff-serv-arch/ > >_______________________________________________ >diffserv mailing list >diffserv@ietf.org >http://www1.ietf.org/mailman/listinfo/diffserv >Archive: http://www-nrg.ee.lbl.gov/diff-serv-arch/ > _______________________________________________ diffserv mailing list diffserv@ietf.org http://www1.ietf.org/mailman/listinfo/diffserv Archive: http://www-nrg.ee.lbl.gov/diff-serv-arch/ From diffserv-admin@ietf.org Mon Apr 10 21:41:16 2000 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA08512 for ; Mon, 10 Apr 2000 21:41:15 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id VAA20188; Mon, 10 Apr 2000 21:13:47 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id VAA20157 for ; Mon, 10 Apr 2000 21:13:42 -0400 (EDT) Received: from sol.extremenetworks.com (sol.extremenetworks.com [216.52.8.2]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA08077 for ; Mon, 10 Apr 2000 21:16:10 -0400 (EDT) Received: by SOL with Internet Mail Service (5.5.2650.21) id ; Mon, 10 Apr 2000 18:13:39 -0700 Message-ID: <808F64DDB492D3119D3C00508B5D8D733EC72F@SOL> From: Andrew Smith To: "'Brian E Carpenter'" , Kathleen Nichols Cc: diffserv@ietf.org Subject: RE: [Diffserv] On RED in a Diffserv MIB Date: Mon, 10 Apr 2000 18:13:36 -0700 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: text/plain; charset="iso-8859-1" Sender: diffserv-admin@ietf.org Errors-To: diffserv-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Diffserv Discussion List X-BeenThere: diffserv@ietf.org > -----Original Message----- > From: Brian E Carpenter [mailto:brian@hursley.ibm.com] > Sent: Thursday, April 06, 2000 2:10 PM > To: Kathleen Nichols > Cc: diffserv@ietf.org > Subject: Re: [Diffserv] On RED in a Diffserv MIB ... > I guess the RED details are better discussed on e2e-interest or > somwhere like that. I'd like to hear more on this topic and take it a bit further because I think we're quite close to some useful semi-consensus - maybe Kathie could crosspost her message to end2end-interest@isi.edu or red-impl@listserv.lbl.gov (is the latter list still alive?). I'm particularly interested in the assertion that such a control law might be usefully controlled by a single parameter (1 knob = good, 3 knobs = nobody bothers to turn it on). However, I will take note of the currently-hatted chair and place this out of scope, but easily addable at future date, for the next rev of MIB draft (winging its way to you as soon as I can resurrect my fried laptop that had an unfortunate encounter with anti-clockwise electricity). Andrew (MIB ed.) _______________________________________________ diffserv mailing list diffserv@ietf.org http://www1.ietf.org/mailman/listinfo/diffserv Archive: http://www-nrg.ee.lbl.gov/diff-serv-arch/ From diffserv-admin@ietf.org Mon Apr 10 22:35:02 2000 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA11008 for ; Mon, 10 Apr 2000 22:35:02 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id VAA20703; Mon, 10 Apr 2000 21:59:37 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id VAA20600 for ; Mon, 10 Apr 2000 21:59:30 -0400 (EDT) Received: from pilgrim.cisco.com (pilgrim.cisco.com [171.69.204.12]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA09708 for ; Mon, 10 Apr 2000 22:01:59 -0400 (EDT) Received: from acharny_pc2 ([161.44.189.106]) by pilgrim.cisco.com (8.8.8-Cisco List Logging/8.8.8) with ESMTP id WAA25785; Mon, 10 Apr 2000 22:00:55 -0400 (EDT) Message-Id: <4.2.0.58.20000410215746.00cd9500@pilgrim.cisco.com> X-Sender: acharny@pilgrim.cisco.com X-Mailer: QUALCOMM Windows Eudora Pro Version 4.2.0.58 Date: Mon, 10 Apr 2000 22:04:05 -0700 To: "Zhao, Yongdong" From: Anna Charny Subject: typo in prev message - Fwd: RE: FW: [Diffserv] EF question !!! Cc: "'Diffserv@ietf.org'" Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: diffserv-admin@ietf.org Errors-To: diffserv-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Diffserv Discussion List X-BeenThere: diffserv@ietf.org Hi, There was a typo in prev message: the sentence " In that case in you example above the queue is technically empty after the last bit of the previous packet left, and before the first bit of the next packet arrived" should obviously be " In that case in you example above the queue is technically empty after the last bit of the previous packet left, and before the *last* bit of the next packet arrived". I hope it was clear from the context... Anna ========================================================================== X-Sender: acharny@pilgrim.cisco.com X-Mailer: QUALCOMM Windows Eudora Pro Version 4.2.0.58 Date: Mon, 10 Apr 2000 19:18:34 -0700 To: "Zhao, Yongdong" , "'Anna Charny'" From: Anna Charny Subject: RE: FW: [Diffserv] EF question !!! Cc: "'Diffserv@ietf.org'" In-Reply-To: <4D45BA2A58A7D3119E050008C7E69E29055DA7@trimail2.tri.sbc.co m> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-UIDL: 09f4093dcd7d17da1681619f61a49c0e Hi, At 05:32 PM 4/10/00 -0500, Zhao, Yongdong wrote: >Hi, > >It seems to me that there are still problems on the service rate definition >even if you only consider busy period. Here is an example. First some >assumptions: >(1) queue is built up from time T_0=0, i.e. queue is empty before time T_0, >(2) EF packet size is L, >(3) it takes S(second) for a packet being switched into the queue, (e.g. >s=L/C, C is the fabric bandwidth) >(4) it takes R(second) to pull a packet out of the queue, (e.g. r=L/D, D is >the port bandwidth) >(5) a packet can be served only after the entire packet has been saved in >the queue. > >Now from T_0=0 to T_1=S, The first packet is put into the queue. The EF >queue cannot be served even though the queue is continuously built up. From >T_1=S to T_2=S+R, the EF queue receives service. Now assume that right >before the queue is about to be empty, i.e. at time T_2 -e where e<<1, >another packet starts to arrive the queue. The second will be fully in the >queue at time >T_3=S+R-e+S. Now from T_0=0 to T_3=2S+R-e, the EF queue is served for >T_2-T_1=R (second). Certainly T_3-T_1 is larger than the >MTU/Port_bandwidth=R, and the queue is not empty during this period of time. >But if the service rate is measured over this time interval, the percentage >of bandwidth received by EF queue is >R/(2S+R-e)=1/(1+2S/R-e/R). >Assume that e/R<<1, the percentage of bandwidth received by the EF queue >becomes approximately 1/(1+2S/R). Now with situation of S/R=1, such as in >routers where one line card can host only one port, only 1/3 of the port >bandwidth is received by the EF queue. I was using the standard convention that a packet arrives to the queue when its last bit arrives to the queue. In that case in you example above the queue is technically empty after the last bit of the previous packet left, and before the first bit of the next packet arrived. >It seems that the EF service rate should be measured over "practically >interesting" time scale. Is the time scale of serving a single packet of the >MTU size the "practically interesting" time scale for EF service, probably >not. I think it really depends on what you mean by "practically interesting". If you want to have minimal jitter, then the smaller the timescale you can guarantee, the better. If all you want is average bandwidth, then you can live with longer timescales. Regards, Anna >Best regards, > >Yongdong Zhao > >SBC Technology Resources, Inc. > >-----Original Message----- >From: Anna Charny [mailto:acharny@cisco.com] >Sent: Friday, April 07, 2000 2:34 PM >To: Shahram Davari; 'Diffserv@ietf.org' >Subject: Re: FW: [Diffserv] EF question !!! > > >Shahram, > >At 11:07 AM 4/6/00 -0700, Shahram Davari wrote: > >"The figure was messed up in previous email. Please use this one:" > > > >Hi, > > > >RFC-2598 says: > >"EF 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" > > > >Lets assume 2 PHB queues: an EF and a BE each of rate R (both nicely > >shaped). Let's assume the output link rate is 2R so that 50% of the link BW > >(=R) is assigned to EF and 50% (=R) to BE. Let's also assume that packet > >sizes are all MTU size. Now on the output link we will have EF and BE > >packets one after another as following: > > > > > >---------------------------------------------------------- > >| BE | EF | BE | EF | BE | EF | ..... | > >---------------------------------------------------------- > > > > <-------------------> > > 3T > > > > > >The duration of each packet at the output link is T= MTU/2R. Now assume the > >time from the beginning of a BE packet to the end of another BE packet; >this > >time = 3T (notice that there is only one EF packet in this interval). Also > >the time to send an MTU size packet at EF configured rate is MTU/R = 2T. > > > >Since 3T > 2T then according to RFC-2598 we should average the configured > >rate in the 3T interval. But as you can see the average EF rate in the 3T > >interval is MTU/3T = 2R/3 which is 2/3 of the EF configured rate R. > > > >Either I am missing something or there is a problem with the RFC-2598. > >It seems to me that in this particular example there is really no actual >problem, because in the interval of length 3T you consider there is only a >single EF packet in the queue, assuming the packets arrive ideally space at >the rate, as I think you have done. I think the statement that a queue >must receive some service X only applies to the case when there are >actually packets in that queue to send. Otherwise it is impossible in >principle to guarantee this even if there is just a single EF stream on a >link with absolutely no contention from BE (That is, just remove BE packets >in your example - if EF packets arrive ideally spaced, they will also leave >ideally spaced, since there is no contention, but it would still be the >case that there will be intervals of length 3T where only one EF packet >will be served). > >I think that as far as the *total* aggregate of all EF "streams" on a given >link goes, it does receive the service R (in the case of priority FIFO >implementation) over any interval of length MTU/R or longer *as long as >the EF queue is continuously backlogged during that interval*, and as long >as rate of EF does not exceed C/2, where C is the capacity of the link. To >see this, consider some a busy period (t1, t2) of the EF queue, where t1 is >the time when the queue changed its state from being empty to being busy, >and t2 is the first time after t1 when the queue became empty again (we do >not care here whether t2 is finite or not). In the case of strict priority >queueing, the EF queue will be continuously served from time >t1 <= t3 <=t1 + MTU/C until the queue becomes empty. That is because a >BE packet may be served in the interval (t1, t3). > >So for any interval of the form (t4, t5) of length > MTU/R , where >t3<=t4<=t5<=t2, the EF queue receives the service equal to (t5-t4)C bits >which is strictly greater than its ideal service (t5-t4)R that it should >have received in this interval. So for any such interval the statement of >RFC 2598 is correct. > >Now consider any interval (t6, t7) such that t1<=t6<=t3 <=t7<=t2. (Note >that in order for (t6, t7) be longer than MTU/R, t7 must be greater than >t3). In any such interval the EF queue is continuously backlogged, but in >the interval (t1, t3) no EF bits are served. So the amount of service that >will be received by the EF queue in the interval (t6, t7) is at least >(t7-t3)C >= (t7-t6)C - MTU bits. So the average rate that the EF aggregate >will get over (t6, t7) is equal to C - MTU/(t7-t6) >= C - MTU/(MTU/R) = >C-R >= 2R - R >= R. > >Since (t1, t2) is an arbitrary busy period, this covers all possible cases >of continuously busy intervals of length MTU/R or greater. > >This shows that in any interval of time longer than or equal to MTU/R *in >which the priority queue is continuously backlogged* AND the EF rate does >not exceed 50% of the speed of the link, the EF queue does receive its >average rate R. > >Now, as I argued above, it does not seem reasonable to request that this >holds for *ANY* interval MTU/R or longer in which the queue is *not* >necessarily continuously backlogged - as your example shows - so it seems >that a reasonable thing to do might be to put a clarification in RFC 2598 >that it only requires the rate for "busy" intervals only, and that the 50% >rate limitation is necessary. I am not sure what the procedure is of >updating RFC's , though. > >Note that if the EF queue is not served at highest priority (such as in >the case of a class-based WFQ scheduler) , the start time of service for a >busy queue may be longer than MTU/C, which would lead to a tighter than 50% >limitation on Ef aggregate rate. > >Finally, it seems important to emphasize that while the above is true for >a total EF aggregate on the link (subject to 50% limitation and the >requirement that the service is computed over busy periods only) , it is no >longer true for individual "EF streams" of which the total EF aggregate on >a link is composed. Jim Robert's example and Jean-Yves Le Boudec's >concerns in an earlier message relate to those "streams", or "edge-to-edge >aggregates", as discussed in the VW draft. But RFC 2598 seems to apply >to EF BA understood as *total link* EF aggregates, as defined in RFC 2475: > > DS behavior aggregate a collection of packets with the same DS > codepoint crossing a link in a particular > direction. > >I hope this helps. > >Regards, >Anna > > > > > > >Any comments? > > > > > >Shahram Davari > >Systems Engineer, Product Research > >PMC-Sierra Inc. > >555 Legget drive, > >Suit 834, Tower B, > >Ottawa, ON K2K 2X3, Canada > >Phone: +1 (613) 271-4018 > >Fax : +1 (613) 271-7007 > > > > > > > >_______________________________________________ > >diffserv mailing list > >diffserv@ietf.org > >http://www1.ietf.org/mailman/listinfo/diffserv > >Archive: http://www-nrg.ee.lbl.gov/diff-serv-arch/ > > > >_______________________________________________ > >diffserv mailing list > >diffserv@ietf.org > >http://www1.ietf.org/mailman/listinfo/diffserv > >Archive: http://www-nrg.ee.lbl.gov/diff-serv-arch/ > > > > >_______________________________________________ >diffserv mailing list >diffserv@ietf.org >http://www1.ietf.org/mailman/listinfo/diffserv >Archive: http://www-nrg.ee.lbl.gov/diff-serv-arch/ > >_______________________________________________ >diffserv mailing list >diffserv@ietf.org >http://www1.ietf.org/mailman/listinfo/diffserv >Archive: http://www-nrg.ee.lbl.gov/diff-serv-arch/ _______________________________________________ diffserv mailing list diffserv@ietf.org http://www1.ietf.org/mailman/listinfo/diffserv Archive: http://www-nrg.ee.lbl.gov/diff-serv-arch/ From diffserv-admin@ietf.org Tue Apr 11 10:51:18 2000 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA07227 for ; Tue, 11 Apr 2000 10:51:17 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id KAA01944; Tue, 11 Apr 2000 10:13:57 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id KAA01910 for ; Tue, 11 Apr 2000 10:13:51 -0400 (EDT) Received: from smtp.mail.yahoo.com (smtp.mail.yahoo.com [128.11.68.32]) by ietf.org (8.9.1a/8.9.1a) with SMTP id KAA05471 for ; Tue, 11 Apr 2000 10:16:19 -0400 (EDT) Received: from cci-209150224083.clarityconnect.net (HELO KHERMANN-NT2.yahoo.com) (209.150.224.83) by smtp.mail.yahoo.com with SMTP; 11 Apr 2000 07:16:16 -0700 X-Apparently-From: Message-Id: <4.3.1.2.20000411101550.00b0aef0@pop.mail.yahoo.com> X-Sender: ncc1701v@pop.mail.yahoo.com X-Mailer: QUALCOMM Windows Eudora Version 4.3.1 Date: Tue, 11 Apr 2000 10:15:58 -0400 To: Kathleen Nichols , Brian E Carpenter From: Scott Brim Cc: diffserv@ietf.org Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Subject: [Diffserv] Fixing up "BA" Sender: diffserv-admin@ietf.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 & Brian, I said I thought ba_def.pdf was mixing concepts. I=20 understand what you're trying to do -- define an edge-to-edge component=20 for building end-to-end services. I think the problem I perceive with=20 the draft is that while you're redefining BA, you're still keeping a hold=20 on the old definition. >The next step for the WG is to lay out how the forwarding path=20 >components (PHBs, classifiers, and traffic >conditioners) can be used within the architectural framework to compose=20 >specific Behavior Aggregates. This uses the new definition. >Since the per-hop behavior must be the same for every node in the domain=20 >while the set >of packets marked for that PHB may be different at every node, a PHB=20 >should be defined such that its treat-ment >of packets of a behavior aggregate This feels like it uses the old definition, "a collection of packets" etc.. >doesn=92t change when other packets join or leave the BA. If the >properties of a BA using a particular PHB Since packets don't "use" a PHB this feels like the new one (as does the=20 rest of the paragraph). >hold regardless of how the aggregate mutates as it traverses the >domain, then that BA scales. If there are limits to where the properties=20 >hold, that translates to a limit on the >size or topology of a DS domain that can use that BA. Although useful=20 >single-link BAs might exist, BAs >=95 Behavior Aggregate: a collection of packets with the same codepoint=20 >crossing a link in a particular direction. The >terms "aggregate" and "behavior aggregate" are used interchangeably in=20 >this document. But then you quote the old definition "for easy reference". And so on. I think I can have time to help with the words if you want=20 any more "help" than you've already been offered :-). ...Scott __________________________________________________ Do You Yahoo!?? Talk to your friends online with Yahoo! Messenger.. http://im.yahoo.com __________________________________________________ Do You Yahoo!? Talk to your friends online with Yahoo! Messenger. http://im.yahoo.com _______________________________________________ diffserv mailing list diffserv@ietf.org http://www1.ietf.org/mailman/listinfo/diffserv Archive: http://www-nrg.ee.lbl.gov/diff-serv-arch/ From diffserv-admin@ietf.org Tue Apr 11 11:09:16 2000 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA08120 for ; Tue, 11 Apr 2000 11:09:16 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id KAA02345; Tue, 11 Apr 2000 10:35:16 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id KAA02323 for ; Tue, 11 Apr 2000 10:35:13 -0400 (EDT) Received: from mail-gw.hursley.ibm.com (mail-gw.hursley.ibm.com [194.196.110.15]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA06543 for ; Tue, 11 Apr 2000 10:37:40 -0400 (EDT) Received: from sp3at21.hursley.ibm.com (sp3at21.hursley.ibm.com [9.20.45.21]) by mail-gw.hursley.ibm.com (AIX4.3/UCB 8.8.8/8.8.8) with ESMTP id PAA19932; Tue, 11 Apr 2000 15:36:54 +0100 Received: from hursley.ibm.com (gsine04.us.sine.ibm.com [9.14.6.44]) by sp3at21.hursley.ibm.com (AIX4.2/UCB 8.7/8.7.3) with ESMTP id PAA28722; Tue, 11 Apr 2000 15:37:02 +0100 (BST) Message-ID: <38F33890.264110D9@hursley.ibm.com> Date: Tue, 11 Apr 2000 09:37:04 -0500 From: Brian E Carpenter Organization: IBM X-Mailer: Mozilla 4.61 [en] (Win98; I) X-Accept-Language: en,fr MIME-Version: 1.0 To: Scott Brim CC: Kathleen Nichols , diffserv@ietf.org References: <4.3.1.2.20000411101550.00b0aef0@pop.mail.yahoo.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Subject: [Diffserv] Re: Fixing up "BA" Sender: diffserv-admin@ietf.org Errors-To: diffserv-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Diffserv Discussion List X-BeenThere: diffserv@ietf.org Content-Transfer-Encoding: 7bit Scott, Thanks for the comments. We will try to be clearer in the next version. Brian Scott Brim wrote: > > Kathie & Brian, I said I thought ba_def.pdf was mixing concepts. I=20 > understand what you're trying to do -- define an edge-to-edge component=20 > for building end-to-end services. I think the problem I perceive with=20 > the draft is that while you're redefining BA, you're still keeping a hold=20 > on the old definition. > > >The next step for the WG is to lay out how the forwarding path=20 > >components (PHBs, classifiers, and traffic > >conditioners) can be used within the architectural framework to compose=20 > >specific Behavior Aggregates. > > This uses the new definition. > > >Since the per-hop behavior must be the same for every node in the domain=20 > >while the set > >of packets marked for that PHB may be different at every node, a PHB=20 > >should be defined such that its treat-ment > >of packets of a behavior aggregate > > This feels like it uses the old definition, "a collection of packets" etc.. > > >doesn=92t change when other packets join or leave the BA. If the > >properties of a BA using a particular PHB > > Since packets don't "use" a PHB this feels like the new one (as does the=20 > rest of the paragraph). > > >hold regardless of how the aggregate mutates as it traverses the > >domain, then that BA scales. If there are limits to where the properties=20 > >hold, that translates to a limit on the > >size or topology of a DS domain that can use that BA. Although useful=20 > >single-link BAs might exist, BAs > > >=95 Behavior Aggregate: a collection of packets with the same codepoint=20 > >crossing a link in a particular direction. The > >terms "aggregate" and "behavior aggregate" are used interchangeably in=20 > >this document. > > But then you quote the old definition "for easy reference". > > And so on. I think I can have time to help with the words if you want=20 > any more "help" than you've already been offered :-). > > ...Scott > > __________________________________________________ > Do You Yahoo!?? > Talk to your friends online with Yahoo! Messenger.. > http://im.yahoo.com > _______________________________________________ diffserv mailing list diffserv@ietf.org http://www1.ietf.org/mailman/listinfo/diffserv Archive: http://www-nrg.ee.lbl.gov/diff-serv-arch/ From diffserv-admin@ietf.org Tue Apr 11 11:27:58 2000 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA08945 for ; Tue, 11 Apr 2000 11:27:58 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id KAA02606; Tue, 11 Apr 2000 10:51:32 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id KAA02575 for ; Tue, 11 Apr 2000 10:51:28 -0400 (EDT) Received: from motgate2.mot.com (motgate2.mot.com [136.182.1.10]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA07368 for ; Tue, 11 Apr 2000 10:53:55 -0400 (EDT) Received: [from pobox2.mot.com (pobox2.mot.com [136.182.15.8]) by motgate2.mot.com (motgate2 2.1) with ESMTP id HAA27809; Tue, 11 Apr 2000 07:47: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 HAA24036; Tue, 11 Apr 2000 07:47:52 -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 KAA26058; Tue, 11 Apr 2000 10:47:49 -0400 (EDT) Message-Id: <200004111447.KAA26058@noah.dma.isg.mot.com> X-Mailer: exmh version 1.6.7 5/3/96 To: Scott Brim cc: Kathleen Nichols , Brian E Carpenter , diffserv@ietf.org Subject: Re: [Diffserv] Fixing up "BA" In-reply-to: Your message of "Tue, 11 Apr 2000 10:15:58 EDT." <4.3.1.2.20000411101550.00b0aef0@pop.mail.yahoo.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Tue, 11 Apr 2000 10:47:46 -0400 From: Dan Grossman Sender: diffserv-admin@ietf.org Errors-To: diffserv-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Diffserv Discussion List X-BeenThere: diffserv@ietf.org Scott, Brian and I discussed a framework for straightening this out. I've run some words by the chairs/authors at their request, and and have gotten an ack, with explict congestion notification :-). I'll give them another day or two, and then send to the list. Dan _______________________________________________ diffserv mailing list diffserv@ietf.org http://www1.ietf.org/mailman/listinfo/diffserv Archive: http://www-nrg.ee.lbl.gov/diff-serv-arch/ From diffserv-admin@ietf.org Tue Apr 11 12:03:50 2000 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA10641 for ; Tue, 11 Apr 2000 12:03:50 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id LAA03155; Tue, 11 Apr 2000 11:29:34 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id LAA03124 for ; Tue, 11 Apr 2000 11:29:30 -0400 (EDT) Received: from motgate2.mot.com (motgate2.mot.com [136.182.1.10]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA09102 for ; Tue, 11 Apr 2000 11:31:57 -0400 (EDT) Received: [from pobox.mot.com (pobox.mot.com [129.188.137.100]) by motgate2.mot.com (motgate2 2.1) with ESMTP id IAA10849 for ; Tue, 11 Apr 2000 08:31:59 -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 IAA11384 for ; Tue, 11 Apr 2000 08:31:58 -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 LAA27603 for ; Tue, 11 Apr 2000 11:31:56 -0400 (EDT) Message-Id: <200004111531.LAA27603@noah.dma.isg.mot.com> X-Mailer: exmh version 1.6.7 5/3/96 To: diffserv@ietf.org Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Tue, 11 Apr 2000 11:31:56 -0400 From: Dan Grossman Subject: [Diffserv] Definition of a BA Sender: diffserv-admin@ietf.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 recent discussion of BAs raised a possible problem with the definition in RFC 2475. DS behavior aggregate: a collection of packets with the same DS codepoint crossing a link in a particular direction. The problem is that AF (and experimental or future PHB groups) in fact use more than one DSCP. Presumably, all packets which are in the PHB group are part of the BA. The obvious fix would be to change the definition to "a collection of packets which are members of the same PHB group crossing a link in a particular direction." The problem with this is that there might be multiple BAs which are of the same PHB group crossing a link, each with its own set of DSCPs. The best fix I can think of is to invent a new term: DSCP Group: A set of DSCPs which select the members of a PHB group. Thus, DS behavior aggregate: a collection of packets having DSCPs which are members of the same DSCP group, crossing a link in a particular direction. A less clear way of doing this without a new definition: DS behavior aggregate: a collection of packets with the same DS codepoint (or related DSCPs that select the same PHB group) crossing a link in a particular direction. Comments? I will update the terminology draft when there is WG consensus. _______________________________________________ diffserv mailing list diffserv@ietf.org http://www1.ietf.org/mailman/listinfo/diffserv Archive: http://www-nrg.ee.lbl.gov/diff-serv-arch/ From diffserv-admin@ietf.org Tue Apr 11 13:23:15 2000 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA13846 for ; Tue, 11 Apr 2000 13:23:15 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id MAA04251; Tue, 11 Apr 2000 12:29:21 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id MAA04226 for ; Tue, 11 Apr 2000 12:29:17 -0400 (EDT) Received: from smtprich.nortel.com (smtprich.nortel.com [192.135.215.8]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA11767 for ; Tue, 11 Apr 2000 12:31:43 -0400 (EDT) Received: from zrchb213.us.nortel.com (actually zrchb213) by smtprich.nortel.com; Tue, 11 Apr 2000 11:14:42 -0500 Received: by zrchb213.us.nortel.com with Internet Mail Service (5.5.2650.21) id <2V3DGG61>; Tue, 11 Apr 2000 11:07:12 -0500 Message-ID: From: "Biswajit Nandy" To: "'Andrew Smith'" , "Diffserv (E-mail)" Subject: RE: [Diffserv] My slides from IETF-47 DiffServ Date: Tue, 11 Apr 2000 11:07:14 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01BFA3CF.FE97A1F2" 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_01BFA3CF.FE97A1F2 Content-Type: text/plain Andrew, Page 5 of MIB slides with title: Open MIB Issues(3) First bullet of point 8 states: "this allows for RIO - multiple averaging functions for the same queue: is this needed?" I guess your answer is "no". Has it been discussed in the meeting? I don't see any mention in the minutes. If yes, what was the conclusion? Biswajit > -----Original Message----- > From: Andrew Smith [SMTP:andrew@extremenetworks.com] > Sent: Monday, April 10, 2000 2:20 PM > To: Diffserv (E-mail) > Subject: [Diffserv] My slides from IETF-47 DiffServ > > > ftp://ftp.extremenetworks.com/pub/outgoing/docs/andrew/smith-diffserv-mode > l- > 0300.ppt > ftp://ftp.extremenetworks.com/pub/outgoing/docs/andrew/smith-diffserv-mib- > 03 > 00.ppt > > These will get converted into PDF in due course, for inclusion in the > proceedings [Note: you will probably need to re-assemble split lines in > the > URLs above]. > > Andrew > > > **************************************************************** > Andrew Smith tel: +1 (408) 579-2821 > Extreme Networks fax: +1 (408) 579-3000 > 3585 Monroe St. http://www.extremenetworks.com > Santa Clara CA 95051-1450 em: andrew@extremenetworks.com > **************************************************************** > > _______________________________________________ > diffserv mailing list > diffserv@ietf.org > http://www1.ietf.org/mailman/listinfo/diffserv > Archive: http://www-nrg.ee.lbl.gov/diff-serv-arch/ > ------_=_NextPart_001_01BFA3CF.FE97A1F2 Content-Type: text/html Content-Transfer-Encoding: quoted-printable RE: [Diffserv] My slides from IETF-47 DiffServ

Andrew,

Page 5 of MIB slides = with title: Open MIB Issues(3)
First bullet of = point 8 states:

"this allows = for RIO - multiple averaging functions for the same queue: is = this
needed?"  = I guess your answer is "no".

Has it been = discussed in the meeting? I don't see any mention in the = minutes.
If yes, what was = the conclusion?

Biswajit

------_=_NextPart_001_01BFA3CF.FE97A1F2-- _______________________________________________ diffserv mailing list diffserv@ietf.org http://www1.ietf.org/mailman/listinfo/diffserv Archive: http://www-nrg.ee.lbl.gov/diff-serv-arch/ From diffserv-admin@ietf.org Tue Apr 11 14: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 ESMTP id OAA15589 for ; Tue, 11 Apr 2000 14:14:16 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id NAA05329; Tue, 11 Apr 2000 13:49:08 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id NAA05298 for ; Tue, 11 Apr 2000 13:49:04 -0400 (EDT) Received: from sol.extremenetworks.com (sol.extremenetworks.com [216.52.8.2]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA14890 for ; Tue, 11 Apr 2000 13:51:32 -0400 (EDT) Received: by SOL with Internet Mail Service (5.5.2650.21) id <2XQRFT8R>; Tue, 11 Apr 2000 10:48:56 -0700 Message-ID: <808F64DDB492D3119D3C00508B5D8D733EC733@SOL> From: Andrew Smith To: "'Biswajit Nandy'" , "Diffserv (E-mail)" Subject: RE: [Diffserv] My slides from IETF-47 DiffServ Date: Tue, 11 Apr 2000 10:48:45 -0700 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: text/plain; charset="iso-8859-1" Sender: diffserv-admin@ietf.org Errors-To: diffserv-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Diffserv Discussion List X-BeenThere: diffserv@ietf.org We did not get as far as discussing this at the meeting - but opinions on this, as well as the other points I raised, are welcome on this mailing list. The answers in parentheses are those that I will assume in the next draft unless we have approximate WG consensus to do otherwise. Some of the points may be moot if we leave out objects for detailed specification of things like RED which is the current intent, I think. Andrew Smith (MIB ed.) -----Original Message----- From: Biswajit Nandy [mailto:bnandy@nortelnetworks.com] Sent: Tuesday, April 11, 2000 9:07 AM To: 'Andrew Smith'; Diffserv (E-mail) Subject: RE: [Diffserv] My slides from IETF-47 DiffServ Andrew, Page 5 of MIB slides with title: Open MIB Issues(3) First bullet of point 8 states: "this allows for RIO - multiple averaging functions for the same queue: is this needed?" I guess your answer is "no". Has it been discussed in the meeting? I don't see any mention in the minutes. If yes, what was the conclusion? Biswajit -----Original Message----- From: Andrew Smith [SMTP:andrew@extremenetworks.com] Sent: Monday, April 10, 2000 2:20 PM To: Diffserv (E-mail) Subject: [Diffserv] My slides from IETF-47 DiffServ ftp://ftp.extremenetworks.com/pub/outgoing/docs/andrew/smith-diffserv-model- 0300.ppt ftp://ftp.extremenetworks.com/pub/outgoing/docs/andrew/smith-diffserv-mib-03 00.ppt These will get converted into PDF in due course, for inclusion in the proceedings [Note: you will probably need to re-assemble split lines in the URLs above]. Andrew **************************************************************** Andrew Smith tel: +1 (408) 579-2821 Extreme Networks fax: +1 (408) 579-3000 3585 Monroe St. http://www.extremenetworks.com Santa Clara CA 95051-1450 em: andrew@extremenetworks.com **************************************************************** _______________________________________________ diffserv mailing list diffserv@ietf.org http://www1.ietf.org/mailman/listinfo/diffserv Archive: http://www-nrg.ee.lbl.gov/diff-serv-arch/ _______________________________________________ diffserv mailing list diffserv@ietf.org http://www1.ietf.org/mailman/listinfo/diffserv Archive: http://www-nrg.ee.lbl.gov/diff-serv-arch/ From diffserv-admin@ietf.org Tue Apr 11 15:39:24 2000 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA18478 for ; Tue, 11 Apr 2000 15:39:24 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id PAA06405; Tue, 11 Apr 2000 15:09:27 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id PAA06375 for ; Tue, 11 Apr 2000 15:09:23 -0400 (EDT) Received: from lohi.eng.telia.fi (root@lohi.eng.telia.fi [195.10.149.18]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA17708 for ; Tue, 11 Apr 2000 15:11:51 -0400 (EDT) Received: (from jh@localhost) by lohi.eng.telia.fi (8.9.3/8.9.3/Debian 8.9.3-21) id WAA17948; Tue, 11 Apr 2000 22:11:48 +0300 From: Juha Heinanen MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <14579.30964.650831.89286@lohi.eng.telia.fi> Date: Tue, 11 Apr 2000 22:11:48 +0300 (EEST) To: Dan Grossman Cc: diffserv@ietf.org Subject: [Diffserv] Definition of a BA In-Reply-To: <200004111531.LAA27603@noah.dma.isg.mot.com> References: <200004111531.LAA27603@noah.dma.isg.mot.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 i thought that we already agreed that af consists of four phb groups and that the text will be fixed when a new version of the rfc is spinned out. diffserv terminology is already now way beyond comprehension and adding a new term (dscp group) is more more nail to the coffin. -- juha _______________________________________________ diffserv mailing list diffserv@ietf.org http://www1.ietf.org/mailman/listinfo/diffserv Archive: http://www-nrg.ee.lbl.gov/diff-serv-arch/ From diffserv-admin@ietf.org Tue Apr 11 16:02:32 2000 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA19088 for ; Tue, 11 Apr 2000 16:02:32 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id PAA06737; Tue, 11 Apr 2000 15:30:50 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id PAA06714 for ; Tue, 11 Apr 2000 15:30:46 -0400 (EDT) Received: from prue.eim.surrey.ac.uk (IDENT:exim@prue.eim.surrey.ac.uk [131.227.76.5]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA18373 for ; Tue, 11 Apr 2000 15:33:05 -0400 (EDT) Received: from petra.ee.surrey.ac.uk ([131.227.88.13] ident=eep1lw) by prue.eim.surrey.ac.uk with esmtp (Exim 3.03 #1) id 12f6PC-0005fV-00; Tue, 11 Apr 2000 20:32:58 +0100 Date: Tue, 11 Apr 2000 20:32:55 +0100 (BST) From: Lloyd Wood X-Sender: eep1lw@petra.ee.surrey.ac.uk Reply-To: L.Wood@eim.surrey.ac.uk To: Juha Heinanen cc: diffserv@ietf.org Subject: Re: [Diffserv] Definition of a BA In-Reply-To: <14579.30964.650831.89286@lohi.eng.telia.fi> Message-ID: Organization: speaking for none X-url: http://www.ee.surrey.ac.uk/Personal/L.Wood/ X-no-archive: yes MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: diffserv-admin@ietf.org Errors-To: diffserv-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Diffserv Discussion List X-BeenThere: diffserv@ietf.org On Tue, 11 Apr 2000, Juha Heinanen wrote: > diffserv terminology is already now way beyond comprehension hear, hear. L. look, it's not the vocabulary that's supposed to scale. PGP _______________________________________________ diffserv mailing list diffserv@ietf.org http://www1.ietf.org/mailman/listinfo/diffserv Archive: http://www-nrg.ee.lbl.gov/diff-serv-arch/ From diffserv-admin@ietf.org Tue Apr 11 16:37:26 2000 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA19802 for ; Tue, 11 Apr 2000 16:37:26 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id QAA07392; Tue, 11 Apr 2000 16:04:29 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id QAA07361 for ; Tue, 11 Apr 2000 16:04:25 -0400 (EDT) Received: from ftpbox.mot.com (ftpbox.mot.com [129.188.136.101]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA19174 for ; Tue, 11 Apr 2000 16:06:53 -0400 (EDT) Received: [from pobox.mot.com (pobox.mot.com [129.188.137.100]) by ftpbox.mot.com (ftpbox 2.1) with ESMTP id MAA01077; Tue, 11 Apr 2000 12:50:18 -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 MAA19146; Tue, 11 Apr 2000 12:50:16 -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 PAA07194; Tue, 11 Apr 2000 15:50:15 -0400 (EDT) Message-Id: <200004111950.PAA07194@noah.dma.isg.mot.com> X-Mailer: exmh version 1.6.7 5/3/96 To: Juha Heinanen cc: diffserv@ietf.org Subject: Re: [Diffserv] Definition of a BA In-reply-to: Your message of "Tue, 11 Apr 2000 22:11:48 EDT." <14579.30964.650831.89286@lohi.eng.telia.fi> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Tue, 11 Apr 2000 15:50:14 -0400 From: Dan Grossman Sender: diffserv-admin@ietf.org Errors-To: diffserv-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Diffserv Discussion List X-BeenThere: diffserv@ietf.org > i thought that we already agreed that af consists of four phb groups and > that the text will be fixed when a new version of the rfc is spinned > out. Yes. But the problem is with the definition of BA, not the definition of PHB group. > diffserv terminology is already now way beyond comprehension and True. Can you suggest terms to take away? > adding a new term (dscp group) is more more nail to the coffin. I take it you prefer the second solution? > > -- juha Dan _______________________________________________ diffserv mailing list diffserv@ietf.org http://www1.ietf.org/mailman/listinfo/diffserv Archive: http://www-nrg.ee.lbl.gov/diff-serv-arch/ From diffserv-admin@ietf.org Tue Apr 11 18:18:46 2000 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA23102 for ; Tue, 11 Apr 2000 18:18:46 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id RAA08806; Tue, 11 Apr 2000 17:56:38 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id RAA08775 for ; Tue, 11 Apr 2000 17:56:34 -0400 (EDT) Received: from sol.extremenetworks.com (sol.extremenetworks.com [216.52.8.2]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA22814 for ; Tue, 11 Apr 2000 17:59:01 -0400 (EDT) Received: by SOL with Internet Mail Service (5.5.2650.21) id <2XQRFV7D>; Tue, 11 Apr 2000 14:56:29 -0700 Message-ID: <808F64DDB492D3119D3C00508B5D8D733EC742@SOL> From: Andrew Smith To: "'Kathleen Nichols'" Cc: "'diffserv@ietf.org'" Subject: RE: [Diffserv] DiffServ Model - slides from yesterday Date: Tue, 11 Apr 2000 14:56:22 -0700 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: text/plain; charset="iso-8859-1" Sender: diffserv-admin@ietf.org Errors-To: diffserv-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Diffserv Discussion List X-BeenThere: diffserv@ietf.org Kathie, Could you be more precise about what to fix up in this definition (other than moving the hyphen): "Non-work A property of a scheduling algorithm such that it does conserving not necessarily service a packet if available at every transmission opportunity." Thanks, Andrew > -----Original Message----- > From: Kathleen Nichols [mailto:kmn@cisco.com] > Sent: Monday, March 27, 2000 4:58 PM > To: Andrew Smith > Cc: 'diffserv@ietf.org' > Subject: Re: [Diffserv] DiffServ Model - slides from yesterday ... > In Definitions, fix the words for Non work conserving. _______________________________________________ diffserv mailing list diffserv@ietf.org http://www1.ietf.org/mailman/listinfo/diffserv Archive: http://www-nrg.ee.lbl.gov/diff-serv-arch/ From diffserv-admin@ietf.org Tue Apr 11 18:20:37 2000 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA23149 for ; Tue, 11 Apr 2000 18:20:37 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id SAA08989; Tue, 11 Apr 2000 18:01:24 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id SAA08968 for ; Tue, 11 Apr 2000 18:01:21 -0400 (EDT) Received: from foxhound.cisco.com (foxhound.cisco.com [171.69.192.161]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA22963 for ; Tue, 11 Apr 2000 18:03:48 -0400 (EDT) Received: (from kzm@localhost) by foxhound.cisco.com (8.8.8/2.5.1/Cisco List Logging/8.8.8) id PAA06081; Tue, 11 Apr 2000 15:03:44 -0700 (PDT) From: Keith McCloghrie Message-Id: <200004112203.PAA06081@foxhound.cisco.com> Subject: Re: [Diffserv] Definition of a BA To: dan@dma.isg.mot.com (Dan Grossman) Date: Tue, 11 Apr 2000 15:03:43 -0700 (PDT) Cc: diffserv@ietf.org In-Reply-To: <200004111531.LAA27603@noah.dma.isg.mot.com> from "Dan Grossman" at Apr 11, 2000 11:31:56 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 > DS behavior aggregate: a collection of packets with the same DS codepoint (or > related DSCPs that select the same PHB group) crossing a link in a particular > direction. How about: DS behavior aggregate: a collection of packets with the same DS codepoint(s) crossing a link in a particular direction. Keith. _______________________________________________ diffserv mailing list diffserv@ietf.org http://www1.ietf.org/mailman/listinfo/diffserv Archive: http://www-nrg.ee.lbl.gov/diff-serv-arch/ From diffserv-admin@ietf.org Tue Apr 11 20:11:53 2000 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA24531 for ; Tue, 11 Apr 2000 20:11:53 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id TAA10195; Tue, 11 Apr 2000 19:52:37 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id TAA10162 for ; Tue, 11 Apr 2000 19:52:32 -0400 (EDT) Received: from alemail1.firewall.lucent.com (alemail1.lucent.com [192.11.221.161]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA24186 for ; Tue, 11 Apr 2000 19:55:01 -0400 (EDT) Received: from alemail1.firewall.lucent.com (localhost [127.0.0.1]) by alemail1.firewall.lucent.com (Pro-8.9.3/8.9.3) with ESMTP id TAA08383 for ; Tue, 11 Apr 2000 19:55:01 -0400 (EDT) Received: from nl0006exch001h.wins.lucent.com (h135-85-76-62.lucent.com [135.85.76.62]) by alemail1.firewall.lucent.com (Pro-8.9.3/8.9.3) with ESMTP id TAA08374 for ; Tue, 11 Apr 2000 19:55:00 -0400 (EDT) Received: by nl0006exch001h.nl.lucent.com with Internet Mail Service (5.5.2448.0) id <2P0YKRHS>; Wed, 12 Apr 2000 01:54:59 +0200 Message-ID: <2413FED0DFE6D111B3F90008C7FA61FB06BF7ED0@nl0006exch002u.nl.lucent.com> From: "Wijnen, Bert (Bert)" To: diffserv@ietf.org Date: Wed, 12 Apr 2000 01:54:55 +0200 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2448.0) Content-Type: text/plain Subject: [Diffserv] Policy Terminology Sender: diffserv-admin@ietf.org Errors-To: diffserv-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Diffserv Discussion List X-BeenThere: diffserv@ietf.org The Policy Terminology work has now become a part of the Policy Framework WG. I recommend that members of this WG keep an eye on what happens there, because in the end, we (IESG) do require a consisten use of terms when talking about Policy Based Management. Bert (co-AD for Operations and Management Area) _______________________________________________ diffserv mailing list diffserv@ietf.org http://www1.ietf.org/mailman/listinfo/diffserv Archive: http://www-nrg.ee.lbl.gov/diff-serv-arch/ From diffserv-admin@ietf.org Tue Apr 11 23:59:18 2000 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA29895 for ; Tue, 11 Apr 2000 23:59:17 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id XAA12489; Tue, 11 Apr 2000 23:39:41 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id XAA12460 for ; Tue, 11 Apr 2000 23:39:33 -0400 (EDT) Received: from dirty.research.bell-labs.com (ns1.research.bell-labs.com [204.178.16.6]) by ietf.org (8.9.1a/8.9.1a) with SMTP id XAA29630 for ; Tue, 11 Apr 2000 23:41:59 -0400 (EDT) Received: from zubin.dnrc.bell-labs.com ([135.180.130.56]) by dirty; Tue Apr 11 23:41:39 EDT 2000 Received: from dnrc.bell-labs.com ([135.254.81.16]) by zubin.dnrc.bell-labs.com (8.9.3/8.9.3) with ESMTP id XAA03350; Tue, 11 Apr 2000 23:41:29 -0400 (EDT) Message-ID: <38F3ED36.6F1B9E58@dnrc.bell-labs.com> Date: Tue, 11 Apr 2000 20:27:50 -0700 From: Grenville Armitage Organization: Bell Laboratories, Lucent Technologies X-Mailer: Mozilla 4.61 [en] (WinNT; U) X-Accept-Language: en MIME-Version: 1.0 To: Dan Grossman CC: diffserv@ietf.org Subject: Re: [Diffserv] Definition of a BA References: <200004111531.LAA27603@noah.dma.isg.mot.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: diffserv-admin@ietf.org Errors-To: diffserv-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Diffserv Discussion List X-BeenThere: diffserv@ietf.org Content-Transfer-Encoding: 7bit Dan Grossman wrote: > > The recent discussion of BAs raised a possible problem with the definition in > RFC 2475. > > DS behavior aggregate: a collection of packets with the same DS codepoint > crossing a link in a particular direction. > > The problem is that AF (and experimental or future PHB groups) in fact use > more than one DSCP. Presumably, all packets which are in the PHB group are > part of the BA. Hmmm... perhaps my head is still flushing the opposite way after the IETF, but can you remind me why must we presume that packets in a PHB Group are part of the same BA? (Or is this tied up with the impending re-definition of BA?) cheers, gja ________________________________________________________________________ Grenville Armitage http://members.home.net/garmitage/ Bell Labs Research Silicon Valley _______________________________________________ diffserv mailing list diffserv@ietf.org http://www1.ietf.org/mailman/listinfo/diffserv Archive: http://www-nrg.ee.lbl.gov/diff-serv-arch/ From diffserv-admin@ietf.org Wed Apr 12 01:25:38 2000 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA03375 for ; Wed, 12 Apr 2000 01:25:37 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id BAA13435; Wed, 12 Apr 2000 01:02:00 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id BAA13406 for ; Wed, 12 Apr 2000 01:01:56 -0400 (EDT) Received: from lohi.eng.telia.fi (root@lohi.eng.telia.fi [195.10.149.18]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA00770 for ; Wed, 12 Apr 2000 01:04:23 -0400 (EDT) Received: (from jh@localhost) by lohi.eng.telia.fi (8.9.3/8.9.3/Debian 8.9.3-21) id IAA19100; Wed, 12 Apr 2000 08:04:18 +0300 From: Juha Heinanen MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <14580.978.560337.843142@lohi.eng.telia.fi> Date: Wed, 12 Apr 2000 08:04:18 +0300 (EEST) To: Grenville Armitage Cc: Dan Grossman , diffserv@ietf.org Subject: Re: [Diffserv] Definition of a BA In-Reply-To: <38F3ED36.6F1B9E58@dnrc.bell-labs.com> References: <200004111531.LAA27603@noah.dma.isg.mot.com> <38F3ED36.6F1B9E58@dnrc.bell-labs.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 Grenville Armitage writes: > Hmmm... perhaps my head is still flushing the opposite way after the > IETF, but can you remind me why must we presume that packets in a > PHB Group are part of the same BA? (Or is this tied up with the > impending re-definition of BA?) why do we need to differentiate BAs and PHB groups? why can't we make them to be the same and get rid of the other term? -- juha _______________________________________________ diffserv mailing list diffserv@ietf.org http://www1.ietf.org/mailman/listinfo/diffserv Archive: http://www-nrg.ee.lbl.gov/diff-serv-arch/ From diffserv-admin@ietf.org Wed Apr 12 06:05:04 2000 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA14560 for ; Wed, 12 Apr 2000 06:05:04 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id FAA20743; Wed, 12 Apr 2000 05:30:40 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id FAA20712 for ; Wed, 12 Apr 2000 05:30:36 -0400 (EDT) Received: from aifhs8.alcatel.fr (una103.alcatel.fr [212.208.74.103]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA14237 for ; Wed, 12 Apr 2000 05:33:05 -0400 (EDT) From: Gerard.Gastaud@alcatel.fr Received: from frmta003.netfr.alcatel.fr (frmta003.netfr.alcatel.fr [155.132.251.32]) by aifhs8.alcatel.fr (ALCANET/SMTP2) with SMTP id LAA22905 for ; Wed, 12 Apr 2000 11:33:27 +0200 (MET DST) Received: by frmta003.netfr.alcatel.fr(Lotus SMTP MTA v4.6.6 (890.1 7-16-1999)) id C12568BF.00345DF4 ; Wed, 12 Apr 2000 11:31:59 +0200 X-Lotus-FromDomain: ALCATEL To: diffserv@ietf.org Message-ID: Date: Wed, 12 Apr 2000 11:29:55 +0200 Mime-Version: 1.0 Content-type: text/plain; charset=us-ascii Content-Disposition: inline Subject: [Diffserv] some IDs status enquiry Sender: diffserv-admin@ietf.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 current status of these drafts please: draft-ietf-diffserv-traffcon, draft-ietf-diffserv-gtc, draft-ietf-diffserv-rashaper, draft-fang-diffserv-tswtcm thanks gg _______________________________________________ diffserv mailing list diffserv@ietf.org http://www1.ietf.org/mailman/listinfo/diffserv Archive: http://www-nrg.ee.lbl.gov/diff-serv-arch/ From diffserv-admin@ietf.org Wed Apr 12 10:19:32 2000 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA21608 for ; Wed, 12 Apr 2000 10:19:32 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id JAA23007; Wed, 12 Apr 2000 09:37:46 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id JAA22977 for ; Wed, 12 Apr 2000 09:37:43 -0400 (EDT) Received: from mail-gw.hursley.ibm.com (mail-gw.hursley.ibm.com [194.196.110.15]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA19932 for ; Wed, 12 Apr 2000 09:40:12 -0400 (EDT) Received: from sp3at21.hursley.ibm.com (sp3at21.hursley.ibm.com [9.20.45.21]) by mail-gw.hursley.ibm.com (AIX4.3/UCB 8.8.8/8.8.8) with ESMTP id OAA44630; Wed, 12 Apr 2000 14:39:28 +0100 Received: from hursley.ibm.com (lig32-227-11-59.us.lig-dial.ibm.com [32.227.11.59]) by sp3at21.hursley.ibm.com (AIX4.2/UCB 8.7/8.7.3) with ESMTP id OAA20456; Wed, 12 Apr 2000 14:39:40 +0100 (BST) Message-ID: <38F47CA0.18AB5048@hursley.ibm.com> Date: Wed, 12 Apr 2000 08:39:44 -0500 From: Brian E Carpenter Organization: IBM X-Mailer: Mozilla 4.61 [en] (Win98; I) X-Accept-Language: en,fr MIME-Version: 1.0 To: Gerard.Gastaud@alcatel.fr CC: diffserv@ietf.org Subject: Re: [Diffserv] some IDs status enquiry 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 Gerard, draft-ietf-diffserv-trafcon-format-00.txt This is obsolete; it was never intended as more than a temporary document. None of the others are current work items; the exercise of getting traffic conditioners documented didn't really enthuse the WG. Brian Carpenter diffserv co-chair Gerard.Gastaud@alcatel.fr wrote: > > What is the current status of these drafts please: > draft-ietf-diffserv-traffcon, draft-ietf-diffserv-gtc, draft-ietf-diffserv-rashaper, draft-fang-diffserv-tswtcm > thanks > gg > > _______________________________________________ > diffserv mailing list > diffserv@ietf.org > http://www1.ietf.org/mailman/listinfo/diffserv > Archive: http://www-nrg.ee.lbl.gov/diff-serv-arch/ -- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - Brian E Carpenter Program Director, Internet Standards & Technology, IBM On assignment for IBM at http://www.iCAIR.org Attend INET 2000: http://www.isoc.org/inet2000 Non-IBM email: brian@icair.org _______________________________________________ diffserv mailing list diffserv@ietf.org http://www1.ietf.org/mailman/listinfo/diffserv Archive: http://www-nrg.ee.lbl.gov/diff-serv-arch/ From diffserv-admin@ietf.org Wed Apr 12 10:32:24 2000 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA22275 for ; Wed, 12 Apr 2000 10:32:24 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id JAA23119; Wed, 12 Apr 2000 09:46:26 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id JAA23090 for ; Wed, 12 Apr 2000 09:46:21 -0400 (EDT) Received: from mail-gw.hursley.ibm.com (mail-gw.hursley.ibm.com [194.196.110.15]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA20207 for ; Wed, 12 Apr 2000 09:48:49 -0400 (EDT) Received: from sp3at21.hursley.ibm.com (sp3at21.hursley.ibm.com [9.20.45.21]) by mail-gw.hursley.ibm.com (AIX4.3/UCB 8.8.8/8.8.8) with ESMTP id OAA34410; Wed, 12 Apr 2000 14:48:06 +0100 Received: from hursley.ibm.com (lig32-227-11-59.us.lig-dial.ibm.com [32.227.11.59]) by sp3at21.hursley.ibm.com (AIX4.2/UCB 8.7/8.7.3) with ESMTP id OAA31280; Wed, 12 Apr 2000 14:48:14 +0100 (BST) Message-ID: <38F47EA4.2FB68237@hursley.ibm.com> Date: Wed, 12 Apr 2000 08:48:20 -0500 From: Brian E Carpenter Organization: IBM X-Mailer: Mozilla 4.61 [en] (Win98; I) X-Accept-Language: en,fr MIME-Version: 1.0 To: Juha Heinanen CC: Grenville Armitage , Dan Grossman , diffserv@ietf.org Subject: Re: [Diffserv] Definition of a BA References: <200004111531.LAA27603@noah.dma.isg.mot.com> <38F3ED36.6F1B9E58@dnrc.bell-labs.com> <14580.978.560337.843142@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, Juha Heinanen wrote: > > Grenville Armitage writes: > > > Hmmm... perhaps my head is still flushing the opposite way after the > > IETF, but can you remind me why must we presume that packets in a > > PHB Group are part of the same BA? (Or is this tied up with the > > impending re-definition of BA?) > > why do we need to differentiate BAs and PHB groups? why can't we make > them to be the same and get rid of the other term? Because a BA is at some level a mathematical model that describes the statistical behaviour of a set of traffic flows. That seems to me to be a very different animal from a PHB Group, which simply describes a mechanism. But I take your general point about acronym minimisation. We mustn't add teriminology for its own sake. Brian _______________________________________________ diffserv mailing list diffserv@ietf.org http://www1.ietf.org/mailman/listinfo/diffserv Archive: http://www-nrg.ee.lbl.gov/diff-serv-arch/ From diffserv-admin@ietf.org Wed Apr 12 10:33:23 2000 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA22329 for ; Wed, 12 Apr 2000 10:33:23 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id JAA23519; Wed, 12 Apr 2000 09:55:11 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id JAA23488 for ; Wed, 12 Apr 2000 09:55:06 -0400 (EDT) Received: from ftpbox.mot.com (ftpbox.mot.com [129.188.136.101]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA20607 for ; Wed, 12 Apr 2000 09:57:35 -0400 (EDT) Received: [from pobox.mot.com (pobox.mot.com [129.188.137.100]) by ftpbox.mot.com (ftpbox 2.1) with ESMTP id GAA04244; Wed, 12 Apr 2000 06:57:31 -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 GAA06674; Wed, 12 Apr 2000 06:57:30 -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 JAA15716; Wed, 12 Apr 2000 09:57:25 -0400 (EDT) Message-Id: <200004121357.JAA15716@noah.dma.isg.mot.com> X-Mailer: exmh version 1.6.7 5/3/96 To: Grenville Armitage cc: diffserv@ietf.org Subject: Re: [Diffserv] Definition of a BA In-reply-to: Your message of "Tue, 11 Apr 2000 20:27:50 EDT." <38F3ED36.6F1B9E58@dnrc.bell-labs.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Wed, 12 Apr 2000 09:57:25 -0400 From: Dan Grossman Sender: diffserv-admin@ietf.org Errors-To: diffserv-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Diffserv Discussion List X-BeenThere: diffserv@ietf.org > > > Dan Grossman wrote: > > > > The recent discussion of BAs raised a possible problem with the definition in > > RFC 2475. > > > > DS behavior aggregate: a collection of packets with the same DS codepoint > > crossing a link in a particular direction. > > > > The problem is that AF (and experimental or future PHB groups) in fact use > > more than one DSCP. Presumably, all packets which are in the PHB group are > > part of the BA. > > Hmmm... perhaps my head is still flushing the opposite way after the > IETF, but can you remind me why must we presume that packets in a > PHB Group are part of the same BA? (Or is this tied up with the > impending re-definition of BA?) > Good question. Yes, it's partly tied up with the impending redefinition of BA, since now BAs are becoming important to the diffserv architecture in a way they weren't before. The question really is, are all the packets belonging to an AF group _instance_ and crossing a link in a particular direction part of the same BA? Does remarking cause packets to shift from one BA to another? _______________________________________________ diffserv mailing list diffserv@ietf.org http://www1.ietf.org/mailman/listinfo/diffserv Archive: http://www-nrg.ee.lbl.gov/diff-serv-arch/ From diffserv-admin@ietf.org Wed Apr 12 10:33:28 2000 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA22367 for ; Wed, 12 Apr 2000 10:33:27 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id JAA23306; Wed, 12 Apr 2000 09:51:11 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id JAA23279 for ; Wed, 12 Apr 2000 09:51:07 -0400 (EDT) Received: from lohi.eng.telia.fi (root@lohi.eng.telia.fi [195.10.149.18]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA20462 for ; Wed, 12 Apr 2000 09:53:35 -0400 (EDT) Received: (from jh@localhost) by lohi.eng.telia.fi (8.9.3/8.9.3/Debian 8.9.3-21) id QAA20342; Wed, 12 Apr 2000 16:53:26 +0300 From: Juha Heinanen MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <14580.32726.755957.919644@lohi.eng.telia.fi> Date: Wed, 12 Apr 2000 16:53:26 +0300 (EEST) To: Brian E Carpenter Cc: Grenville Armitage , Dan Grossman , diffserv@ietf.org Subject: Re: [Diffserv] Definition of a BA In-Reply-To: <38F47EA4.2FB68237@hursley.ibm.com> References: <200004111531.LAA27603@noah.dma.isg.mot.com> <38F3ED36.6F1B9E58@dnrc.bell-labs.com> <14580.978.560337.843142@lohi.eng.telia.fi> <38F47EA4.2FB68237@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: > Because a BA is at some level a mathematical model that describes the > statistical behaviour of a set of traffic flows. That seems to me to > be a very different animal from a PHB Group, which simply describes > a mechanism. why don't you then talk about edge-to-edge behavior of bhp groups rather than invent a new term? -- juha _______________________________________________ diffserv mailing list diffserv@ietf.org http://www1.ietf.org/mailman/listinfo/diffserv Archive: http://www-nrg.ee.lbl.gov/diff-serv-arch/ From diffserv-admin@ietf.org Wed Apr 12 10:37:32 2000 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA22533 for ; Wed, 12 Apr 2000 10:37:32 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id JAA23227; Wed, 12 Apr 2000 09:48:53 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id JAA23190 for ; Wed, 12 Apr 2000 09:48:48 -0400 (EDT) Received: from motgate2.mot.com (motgate2.mot.com [136.182.1.10]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA20406 for ; Wed, 12 Apr 2000 09:51:17 -0400 (EDT) Received: [from mothost.mot.com (mothost.mot.com [129.188.137.101]) by motgate2.mot.com (motgate2 2.1) with ESMTP id GAA11620; Wed, 12 Apr 2000 06:51:16 -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 GAA12609; Wed, 12 Apr 2000 06:51:15 -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 JAA15423; Wed, 12 Apr 2000 09:51:12 -0400 (EDT) Message-Id: <200004121351.JAA15423@noah.dma.isg.mot.com> X-Mailer: exmh version 1.6.7 5/3/96 To: Keith McCloghrie cc: diffserv@ietf.org Subject: Re: [Diffserv] Definition of a BA In-reply-to: Your message of "Tue, 11 Apr 2000 15:03:43 EDT." <200004112203.PAA06081@foxhound.cisco.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Wed, 12 Apr 2000 09:51:12 -0400 From: Dan Grossman Sender: diffserv-admin@ietf.org Errors-To: diffserv-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Diffserv Discussion List X-BeenThere: diffserv@ietf.org > > DS behavior aggregate: a collection of packets with the same DS codepoint (or > > related DSCPs that select the same PHB group) crossing a link in a particular > > direction. > > How about: > > DS behavior aggregate: a collection of packets with the same DS > codepoint(s) crossing a link in a particular direction. > Nice thought, but too inclusive. It probably was not intended that completely unrelated DSCPs be part of the same BA. > Keith. > Dan _______________________________________________ diffserv mailing list diffserv@ietf.org http://www1.ietf.org/mailman/listinfo/diffserv Archive: http://www-nrg.ee.lbl.gov/diff-serv-arch/ From diffserv-admin@ietf.org Wed Apr 12 10:38:12 2000 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA22563 for ; Wed, 12 Apr 2000 10:38:12 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id JAA23414; Wed, 12 Apr 2000 09:53:07 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id JAA23385 for ; Wed, 12 Apr 2000 09:53:03 -0400 (EDT) Received: from mail-gw.hursley.ibm.com (mail-gw.hursley.ibm.com [194.196.110.15]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA20554 for ; Wed, 12 Apr 2000 09:55:32 -0400 (EDT) Received: from sp3at21.hursley.ibm.com (sp3at21.hursley.ibm.com [9.20.45.21]) by mail-gw.hursley.ibm.com (AIX4.3/UCB 8.8.8/8.8.8) with ESMTP id OAA53672; Wed, 12 Apr 2000 14:54:50 +0100 Received: from hursley.ibm.com (lig32-227-11-59.us.lig-dial.ibm.com [32.227.11.59]) by sp3at21.hursley.ibm.com (AIX4.2/UCB 8.7/8.7.3) with ESMTP id OAA24270; Wed, 12 Apr 2000 14:55:00 +0100 (BST) Message-ID: <38F48039.F48D4F38@hursley.ibm.com> Date: Wed, 12 Apr 2000 08:55:05 -0500 From: Brian E Carpenter Organization: IBM X-Mailer: Mozilla 4.61 [en] (Win98; I) X-Accept-Language: en,fr MIME-Version: 1.0 To: Grenville Armitage CC: Dan Grossman , diffserv@ietf.org Subject: Re: [Diffserv] Definition of a BA References: <200004111531.LAA27603@noah.dma.isg.mot.com> <38F3ED36.6F1B9E58@dnrc.bell-labs.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: diffserv-admin@ietf.org Errors-To: diffserv-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Diffserv Discussion List X-BeenThere: diffserv@ietf.org Content-Transfer-Encoding: 7bit Grenville, Grenville Armitage wrote: ... > Hmmm... perhaps my head is still flushing the opposite way after the > IETF, but can you remind me why must we presume that packets in a > PHB Group are part of the same BA? (Or is this tied up with the > impending re-definition of BA?) A BA classifier only looks at the DSCP, so a BA classifier cannot discriminate between hypothetically different "BAs" whose packets carry the same DSCP. Since we want interior routers to be able to use BA classifiers, it follows that at a given interior router interface, all packets belonging to a given PHB Group are in the same BA. Brian _______________________________________________ diffserv mailing list diffserv@ietf.org http://www1.ietf.org/mailman/listinfo/diffserv Archive: http://www-nrg.ee.lbl.gov/diff-serv-arch/ From diffserv-admin@ietf.org Wed Apr 12 10:44:19 2000 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA22794 for ; Wed, 12 Apr 2000 10:44:18 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id KAA23986; Wed, 12 Apr 2000 10:02:47 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id KAA23950 for ; Wed, 12 Apr 2000 10:02:42 -0400 (EDT) Received: from procyon.pmc-sierra.bc.ca (procyon.pmc-sierra.bc.ca [134.87.115.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA21051 for ; Wed, 12 Apr 2000 10:05:12 -0400 (EDT) Received: from nt-exchange1.pmc-sierra.bc.ca (nt-exchange1.pmc-sierra.bc.ca [134.87.116.183]) by procyon.pmc-sierra.bc.ca (6.6.6/6.6.6) with ESMTP id HAA06264; Wed, 12 Apr 2000 07:04:59 -0700 (PDT) Received: by nt-exchange1.pmc-sierra.bc.ca with Internet Mail Service (5.5.2650.21) id <2J274ZP9>; Wed, 12 Apr 2000 07:05:00 -0700 Message-ID: <336ECDAFDF7DD311B9E30090277AEE4101B404C6@nt-exchange-bby.pmc-sierra.bc.ca> From: Shahram Davari To: "'Brian E Carpenter'" , Grenville Armitage Cc: Dan Grossman , diffserv@ietf.org Subject: RE: [Diffserv] Definition of a BA Date: Wed, 12 Apr 2000 07:02:16 -0700 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: text/plain; charset="iso-8859-1" Sender: diffserv-admin@ietf.org Errors-To: diffserv-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Diffserv Discussion List X-BeenThere: diffserv@ietf.org Brian, I think Grenville's question was why packet's with different DSCPs that indicate a PHB group are part of a single BA? For example assume AF11=>DSCP1, AF12=>DSCP2 and AF13=>DSCP3, now if we have packets with DSCP1, DSCP2, DSCP3, are they part of a single BA? or they belong to 3 BAs? Regards, -Shahram >-----Original Message----- >From: Brian E Carpenter [mailto:brian@hursley.ibm.com] >Sent: Wednesday, April 12, 2000 9:55 AM >To: Grenville Armitage >Cc: Dan Grossman; diffserv@ietf.org >Subject: Re: [Diffserv] Definition of a BA > > >Grenville, > >Grenville Armitage wrote: >... >> Hmmm... perhaps my head is still flushing the opposite way after the >> IETF, but can you remind me why must we presume that packets in a >> PHB Group are part of the same BA? (Or is this tied up with the >> impending re-definition of BA?) > >A BA classifier only looks at the DSCP, so a BA classifier cannot >discriminate between hypothetically different "BAs" whose >packets carry >the same DSCP. Since we want interior routers to be able to use BA >classifiers, it follows that at a given interior router interface, >all packets belonging to a given PHB Group are in the same BA. > > Brian > >_______________________________________________ >diffserv mailing list >diffserv@ietf.org >http://www1.ietf.org/mailman/listinfo/diffserv >Archive: http://www-nrg.ee.lbl.gov/diff-serv-arch/ > _______________________________________________ diffserv mailing list diffserv@ietf.org http://www1.ietf.org/mailman/listinfo/diffserv Archive: http://www-nrg.ee.lbl.gov/diff-serv-arch/ From diffserv-admin@ietf.org Wed Apr 12 11:42:25 2000 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA24817 for ; Wed, 12 Apr 2000 11:42:24 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id LAA25538; Wed, 12 Apr 2000 11:02:12 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id LAA25507 for ; Wed, 12 Apr 2000 11:02:07 -0400 (EDT) Received: from mail-gw.hursley.ibm.com (mail-gw.hursley.ibm.com [194.196.110.15]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA23590 for ; Wed, 12 Apr 2000 11:04:35 -0400 (EDT) Received: from sp3at21.hursley.ibm.com (sp3at21.hursley.ibm.com [9.20.45.21]) by mail-gw.hursley.ibm.com (AIX4.3/UCB 8.8.8/8.8.8) with ESMTP id QAA29924; Wed, 12 Apr 2000 16:03:53 +0100 Received: from hursley.ibm.com (lig32-227-11-59.us.lig-dial.ibm.com [32.227.11.59]) by sp3at21.hursley.ibm.com (AIX4.2/UCB 8.7/8.7.3) with ESMTP id QAA31400; Wed, 12 Apr 2000 16:04:03 +0100 (BST) Message-ID: <38F49050.57249490@hursley.ibm.com> Date: Wed, 12 Apr 2000 10:03:44 -0500 From: Brian E Carpenter Organization: IBM X-Mailer: Mozilla 4.61 [en] (Win98; I) X-Accept-Language: en,fr MIME-Version: 1.0 To: Juha Heinanen CC: Grenville Armitage , Dan Grossman , diffserv@ietf.org Subject: Re: [Diffserv] Definition of a BA References: <200004111531.LAA27603@noah.dma.isg.mot.com> <38F3ED36.6F1B9E58@dnrc.bell-labs.com> <14580.978.560337.843142@lohi.eng.telia.fi> <38F47EA4.2FB68237@hursley.ibm.com> <14580.32726.755957.919644@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: > > Brian E Carpenter writes: > > > Because a BA is at some level a mathematical model that describes the > > statistical behaviour of a set of traffic flows. That seems to me to > > be a very different animal from a PHB Group, which simply describes > > a mechanism. > > why don't you then talk about edge-to-edge behavior of bhp groups rather > than invent a new term? 1) because BA is shorter to write 2) because BA isn't a new term anyway Brian _______________________________________________ diffserv mailing list diffserv@ietf.org http://www1.ietf.org/mailman/listinfo/diffserv Archive: http://www-nrg.ee.lbl.gov/diff-serv-arch/ From diffserv-admin@ietf.org Wed Apr 12 11:48:09 2000 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA24983 for ; Wed, 12 Apr 2000 11:48:09 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id LAA25501; Wed, 12 Apr 2000 11:01:02 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id LAA25461 for ; Wed, 12 Apr 2000 11:00:58 -0400 (EDT) Received: from mail-gw.hursley.ibm.com (mail-gw.hursley.ibm.com [194.196.110.15]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA23534 for ; Wed, 12 Apr 2000 11:03:26 -0400 (EDT) Received: from sp3at21.hursley.ibm.com (sp3at21.hursley.ibm.com [9.20.45.21]) by mail-gw.hursley.ibm.com (AIX4.3/UCB 8.8.8/8.8.8) with ESMTP id QAA33490; Wed, 12 Apr 2000 16:02:43 +0100 Received: from hursley.ibm.com (lig32-227-11-59.us.lig-dial.ibm.com [32.227.11.59]) by sp3at21.hursley.ibm.com (AIX4.2/UCB 8.7/8.7.3) with ESMTP id QAA20326; Wed, 12 Apr 2000 16:02:51 +0100 (BST) Message-ID: <38F49006.730D3D6B@hursley.ibm.com> Date: Wed, 12 Apr 2000 10:02:30 -0500 From: Brian E Carpenter Organization: IBM X-Mailer: Mozilla 4.61 [en] (Win98; I) X-Accept-Language: en,fr MIME-Version: 1.0 To: Shahram Davari CC: Grenville Armitage , Dan Grossman , diffserv@ietf.org Subject: Re: [Diffserv] Definition of a BA References: <336ECDAFDF7DD311B9E30090277AEE4101B404C6@nt-exchange-bby.pmc-sierra.bc.ca> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: diffserv-admin@ietf.org Errors-To: diffserv-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Diffserv Discussion List X-BeenThere: diffserv@ietf.org Content-Transfer-Encoding: 7bit If that's the question, I think it is for whoever is brave enough to draft a BA description for AF to answer. If the answer is no, it means that the aggregate behaviour of AF can't be described. Brian Shahram Davari wrote: > > Brian, > > I think Grenville's question was why packet's with different DSCPs that > indicate a PHB group are part of a single BA? For example assume > AF11=>DSCP1, AF12=>DSCP2 and AF13=>DSCP3, now if we have packets with DSCP1, > DSCP2, DSCP3, are they part of a single BA? or they belong to 3 BAs? > > Regards, > -Shahram > > >-----Original Message----- > >From: Brian E Carpenter [mailto:brian@hursley.ibm.com] > >Sent: Wednesday, April 12, 2000 9:55 AM > >To: Grenville Armitage > >Cc: Dan Grossman; diffserv@ietf.org > >Subject: Re: [Diffserv] Definition of a BA > > > > > >Grenville, > > > >Grenville Armitage wrote: > >... > >> Hmmm... perhaps my head is still flushing the opposite way after the > >> IETF, but can you remind me why must we presume that packets in a > >> PHB Group are part of the same BA? (Or is this tied up with the > >> impending re-definition of BA?) > > > >A BA classifier only looks at the DSCP, so a BA classifier cannot > >discriminate between hypothetically different "BAs" whose > >packets carry > >the same DSCP. Since we want interior routers to be able to use BA > >classifiers, it follows that at a given interior router interface, > >all packets belonging to a given PHB Group are in the same BA. > > > > Brian > > > >_______________________________________________ > >diffserv mailing list > >diffserv@ietf.org > >http://www1.ietf.org/mailman/listinfo/diffserv > >Archive: http://www-nrg.ee.lbl.gov/diff-serv-arch/ > > > > _______________________________________________ > diffserv mailing list > diffserv@ietf.org > http://www1.ietf.org/mailman/listinfo/diffserv > Archive: http://www-nrg.ee.lbl.gov/diff-serv-arch/ _______________________________________________ diffserv mailing list diffserv@ietf.org http://www1.ietf.org/mailman/listinfo/diffserv Archive: http://www-nrg.ee.lbl.gov/diff-serv-arch/ From diffserv-admin@ietf.org Wed Apr 12 12:17:37 2000 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA26006 for ; Wed, 12 Apr 2000 12:17:37 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id LAA26466; Wed, 12 Apr 2000 11:45:34 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id LAA26360 for ; Wed, 12 Apr 2000 11:45:27 -0400 (EDT) Received: from ennovatenetworks.com (ennovatenetworks.com [208.227.99.254]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA24968 for ; Wed, 12 Apr 2000 11:47:56 -0400 (EDT) Received: from broncos (broncos.tst.ennovatenetworks.com [10.1.1.208]) by ennovatenetworks.com (8.8.7/8.8.7) with SMTP id LAA17144; Wed, 12 Apr 2000 11:47:14 -0400 (EDT) (envelope-from bkumar@ennovatenetworks.com) Reply-To: From: "Brijesh Kumar" To: "'Brian E Carpenter'" , "'Grenville Armitage'" Cc: "'Dan Grossman'" , Subject: RE: [Diffserv] Definition of a BA Date: Wed, 12 Apr 2000 11:50:47 -0400 Message-ID: <004401bfa496$dfc45960$d001010a@tst.ennovatenetworks.com> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook CWS, Build 9.0.2416 (9.0.2910.0) X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2615.200 In-reply-to: <38F48039.F48D4F38@hursley.ibm.com> Importance: Normal Content-Transfer-Encoding: 7bit Sender: diffserv-admin@ietf.org Errors-To: diffserv-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Diffserv Discussion List X-BeenThere: diffserv@ietf.org Content-Transfer-Encoding: 7bit > Brian Carpenter wrote: > Grenville Armitage wrote: > ... > > Hmmm... perhaps my head is still flushing the opposite way after the > > IETF, but can you remind me why must we presume that packets in a > > PHB Group are part of the same BA? (Or is this tied up with the > > impending re-definition of BA?) > > A BA classifier only looks at the DSCP, so a BA classifier cannot > discriminate between hypothetically different "BAs" whose > packets carry > the same DSCP. Since we want interior routers to be able to use BA > classifiers, it follows that at a given interior router interface, > all packets belonging to a given PHB Group are in the same BA. I think it should be other way around. All packets belonging to a given BA (i.e., having the same codepoint) would be in the same PHB group at a given router interface. But the reverse cannot be true since one can map more than one BAs (i.e., packets having different codepoints) to the same PHB group within a router. Is that not correct? Secondly, I have a question. It is not clear from any draft of the DiffServe documents what is the relationship between PHBs selected by the class selector codepoints with regard to EF and AF PHB? RFC 2474 only says that a PHB selected by a bigger numerical value of a class selector codepoint will have a preferential treatment over a PHB selected by a smaller numerical value of a class selector codepoint (default PHB selected by the codepoint 000000 getting the least preferential treatment). Does it mean that every implementation must choose its own preference for defined PHBs? Cheers, --brijesh _______________________________________________ diffserv mailing list diffserv@ietf.org http://www1.ietf.org/mailman/listinfo/diffserv Archive: http://www-nrg.ee.lbl.gov/diff-serv-arch/ From diffserv-admin@ietf.org Wed Apr 12 12:26:51 2000 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA26267 for ; Wed, 12 Apr 2000 12:26:51 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id LAA26659; Wed, 12 Apr 2000 11:57:30 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id LAA26635 for ; Wed, 12 Apr 2000 11:57:27 -0400 (EDT) Received: from smtp.mail.yahoo.com (smtp.mail.yahoo.com [128.11.68.32]) by ietf.org (8.9.1a/8.9.1a) with SMTP id LAA25314 for ; Wed, 12 Apr 2000 11:59:54 -0400 (EDT) Received: from cci-209150224086.clarityconnect.net (HELO KHERMANN-NT2.yahoo.com) (209.150.224.86) by smtp.mail.yahoo.com with SMTP; 12 Apr 2000 08:59:47 -0700 X-Apparently-From: Message-Id: <4.3.1.2.20000412115541.00af2d50@pop.mail.yahoo.com> X-Sender: ncc1701v@pop.mail.yahoo.com X-Mailer: QUALCOMM Windows Eudora Version 4.3.1 Date: Wed, 12 Apr 2000 11:59:31 -0400 To: Kathleen Nichols From: Scott Brim Cc: Brian E Carpenter , diffserv@ietf.org In-Reply-To: <38F3BDBE.76199CE3@cisco.com> References: <4.3.1.2.20000328134917.00ad2ce0@pop.mail.yahoo.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Subject: [Diffserv] Re: Fixing up "BA" Sender: diffserv-admin@ietf.org Errors-To: diffserv-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Diffserv Discussion List X-BeenThere: diffserv@ietf.org Since you're just trying to extend the current definition, try substituting "a collection of packets" everywhere you now have "BA", optionally adding "with the attribute of ..." as well (for your extensions). See if it makes sense. It doesn't to me. Let me (us?) know if you want discuss it in detail. ...Scott At 05:05 PM 4/11/00 -0700, Kathleen Nichols wrote: >Scott Brim wrote: > > > > Kathie & Brian, I said I thought ba_def.pdf was mixing concepts. I > > understand what you're trying to do -- define an edge-to-edge component > > for building end-to-end services. I think the problem I perceive with > > the draft is that while you're redefining BA, you're still keeping a hold > > on the old definition. > > > >We are not "redefining" BA but making an extension that should >not contradict the old definition. __________________________________________________ Do You Yahoo!? Talk to your friends online with Yahoo! Messenger. http://im.yahoo.com _______________________________________________ diffserv mailing list diffserv@ietf.org http://www1.ietf.org/mailman/listinfo/diffserv Archive: http://www-nrg.ee.lbl.gov/diff-serv-arch/ From diffserv-admin@ietf.org Wed Apr 12 12:39:18 2000 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA26905 for ; Wed, 12 Apr 2000 12:39:18 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id MAA27201; Wed, 12 Apr 2000 12:05:38 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id MAA27148 for ; Wed, 12 Apr 2000 12:05:33 -0400 (EDT) Received: from procyon.pmc-sierra.bc.ca (procyon.pmc-sierra.bc.ca [134.87.115.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA25577 for ; Wed, 12 Apr 2000 12:08:01 -0400 (EDT) Received: from nt-exchange1.pmc-sierra.bc.ca (nt-exchange1.pmc-sierra.bc.ca [134.87.116.183]) by procyon.pmc-sierra.bc.ca (6.6.6/6.6.6) with ESMTP id JAA13610 for ; Wed, 12 Apr 2000 09:08:02 -0700 (PDT) Received: by nt-exchange1.pmc-sierra.bc.ca with Internet Mail Service (5.5.2650.21) id <2J27455F>; Wed, 12 Apr 2000 09:08:02 -0700 Message-ID: <336ECDAFDF7DD311B9E30090277AEE4101B404C9@nt-exchange-bby.pmc-sierra.bc.ca> From: Shahram Davari To: diffserv@ietf.org Subject: RE: [Diffserv] Definition of a BA Date: Wed, 12 Apr 2000 09:05:23 -0700 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: text/plain; charset="iso-8859-1" Sender: diffserv-admin@ietf.org Errors-To: diffserv-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Diffserv Discussion List X-BeenThere: diffserv@ietf.org Hi, What if we define a BA that applies to only one DSCP. Then the current definition of OA can be applied to a group of BAs that uses a PHB group (of course having the ordering constraints). And we don't need to invent any new term. -Shahram >-----Original Message----- >From: Brian E Carpenter [mailto:brian@hursley.ibm.com] >Sent: Wednesday, April 12, 2000 11:03 AM >To: Shahram Davari >Cc: Grenville Armitage; Dan Grossman; diffserv@ietf.org >Subject: Re: [Diffserv] Definition of a BA > > >If that's the question, I think it is for whoever is brave enough to >draft a BA description for AF to answer. If the answer is no, >it means that the aggregate behaviour of AF can't be described. > > Brian > >Shahram Davari wrote: >> >> Brian, >> >> I think Grenville's question was why packet's with different >DSCPs that >> indicate a PHB group are part of a single BA? For example assume >> AF11=>DSCP1, AF12=>DSCP2 and AF13=>DSCP3, now if we have >packets with DSCP1, >> DSCP2, DSCP3, are they part of a single BA? or they belong to 3 BAs? >> >> Regards, >> -Shahram >> >> >-----Original Message----- >> >From: Brian E Carpenter [mailto:brian@hursley.ibm.com] >> >Sent: Wednesday, April 12, 2000 9:55 AM >> >To: Grenville Armitage >> >Cc: Dan Grossman; diffserv@ietf.org >> >Subject: Re: [Diffserv] Definition of a BA >> > >> > >> >Grenville, >> > >> >Grenville Armitage wrote: >> >... >> >> Hmmm... perhaps my head is still flushing the opposite >way after the >> >> IETF, but can you remind me why must we presume that packets in a >> >> PHB Group are part of the same BA? (Or is this tied up with the >> >> impending re-definition of BA?) >> > >> >A BA classifier only looks at the DSCP, so a BA classifier cannot >> >discriminate between hypothetically different "BAs" whose >> >packets carry >> >the same DSCP. Since we want interior routers to be able to use BA >> >classifiers, it follows that at a given interior router interface, >> >all packets belonging to a given PHB Group are in the same BA. >> > >> > Brian >> > >> >_______________________________________________ >> >diffserv mailing list >> >diffserv@ietf.org >> >http://www1.ietf.org/mailman/listinfo/diffserv >> >Archive: http://www-nrg.ee.lbl.gov/diff-serv-arch/ >> > >> >> _______________________________________________ >> diffserv mailing list >> diffserv@ietf.org >> http://www1.ietf.org/mailman/listinfo/diffserv >> Archive: http://www-nrg.ee.lbl.gov/diff-serv-arch/ > _______________________________________________ diffserv mailing list diffserv@ietf.org http://www1.ietf.org/mailman/listinfo/diffserv Archive: http://www-nrg.ee.lbl.gov/diff-serv-arch/ From diffserv-admin@ietf.org Wed Apr 12 14:29:53 2000 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA00541 for ; Wed, 12 Apr 2000 14:29:53 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id NAA28935; Wed, 12 Apr 2000 13:54:36 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id NAA28904 for ; Wed, 12 Apr 2000 13:54:32 -0400 (EDT) Received: from motgate2.mot.com (motgate2.mot.com [136.182.1.10]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA29640 for ; Wed, 12 Apr 2000 13:56:58 -0400 (EDT) Received: [from mothost.mot.com (mothost.mot.com [129.188.137.101]) by motgate2.mot.com (motgate2 2.1) with ESMTP id KAA24973 for ; Wed, 12 Apr 2000 10:56:58 -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 KAA14596 for ; Wed, 12 Apr 2000 10:56:58 -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 NAA24212 for ; Wed, 12 Apr 2000 13:56:57 -0400 (EDT) Message-Id: <200004121756.NAA24212@noah.dma.isg.mot.com> X-Mailer: exmh version 1.6.7 5/3/96 To: diffserv@ietf.org Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Wed, 12 Apr 2000 13:56:57 -0400 From: Dan Grossman Subject: [Diffserv] BA 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 Yesterday, I mentioned having discussed some ideas that Brian concerning the BA draft. It is becoming increasingly clear that these ideas need to be discussed on the list at the same time as the other issue with the definition of BA, especially since that discussion is going off into the weeds. Since Adelaide, I've also had a chance to think some more about this, and will mix some of those thoughts with what we discussed. Brian is free to disagree with and/or repudiate any or all of the following. The problem as I now see it is that we seem to agree that we need a framework for an amphibious bird that has a long flat beak, waddles on webbed feet and quacks --- but we're not allowed to call it a duck :-). So be it. The -00 BA draft tried to dance around the problem by appropriating another concept and redefining it halfway (as Scott pointed out yesterday, and I was trying to point out in Adelaide). This did nothing but confuse matters. The concept of the following is to retain the meaning of BA as we presently know it. It then creates a new term that contains "BA" to really mean edge-to-edge service; The latter is in the interest of not having to revise the charter, or violate the taboo against defining services. New terms (sorry): Behavior Aggregate Class (BA Class): A set of rules, characteristics, parameters and assumptions which, together, define the treatment accorded to a **type** of edge to edge BA or cloud BA. A BA class defines the service (see definition of service in RFC 2475) provided by a single DS domain to a Link BA or Cloud BA. Link Behavior Aggregate (Link BA): a collection of packets with the same DS codepoint crossing a link in a particular direction. Referred to as a BA in RFC 2475. Edge-to-edge Behavior aggregate (E-E BA): a collection of packets with the same DS codepoint [or whatever :-)] crossing a DS domain from one [or more?] DS ingress node to one [or more?] DS egress node. Cloud Behavior Aggregate (Cloud BA) : the set of packets with the same DS codepoint crossing a DS domain from [choice: (the set of all ingress nodes to the set of all egress nodes) | (from a set of ingress nodes to an egress node) | (from a set of ingress nodes to a set of egress nodes?)] [having at least one common link BA?] Brian and I couldn't decide whether the cloud BA concept was useful. I had trouble defining the thing; the hangup has to do with topological scope. The next version of the draft would start with these definitions and define a format for specification of BA classes. We make it clear that a BA class is definitely edge-to-edge or within a cloud, and not an end-to-end service, and only covers those elements of service that relate to Diffserv, and especially not business stuff. We also say that although E-E BAs having the same BA class can be concatenated across multiple DS domains to offer a multidomain service, that service can't necessarily be said to be of that BA class (notsure I agree completely with this statement, but the draft seems headed in that direction). We somehow relax the statement about measurable, quantifiable characteristics -- for example, we could say that these may be absolute or relative, qualitative or quantitative, objectives with statistical bounds and generally reflect back the wording in RFC 2475 and the limits of networks' ability to engineer for absolute bounds. Also, additional text (perhaps a section) is needed regarding topological considerations on characteristics. We probably would want to allow a unidirectional multicast E-E BA (although how this would interact with IGMP, multicast routing et al, I have no idea, yet). Dan _______________________________________________ diffserv mailing list diffserv@ietf.org http://www1.ietf.org/mailman/listinfo/diffserv Archive: http://www-nrg.ee.lbl.gov/diff-serv-arch/ From diffserv-admin@ietf.org Sun Apr 23 03:15:52 2000 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA01446; Sun, 23 Apr 2000 03:15:51 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id CAA13255; Sun, 23 Apr 2000 02:32:59 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id CAA13224 for ; Sun, 23 Apr 2000 02:32:55 -0400 (EDT) Received: from wiprom2mx2.wipro.com ([203.197.164.42]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA06753 for ; Sun, 23 Apr 2000 02:32:53 -0400 (EDT) Received: from m2vwall1.wipro.com (m2vwall1.wipro.com [164.164.27.50]) by wiprom2mx2.wipro.com (8.9.3/8.9.3) with ESMTP id OAA19939 for ; Sun, 23 Apr 2000 14:35:22 +0530 Received: from sarovar.mail.wipro.com ([164.164.27.50]) by m2vwall1.wipro.com (Netscape Messaging Server 3.6) with ESMTP id AAA1B1B for ; Sun, 23 Apr 2000 12:00:50 +0530 Received: from webmail ([192.168.2.18]) by sarovar.mail.wipro.com (Netscape Messaging Server 3.6) with SMTP id AAA4BBD for ; Sun, 23 Apr 2000 12:00:02 +0530 From: "Aditya Vikram Manpuria" To: diffserv@ietf.org X-Mailer: Netscape Messenger Express 3.5.2 [Mozilla/4.7 [en] (X11; I; Linux 2.2.13 i686)] Date: Sun, 23 Apr 2000 12:00:02 +0530 Message-ID: <77363942BBA.AAA4BBD@sarovar.mail.wipro.com> Subject: [Diffserv] A question on re-mapping Sender: diffserv-admin@ietf.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 relatively new to this mailing list. While going through the RFCs and drafts on diffserv, I had some thoughts which I would like to share with you. Your comments would be much appreciated. Consider the following scenario - In-profile traffic is mapped to a particular DSCP (say X) and out-profile traffic is mapped to another DSCP (say Y) which will lead the routers to adopt a relatively "inferior" forwarding behaviour. At the time of congestion, the router might want to drop packets from the BA whose corresponding DSCP value is Y. In this scenario, the probability of dropping packets which are "in-profile" and are mapped to this DSCP (ie Y) is equal to that of "out-profile" traffic which has been remapped to this DSCP. Is this not unfair ? Instead should we not look at some form of tagging mechanism to tag packets as "out-of-profile" when remapping them to other DSCP values. Probably one of the two unused bits in the DSCP octet could be used for this purpose. The router could then preferentially drop packets within a particular BA. Regards, Aditya. _______________________________________________ diffserv mailing list diffserv@ietf.org http://www1.ietf.org/mailman/listinfo/diffserv Archive: http://www-nrg.ee.lbl.gov/diff-serv-arch/ From diffserv-admin@ietf.org Sun Apr 23 21:47:12 2000 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA13088; Sun, 23 Apr 2000 21:47:12 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id VAA19896; Sun, 23 Apr 2000 21:00:45 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id VAA19869 for ; Sun, 23 Apr 2000 21:00:41 -0400 (EDT) Received: from hotmail.com (f10.law9.hotmail.com [64.4.9.10]) by ietf.org (8.9.1a/8.9.1a) with SMTP id VAA11852 for ; Sun, 23 Apr 2000 21:00:43 -0400 (EDT) Received: (qmail 88237 invoked by uid 0); 24 Apr 2000 01:00:14 -0000 Message-ID: <20000424010014.88236.qmail@hotmail.com> Received: from 128.230.151.69 by www.hotmail.com with HTTP; Sun, 23 Apr 2000 18:00:14 PDT X-Originating-IP: [128.230.151.69] From: "Mike Badil" To: diffserv@ietf.org Date: Sun, 23 Apr 2000 21:00:14 EDT Mime-Version: 1.0 Content-Type: text/plain; format=flowed Subject: [Diffserv] test Sender: diffserv-admin@ietf.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 just test ________________________________________________________________________ Get Your Private, Free E-mail from MSN Hotmail at http://www.hotmail.com _______________________________________________ diffserv mailing list diffserv@ietf.org http://www1.ietf.org/mailman/listinfo/diffserv Archive: http://www-nrg.ee.lbl.gov/diff-serv-arch/ From diffserv-admin@ietf.org Mon Apr 24 11:14:34 2000 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA05676; Mon, 24 Apr 2000 11:14:33 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id JAA00403; Mon, 24 Apr 2000 09:50:38 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id JAA00376 for ; Mon, 24 Apr 2000 09:50:34 -0400 (EDT) Received: from agni.wipinfo.soft.net (agni.wipinfo.soft.net [164.164.6.20]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA03822 for ; Mon, 24 Apr 2000 09:50:29 -0400 (EDT) Received: from vayu.wipinfo.soft.net (vayu [192.168.200.170]) by agni.wipinfo.soft.net (8.9.3/8.9.3) with ESMTP id TAA08935; Mon, 24 Apr 2000 19:17:01 +0500 (GMT) Received: from wipro.tcpn.com ([172.31.41.11]) by vayu.wipinfo.soft.net (8.9.3/8.9.3) with ESMTP id TAA25932; Mon, 24 Apr 2000 19:18:54 +0500 (GMT) Received: from arkavathi (arkavathi.wipro.tcpn.com [172.31.41.16]) by wipro.tcpn.com (8.9.3/8.9.3) with SMTP id TAA11753; Mon, 24 Apr 2000 19:23:44 +0530 (IST) Date: Mon, 24 Apr 2000 19:21:21 +0530 (GMT+0530) From: Aditya Manpuria X-Sender: aditya@arkavathi To: Anoop Ghanwani cc: diffserv@ietf.org Subject: Re: [Diffserv] A question on re-mapping In-Reply-To: <39030759.C61CD5F2@nortelnetworks.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 Anoop, Your observation holds good under the following conditions - 1) the router is using the AF PHB (and a DS compliant router need not necessarily implement this PHB) 2) out-of-profile packets are remarked with DSCP values from the same class (I am assuming that the resources allocated for any AF class, including its drop precedence levels, is constant) In the generic case, when a packet (with DSCP X) is remarked with DSCP Y, it starts competing for resources (buffer space/bandwidth) intended for "in-profile" traffic in the BA corresponding to DSCP Y. Now, when congestion sets in, and the router has to decide which packets to drop, I feel "out-of-profile" packets which have been remarked to this BA should be dropped first since there could be scenarios wherein such "out-of-profile" packets could hog a major part of the resources intended for this BA thereby starving traffic which are "in-profile" and belong to this BA. (In a way, this could also hold good for packets remarked within the same AF class) This is why I feel that we should look at some means of tagging packets as "out-of-profile" and using it to preferentially drop packets. Regards, Aditya. On Sun, 23 Apr 2000, Anoop Ghanwani wrote: > > The DSCP contains information that says that this packet > belongs to a particular class but has been downgraded. > For example, a packet marked with AF11, gets downgraded to > AF12, or AF13, which means the AF class stays the same > but the packet has a higher drop preference. So there's > nothing unfair :-) > > -Anoop > > aditya.manpuria@wipro.com wrote: > > > > Hi, > > I am relatively new to this mailing list. While going through the > > RFCs and drafts on diffserv, I had some thoughts which I would like to > > share with you. Your comments would be much appreciated. > > > > Consider the following scenario - > > > > In-profile traffic is mapped to a particular DSCP (say X) and > > out-profile traffic is mapped to another DSCP (say Y) which will lead the > > routers to adopt a relatively "inferior" forwarding behaviour. > > At the time of congestion, the router might want to drop packets > > from the BA whose corresponding DSCP value is Y. In this scenario, the > > probability of dropping packets which are "in-profile" and are mapped to > > this DSCP (ie Y) is equal to that of "out-profile" traffic which has been > > remapped to this DSCP. > > Is this not unfair ? > > Instead should we not look at some form of tagging mechanism to tag > > packets as "out-of-profile" when remapping them to other DSCP values. > > Probably one of the two unused bits in the DSCP octet could be used for > > this purpose. The router could then preferentially drop packets within a > > particular BA. > > > > Regards, > > Aditya. > > > > > > _______________________________________________ > > diffserv mailing list > > diffserv@ietf.org > > http://www1.ietf.org/mailman/listinfo/diffserv > > Archive: http://www-nrg.ee.lbl.gov/diff-serv-arch/ > > -- > Anoop Ghanwani, IP Infrastructure, Nortel Networks, Billerica, MA > Ph: 978-288-4514 Fax: 978-288-0620 aghanwan@nortelnetworks.com > _______________________________________________ diffserv mailing list diffserv@ietf.org http://www1.ietf.org/mailman/listinfo/diffserv Archive: http://www-nrg.ee.lbl.gov/diff-serv-arch/ From diffserv-admin@ietf.org Mon Apr 24 11:14:34 2000 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA05677; Mon, 24 Apr 2000 11:14:33 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id KAA00614; Mon, 24 Apr 2000 10:01:08 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id KAA00589 for ; Mon, 24 Apr 2000 10:01:04 -0400 (EDT) Received: from procyon.pmc-sierra.bc.ca (procyon.pmc-sierra.bc.ca [134.87.115.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA04222 for ; Mon, 24 Apr 2000 10:01:05 -0400 (EDT) Received: from nt-exchange1.pmc-sierra.bc.ca (nt-exchange1.pmc-sierra.bc.ca [134.87.116.183]) by procyon.pmc-sierra.bc.ca (6.6.6/6.6.6) with ESMTP id HAA20810; Mon, 24 Apr 2000 07:00:23 -0700 (PDT) Received: by nt-exchange1.pmc-sierra.bc.ca with Internet Mail Service (5.5.2650.21) id <2094N8FQ>; Mon, 24 Apr 2000 07:00:23 -0700 Message-ID: <336ECDAFDF7DD311B9E30090277AEE4101B404F5@nt-exchange-bby.pmc-sierra.bc.ca> From: Shahram Davari To: "'Aditya Manpuria'" , Anoop Ghanwani Cc: diffserv@ietf.org Subject: RE: [Diffserv] A question on re-mapping Date: Mon, 24 Apr 2000 06:57:42 -0700 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: text/plain; charset="iso-8859-1" Sender: diffserv-admin@ietf.org Errors-To: diffserv-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Diffserv Discussion List X-BeenThere: diffserv@ietf.org Hi, If you do not map any in-profile flow to the "Y" DSCP, then your required behavior is met. Regards, -Shahram >-----Original Message----- >From: Aditya Manpuria [mailto:Aditya.Manpuria@wipro.com] >Sent: Monday, April 24, 2000 9:51 AM >To: Anoop Ghanwani >Cc: diffserv@ietf.org >Subject: Re: [Diffserv] A question on re-mapping > > >Anoop, > Your observation holds good under the following conditions - >1) the router is using the AF PHB (and a DS compliant router need not >necessarily implement this PHB) >2) out-of-profile packets are remarked with DSCP values from the same >class >(I am assuming that the resources allocated for any AF class, including >its drop precedence levels, is constant) > > In the generic case, when a packet (with DSCP X) is >remarked with DSCP >Y, it starts competing for resources (buffer space/bandwidth) >intended for >"in-profile" traffic in the BA corresponding to DSCP Y. > Now, when congestion sets in, and the router has to decide which >packets to drop, I feel "out-of-profile" packets which have >been remarked >to this BA should be dropped first since there could be >scenarios wherein >such "out-of-profile" packets could hog a major part of the resources >intended for this BA thereby starving traffic which are >"in-profile" and >belong to this BA. > (In a way, this could also hold good for packets remarked within the >same AF class) > This is why I feel that we should look at some means of >tagging packets >as "out-of-profile" and using it to preferentially drop packets. > >Regards, >Aditya. > >On Sun, 23 Apr 2000, Anoop Ghanwani wrote: > >> >> The DSCP contains information that says that this packet >> belongs to a particular class but has been downgraded. >> For example, a packet marked with AF11, gets downgraded to >> AF12, or AF13, which means the AF class stays the same >> but the packet has a higher drop preference. So there's >> nothing unfair :-) >> >> -Anoop >> >> aditya.manpuria@wipro.com wrote: >> > >> > Hi, >> > I am relatively new to this mailing list. While >going through the >> > RFCs and drafts on diffserv, I had some thoughts which I >would like to >> > share with you. Your comments would be much appreciated. >> > >> > Consider the following scenario - >> > >> > In-profile traffic is mapped to a particular DSCP >(say X) and >> > out-profile traffic is mapped to another DSCP (say Y) >which will lead the >> > routers to adopt a relatively "inferior" forwarding behaviour. >> > At the time of congestion, the router might want >to drop packets >> > from the BA whose corresponding DSCP value is Y. In this >scenario, the >> > probability of dropping packets which are "in-profile" and >are mapped to >> > this DSCP (ie Y) is equal to that of "out-profile" traffic >which has been >> > remapped to this DSCP. >> > Is this not unfair ? >> > Instead should we not look at some form of tagging >mechanism to tag >> > packets as "out-of-profile" when remapping them to other >DSCP values. >> > Probably one of the two unused bits in the DSCP octet >could be used for >> > this purpose. The router could then preferentially drop >packets within a >> > particular BA. >> > >> > Regards, >> > Aditya. >> > >> > >> > _______________________________________________ >> > diffserv mailing list >> > diffserv@ietf.org >> > http://www1.ietf.org/mailman/listinfo/diffserv >> > Archive: http://www-nrg.ee.lbl.gov/diff-serv-arch/ >> >> -- >> Anoop Ghanwani, IP Infrastructure, Nortel Networks, Billerica, MA >> Ph: 978-288-4514 Fax: 978-288-0620 aghanwan@nortelnetworks.com >> > > >_______________________________________________ >diffserv mailing list >diffserv@ietf.org >http://www1.ietf.org/mailman/listinfo/diffserv >Archive: http://www-nrg.ee.lbl.gov/diff-serv-arch/ > _______________________________________________ diffserv mailing list diffserv@ietf.org http://www1.ietf.org/mailman/listinfo/diffserv Archive: http://www-nrg.ee.lbl.gov/diff-serv-arch/ From diffserv-admin@ietf.org Mon Apr 24 20:38:45 2000 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA18520; Mon, 24 Apr 2000 20:38:45 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id UAA05706; Mon, 24 Apr 2000 20:02:03 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id UAA05674 for ; Mon, 24 Apr 2000 20:01:59 -0400 (EDT) Received: from crufty.research.bell-labs.com (ns2.research.bell-labs.com [204.178.16.49]) by ietf.org (8.9.1a/8.9.1a) with SMTP id UAA18130 for ; Mon, 24 Apr 2000 20:02:03 -0400 (EDT) Received: from zubin.dnrc.bell-labs.com ([135.180.130.56]) by crufty; Mon Apr 24 20:00:49 EDT 2000 Received: from dnrc.bell-labs.com (gja000.lra.lucent.com [135.255.16.145]) by zubin.dnrc.bell-labs.com (8.9.3/8.9.3) with ESMTP id UAA19378; Mon, 24 Apr 2000 20:00:38 -0400 (EDT) Message-ID: <3904E10A.C389260E@dnrc.bell-labs.com> Date: Mon, 24 Apr 2000 17:04:26 -0700 From: Grenville Armitage Organization: Bell Laboratories, Lucent Technologies X-Mailer: Mozilla 4.61 [en] (WinNT; U) X-Accept-Language: en MIME-Version: 1.0 To: Aditya Manpuria CC: diffserv@ietf.org Subject: Re: [Diffserv] A question on re-mapping 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 Aditya Manpuria wrote: [..] > In the generic case, when a packet (with DSCP X) is remarked with DSCP > Y, it starts competing for resources (buffer space/bandwidth) intended for > "in-profile" traffic in the BA corresponding to DSCP Y. This scenario misuses DSCPs. By definition you should only map traffic into a given DSCP if *all* packets so marked are intended to get the same service. It is never the intention that the same DSCP provides multiple levels of servic - that's what other DSCPs are for. cheers, gja ________________________________________________________________________ Grenville Armitage http://members.home.net/garmitage/ Bell Labs Research Silicon Valley _______________________________________________ diffserv mailing list diffserv@ietf.org http://www1.ietf.org/mailman/listinfo/diffserv Archive: http://www-nrg.ee.lbl.gov/diff-serv-arch/ From diffserv-admin@ietf.org Thu Apr 27 17:37:27 2000 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA07242; Thu, 27 Apr 2000 17:37:27 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id QAA22973; Thu, 27 Apr 2000 16:47:26 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id QAA22947 for ; Thu, 27 Apr 2000 16:47:22 -0400 (EDT) Received: from mx2.tellabs.com (mx2.tellabs.com [204.68.180.51]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA06467 for ; Thu, 27 Apr 2000 16:47:25 -0400 (EDT) Received: from mail.hq.tellabs.com (tlab-138-111-51-100.tellabs.com [138.111.51.100] (may be forged)) by mx2.tellabs.com (8.8.8/8.8.8) with ESMTP id PAA10585; Thu, 27 Apr 2000 15:46:44 -0500 (CDT) Received: from tellabs ([192.168.7.104] (may be forged)) by mail.hq.tellabs.com (8.8.6 (PHNE_17135)/8.8.6) with SMTP id PAA17537; Thu, 27 Apr 2000 15:46:44 -0500 (CDT) Reply-To: From: "Kent Benson" To: Cc: Subject: RE: [Diffserv] issues with RFC 2598 Date: Thu, 27 Apr 2000 15:49:18 -0500 Message-ID: <002a01bfb08a$0f44dd50$6807a8c0@tellabs.hq.tellabs.com> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook 8.5, Build 4.71.2173.0 In-Reply-To: <4.2.0.58.20000417234549.00ca2cb0@pilgrim.cisco.com> X-MimeOLE: Produced By Microsoft MimeOLE V4.72.3110.3 Importance: Normal Content-Transfer-Encoding: 7bit Sender: diffserv-admin@ietf.org Errors-To: diffserv-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Diffserv Discussion List X-BeenThere: diffserv@ietf.org Content-Transfer-Encoding: 7bit Anna, Thanks for your suggestions. We (my colleagues and I) aren't exactly sure what kinds of behavior RFC 2598 was trying to allow and what behaviors it was trying to forbid. One reasonable guess we had comes straight from the first two sentences in section 2 ("The EF PHB is defined as a forwarding treatment for a particular diffserv aggregate where the departure rate of the aggregate's packets from any diffserv node must equal or exceed a configurable rate. The EF traffic SHOULD receive this rate independent of the intensity of any other traffic attempting to transit the node."). One possible way of interpreting these sentences would be this: the EF aggregate should receive service equal to or greater than the service it would receive from a fluid flow server from which it receives a minimum service rate equal to some configured rate. (Note that the fluid flow server does not have to be a Fluid Flow Queuing Server (Generalized Processor Sharing Server). In fact, it does not even have to be work conserving.) The discussions on the list have shown that this requirement needs a phrase like "within some tolerance" added to it somewhere for two reasons. First, realizable schedulers cannot give service that is identical to a fluid flow server since they can only transmit one packet at a time. Thus, packets must often be sent earlier or later than their fluid flow finish times. Second, many routers are not purely output buffered and so cannot be modeled as a collection of independent multiplexers feeding output links. A tolerance would allow for multistage switch fabrics with multiple contention points. It looks like the conformance definition from your last e-mail can give some behavior that does not fit with the "fluid flow server" criterion above. This definition can be restated as follows (this makes the third or fourth restatement from various people I think). Assume EF packet P_i with length L_i arrives at time a_i. Letting Q(t) be the number of EF bits in a device at time t, P_i finds Q(a_i-) bits in the system. (Note that Q(a_i+)=Q(a_i-)+L_i.) We require d_i, the departure time of P_i (the time P_i actually leaves the system) to satisfy d_i<=a_i+[Q(a_i+)/R_c]+E where R_c is the EF configured rate and E is a tolerance/error term. Assume it takes time T to serve a packet of length L at rate R_c. A series of packets of length of L arrive at times 0, T, 2T, 3T, and so on. P_1 arrives at time 0, finds 0 EF bits in the system. Thus, d_1<=a_1+[Q(0+)/R_c]+E=0+[L/R_c]+E=T+E. If E is large enough such that P_2 arrives (at time T) before P_1 begins service (at time T+E-(L/C)) then P_2 could find L bits still in the system. Thus, the largest d_2 could be is T+[2L/R_c]+E=3T+E. Continuing, the worst case allowable behavior is Packet # 1 2 3 4 5 6 7 8 a_i 0 T 2T 3T 4T 5T 6T 7T d_i T+E 3T+E 4T+E 6T+E 7T+E 8T+E 10T+E 11T+E The possible departure times can creep away from the fluid flow server ideal. Obviously, if you pick a different EF criterion then this behavior might not be considered undesirable. Our restatement of the EF definition given above leads pretty directly to the following requirement: F_i=max{a_i,F_(i-1)}+(L_i/R_c) d_i<=F_i+g(E) where F_i is the finish time of packet i in a fluid flow server that gives the EF aggregate service of exactly R_c at all times, d_i is the time by which packet i must be sent by the actual system, and g(E) is some tolerance/error function. I split the function g(E) out from F_i so it can't loop back and accumulate in the finish times. This Virtual Clock-like criterion would allow most common schedulers such as WFQ, WF2Q, SCFQ, and strict priority. This requirement has its drawbacks, of course, but it is something to think about. Kent >-----Original Message----- >From: acharny@cisco.com [mailto:acharny@cisco.com] >Sent: Tuesday, April 18, 2000 2:29 AM >To: Kent.Benson@tellabs.com >Cc: diffserv@ietf.org >Subject: OOPS: CORRECTIONS TO PREVIOUS MESSAGE. RE: [Diffserv] issues >with RFC 2598 > > >Kent and Diffservers, > >The previous message I sent earlier tonight seems to have more >than one >problem. Please see corrections below. My apologies. >It's a late hour... > >Anna >=============================================================== >============= >=================== > > >Kent, > > >Thank you for bringing up this issue. I think the point you >are raising >is very valid. My attempt to retain as much of the wording of >the >current EF definition as possible caused this issue that I >overlooked. While the definitions I gave allow many >reasonable >schedulers/devices to be compliant, it still does >not cover >some reasonable cases such as you are describing. Since these are >indeed >both reasonable and useful cases, this issue needs to >be addressed. > > >At second glance the following attempt of a definition does >not seem right >at all. Aside from a misplaced parenthes, it looks like this >approach >does not accounts for a fixed delay in the box, At the moment >I cannot >figure out how to make it right. Please disregard it for now. > > >If I understand it correctly, a standard way of dealing >with the problem >you are describing would be to say that if at time 0 there is no >EF >traffic in the queue, then for any t>0 the amount of >traffic served by >the EF aggregate by time t must be at least min(A(t), tR_conf-E), >where >A(t) denotes the number of EF bits that arrived to the >queue in the >interval (0, t), R_conf is the configured rate of the EF >queue, and E is >the >error term (tolerance term) (in bits). > >A straightforward conformance test would then need to look >at intervals >of type (0, t) rather than at intervals of type (t1, t2). > >The following text has been corrected to fix a typo and to include the >length of the arriving packet that I previously forgot. >Otherwise it still appears to be correct. > > >Another way of addressing this issue might be to require that an EF >packet of length L entering a device at time t and finding Q EF bits >in >the device must leave the device no later than at time >t+E+(Q+L)/R_conf (where E is in units of time). It may be >convenient to > >split the error term into fixed and rate-proportional delay >similarly to >how it is done done in RFC 2212. Choosing E to cover the >fixed >delay >should fix your problem ( in your example the only cause of >the delay is >the fixed delay, but of course E should also account for >scheduling >errors, etc). > >A straightforward conformance test would now keep track of >the number of >bits still in the box at the time of arrival of a given packet >and >see if >its departure time conforms to the definition. > > > >It seems to me that these two definitions still capture the original >intent of EF definition, allows all of the schedulers that would be >allowed >under the two alternatives I previously suggested, >and also take >care of the issues you brought up. Certainly these also need to >be >scrutinized for unnoticed and unwanted side effects. At >the moment I do >not see any. > >Unfortunately, these are much farther away from the original >wording of >the EF definition. > >So I guess we now have 4 options to consider. It is not getting any >easier :-). > >Well, we are down to three now :-) > >Anna > > > _______________________________________________ diffserv mailing list diffserv@ietf.org http://www1.ietf.org/mailman/listinfo/diffserv Archive: http://www-nrg.ee.lbl.gov/diff-serv-arch/ From diffserv-admin@ietf.org Thu Apr 27 23:32:11 2000 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA12772; Thu, 27 Apr 2000 23:32:10 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id WAA25692; Thu, 27 Apr 2000 22:24:14 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id WAA25666 for ; Thu, 27 Apr 2000 22:24:10 -0400 (EDT) Received: from pilgrim.cisco.com (pilgrim.cisco.com [171.69.204.12]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA11023 for ; Thu, 27 Apr 2000 22:24:11 -0400 (EDT) Received: from acharny_pc2 ([161.44.189.106]) by pilgrim.cisco.com (8.8.8-Cisco List Logging/8.8.8) with ESMTP id WAA05168; Thu, 27 Apr 2000 22:23:00 -0400 (EDT) Message-Id: <4.2.0.58.20000427204001.00d671b0@pilgrim.cisco.com> X-Sender: acharny@pilgrim.cisco.com X-Mailer: QUALCOMM Windows Eudora Pro Version 4.2.0.58 Date: Thu, 27 Apr 2000 22:26:24 -0700 To: Kent.Benson@tellabs.com From: Anna Charny Subject: RE: [Diffserv] issues with RFC 2598 Cc: diffserv@ietf.org, leboudec@epfl.ch In-Reply-To: <002a01bfb08a$0f44dd50$6807a8c0@tellabs.hq.tellabs.com> References: <4.2.0.58.20000417234549.00ca2cb0@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 Kent, Thanks for your comments. Yes, I am by now aware of the side effect of the last definition I gave. While it does seem to allow all the known scheduling implementations I have thought of that appear reasonable for EF, it also allows a compliant scheduling sequence that gives only asymptotic rate guarantees. The problem that we are facing appears to be that all the "simple" definitions we have so far come up with appear either to disallow many or some reasonable schedulers, or allow some schedulers which appear to obviously not be "good" for EF. We have discussed at length that the current definition in RFC 2598 does not allow any schedulers at all. A simple addition of the busy period allows some schedulers, but imposes rate limitations that may be unnecessary. An addition of a slack term allows all the WFQ-like schedulers, but still does not work for purely delay-based schedulers. As mentioned above, and as your example indicates, the definition based on the time to drain the queue at the right rate (with the slack term) appears to allow the common reasonable schedulers, but in addition allows the cases such as you give in your example, where rate is guaranteed only asymptotically. Finally, your definition that you give below appears to have an unwanted side effect of the virtual clock scheduler, which is that a flow that sends more packets initially (and gets transmitted in the absence of competing traffic) then can get punished later. For example, suppose EF aggregate has configured rate 1/2 of the output link speed. Suppose at time zero a 100 packets arrive, each from a separate input. Then, when the F_i will be updated to account for all packets, it will set to 200T, where T is the packet time at link speed. Suppose at time 101T a new packet arrives from yet another link. Its finish time is then set to max (101T, 200T)+2T, and its deadline is then 202T_g(E). Then the following scheduling sequence is compliant under your definition: send packets 1-100 back to back at times 1T,2T,3T...100T, then send packet 101 at time 202T+g(E) So in the interval (101T, 202T+ g(E)) nothing is sent without violating compliance, while the queue is continuously busy in that interval. It seems that this is not what we want either... Would you agree? I have been talking to Jean-Yves Le Boudec about this problem. He is of the opinion that the only way we could avoid these problems is to use the definition based on service curves, as introduced by Cruz, and as used in the Intserv context. We are still in the process of figuring out some issues surrounding this. I am copying Jean-Yves directly in case he would like to comment. In any case, it seems clear that either we should settle on a simple definition that has some known drawbacks (e.g. allows some (perhaps not as complete as we would like) set of known schedulers that seem reasonable for EF implementation, and does not allow those which are obviously bad), or the definition must be substantially more complicated than has been originally envisioned. Regards, Anna at 03:49 PM 4/27/00 -0500, Kent Benson wrote: >Anna, > >Thanks for your suggestions. We (my colleagues and I) aren't exactly sure >what kinds of behavior RFC 2598 was trying to allow and what behaviors it >was trying to forbid. One reasonable guess we had comes straight from the >first two sentences in section 2 ("The EF PHB is defined as a forwarding >treatment for a particular diffserv aggregate where the departure rate of >the aggregate's packets from any diffserv node must equal or exceed a >configurable rate. The EF traffic SHOULD receive this rate independent of >the intensity of any other traffic attempting to transit the node."). One >possible way of interpreting these sentences would be this: the EF aggregate >should receive service equal to or greater than the service it would receive >from a fluid flow server from which it receives a minimum service rate equal >to some configured rate. (Note that the fluid flow server does not have to >be a Fluid Flow Queuing Server (Generalized Processor Sharing Server). In >fact, it does not even have to be work conserving.) The discussions on the >list have shown that this requirement needs a phrase like "within some >tolerance" added to it somewhere for two reasons. First, realizable >schedulers cannot give service that is identical to a fluid flow server >since they can only transmit one packet at a time. Thus, packets must often >be sent earlier or later than their fluid flow finish times. Second, many >routers are not purely output buffered and so cannot be modeled as a >collection of independent multiplexers feeding output links. A tolerance >would allow for multistage switch fabrics with multiple contention points. > >It looks like the conformance definition from your last e-mail can give some >behavior that does not fit with the "fluid flow server" criterion above. >This definition can be restated as follows (this makes the third or fourth >restatement from various people I think). Assume EF packet P_i with length >L_i arrives at time a_i. Letting Q(t) be the number of EF bits in a device >at time t, P_i finds Q(a_i-) bits in the system. (Note that >Q(a_i+)=Q(a_i-)+L_i.) We require d_i, the departure time of P_i (the time >P_i actually leaves the system) to satisfy > >d_i<=a_i+[Q(a_i+)/R_c]+E > >where R_c is the EF configured rate and E is a tolerance/error term. > >Assume it takes time T to serve a packet of length L at rate R_c. A series >of packets of length of L arrive at times 0, T, 2T, 3T, and so on. P_1 >arrives at time 0, finds 0 EF bits in the system. Thus, >d_1<=a_1+[Q(0+)/R_c]+E=0+[L/R_c]+E=T+E. If E is large enough such that P_2 >arrives (at time T) before P_1 begins service (at time T+E-(L/C)) then P_2 >could find L bits still in the system. Thus, the largest d_2 could be is >T+[2L/R_c]+E=3T+E. Continuing, the worst case allowable behavior is > >Packet # 1 2 3 4 5 6 7 8 >a_i 0 T 2T 3T 4T 5T 6T 7T >d_i T+E 3T+E 4T+E 6T+E 7T+E 8T+E 10T+E 11T+E > >The possible departure times can creep away from the fluid flow server >ideal. Obviously, if you pick a different EF criterion then this behavior >might not be considered undesirable. > >Our restatement of the EF definition given above leads pretty directly to >the following requirement: > >F_i=max{a_i,F_(i-1)}+(L_i/R_c) > >d_i<=F_i+g(E) > >where F_i is the finish time of packet i in a fluid flow server that gives >the EF aggregate service of exactly R_c at all times, d_i is the time by >which packet i must be sent by the actual system, and g(E) is some >tolerance/error function. I split the function g(E) out from F_i so it >can't loop back and accumulate in the finish times. > >This Virtual Clock-like criterion would allow most common schedulers such as >WFQ, WF2Q, SCFQ, and strict priority. This requirement has its drawbacks, >of course, but it is something to think about. > >Kent > > > >-----Original Message----- > >From: acharny@cisco.com [mailto:acharny@cisco.com] > >Sent: Tuesday, April 18, 2000 2:29 AM > >To: Kent.Benson@tellabs.com > >Cc: diffserv@ietf.org > >Subject: OOPS: CORRECTIONS TO PREVIOUS MESSAGE. RE: [Diffserv] issues > >with RFC 2598 > > > > > >Kent and Diffservers, > > > >The previous message I sent earlier tonight seems to have more > >than one > >problem. Please see corrections below. My apologies. > >It's a late hour... > > > >Anna > >=============================================================== > >============= > >=================== > > > > >Kent, > > > > >Thank you for bringing up this issue. I think the point you > >are raising > >is very valid. My attempt to retain as much of the wording of > >the >current EF definition as possible caused this issue that I > >overlooked. While the definitions I gave allow many > >reasonable >schedulers/devices to be compliant, it still does > >not cover > >some reasonable cases such as you are describing. Since these are > >indeed >both reasonable and useful cases, this issue needs to > >be addressed. > > > > > >At second glance the following attempt of a definition does > >not seem right > >at all. Aside from a misplaced parenthes, it looks like this > >approach > >does not accounts for a fixed delay in the box, At the moment > >I cannot > >figure out how to make it right. Please disregard it for now. > > > > >If I understand it correctly, a standard way of dealing > >with the problem > >you are describing would be to say that if at time 0 there is no > >EF >traffic in the queue, then for any t>0 the amount of > >traffic served by > >the EF aggregate by time t must be at least min(A(t), tR_conf-E), > >where >A(t) denotes the number of EF bits that arrived to the > >queue in the > >interval (0, t), R_conf is the configured rate of the EF > >queue, and E is > >the >error term (tolerance term) (in bits). > > >A straightforward conformance test would then need to look > >at intervals > >of type (0, t) rather than at intervals of type (t1, t2). > > > >The following text has been corrected to fix a typo and to include the > >length of the arriving packet that I previously forgot. > >Otherwise it still appears to be correct. > > > > >Another way of addressing this issue might be to require that an EF > >packet of length L entering a device at time t and finding Q EF bits > >in >the device must leave the device no later than at time > >t+E+(Q+L)/R_conf (where E is in units of time). It may be > >convenient to > > >split the error term into fixed and rate-proportional delay > >similarly to > >how it is done done in RFC 2212. Choosing E to cover the > >fixed >delay > >should fix your problem ( in your example the only cause of > >the delay is > >the fixed delay, but of course E should also account for >scheduling > >errors, etc). > > >A straightforward conformance test would now keep track of > >the number of > >bits still in the box at the time of arrival of a given packet > >and >see if > >its departure time conforms to the definition. > > > > > > >It seems to me that these two definitions still capture the original > >intent of EF definition, allows all of the schedulers that would be > >allowed >under the two alternatives I previously suggested, > >and also take > >care of the issues you brought up. Certainly these also need to > >be >scrutinized for unnoticed and unwanted side effects. At > >the moment I do > >not see any. > > >Unfortunately, these are much farther away from the original > >wording of > >the EF definition. > > >So I guess we now have 4 options to consider. It is not getting any > >easier :-). > > > >Well, we are down to three now :-) > > > >Anna > > > > > > _______________________________________________ diffserv mailing list diffserv@ietf.org http://www1.ietf.org/mailman/listinfo/diffserv Archive: http://www-nrg.ee.lbl.gov/diff-serv-arch/ From diffserv-admin@ietf.org Fri Apr 28 18:08:11 2000 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA12981; Fri, 28 Apr 2000 18:08:11 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id QAA09751; Fri, 28 Apr 2000 16:59:03 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id QAA09727 for ; Fri, 28 Apr 2000 16:58:59 -0400 (EDT) Received: from mx2.tellabs.com (mx2.tellabs.com [204.68.180.51]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA11469 for ; Fri, 28 Apr 2000 16:58:58 -0400 (EDT) Received: from mail.hq.tellabs.com (tlab-138-111-51-100.tellabs.com [138.111.51.100] (may be forged)) by mx2.tellabs.com (8.8.8/8.8.8) with ESMTP id PAA01249; Fri, 28 Apr 2000 15:58:24 -0500 (CDT) Received: from tellabs ([192.168.7.104] (may be forged)) by mail.hq.tellabs.com (8.8.6 (PHNE_17135)/8.8.6) with SMTP id PAA07183; Fri, 28 Apr 2000 15:58:23 -0500 (CDT) Reply-To: From: "Kent Benson" To: Cc: , Subject: RE: [Diffserv] issues with RFC 2598 Date: Fri, 28 Apr 2000 16:00:58 -0500 Message-ID: <002901bfb154$dad95a70$6807a8c0@tellabs.hq.tellabs.com> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook 8.5, Build 4.71.2173.0 In-Reply-To: <4.2.0.58.20000427204001.00d671b0@pilgrim.cisco.com> X-MimeOLE: Produced By Microsoft MimeOLE V4.72.3110.3 Importance: Normal Content-Transfer-Encoding: 7bit Sender: diffserv-admin@ietf.org Errors-To: diffserv-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Diffserv Discussion List X-BeenThere: diffserv@ietf.org Content-Transfer-Encoding: 7bit Anna, Everything you say is true, I fear. It may be necessary to choose one of the following options: some "reasonable" output patterns are not compliant, some "unreasonable" output patterns are compliant, or the compliance definition is quite complicated. I suppose it comes down to how desirable the "reasonable" cases would be, how undesirable the "unreasonable" cases would be, how complex the "complicated" standard would be, and how people are willing to trade off these factors. The likelihood of the particular circumstances that could lead to an undesirable output could also be a factor. It does look like both of our recent compliance definitions would allow a scheduler to produce an output with large gaps between EF packets. It would be nice if WFQ with the minimum EF rate set equal to the EF configured rate would be compliant under any new conformance definition. Since WFQ can produce surprisingly large inter-packet gaps under some conditions, however, any conformance criterion that rules out certain gaps between EF packets will eliminate WFQ from consideration (at least using this simple configuration). Maybe saving this simple configuration is not worth the downside and anyone wanting to use WFQ should just be careful to set the EF weight high enough. It would be nice if a simple rule for "high enough" could be found. On a related note, does anyone know of any results that bound the real time difference between a packet's departure time and its finish time, for example as a function of the number of other flows and their weights? What's the tightest bound for a flow that does not have the largest weight, for instance. Thanks, Kent >-----Original Message----- >From: acharny@cisco.com [mailto:acharny@cisco.com] >Sent: Friday, April 28, 2000 12:26 AM >To: Kent.Benson@tellabs.com >Cc: diffserv@ietf.org; leboudec@epfl.ch >Subject: RE: [Diffserv] issues with RFC 2598 > > >Kent, > >Thanks for your comments. Yes, I am by now aware of the side >effect of the >last definition I gave. While it does seem to allow all the known >scheduling implementations I have thought of that appear >reasonable for EF, >it also allows a compliant scheduling sequence that gives only >asymptotic >rate guarantees. > >The problem that we are facing appears to be that all the "simple" >definitions we have so far come up with >appear either to disallow many or some reasonable schedulers, >or allow some >schedulers which appear to obviously >not be "good" for EF. > >We have discussed at length that the current definition in RFC >2598 does >not allow any schedulers at all. >A simple addition of the busy period allows some schedulers, >but imposes >rate limitations that may be unnecessary. An addition of >a slack term allows all the WFQ-like schedulers, but still >does not work >for purely delay-based schedulers. As mentioned above, and as >your example >indicates, the definition based on the time to drain the queue >at the right >rate (with the slack term) appears to allow the common reasonable >schedulers, but in addition allows the cases such as you give in your >example, where rate is guaranteed only asymptotically. > >Finally, your definition that you give below appears to have >an unwanted >side effect of the virtual clock scheduler, which is that a >flow that sends >more packets initially (and gets transmitted in the absence of >competing >traffic) then can get punished later. For example, suppose >EF aggregate has configured rate 1/2 of the output link speed. > Suppose at >time zero a 100 packets arrive, each from a separate input. Then, when >the F_i will be updated to account for all packets, it will >set to 200T, >where T is the packet time at link speed. Suppose at time 101T a new >packet arrives from yet another link. Its finish time is then >set to max >(101T, 200T)+2T, and its deadline is then 202T_g(E). > >Then the following scheduling sequence is compliant under your >definition: > >send packets 1-100 back to back at times 1T,2T,3T...100T, then >send packet >101 at time 202T+g(E) > >So in the interval (101T, 202T+ g(E)) nothing is sent without >violating >compliance, while the queue is continuously busy in that interval. >It seems that this is not what we want either... Would you agree? > >I have been talking to Jean-Yves Le Boudec about this problem. >He is of the >opinion that the only way we could avoid these problems is to use the >definition based on service curves, as introduced by Cruz, and >as used in >the Intserv context. We are still in the process of figuring out some >issues surrounding this. I am copying Jean-Yves directly in >case he would >like to comment. > >In any case, it seems clear that either we should settle on a simple >definition that has some known drawbacks (e.g. allows some >(perhaps not as >complete as we would like) set of known schedulers that seem >reasonable for >EF implementation, and does not allow those which are >obviously bad), or >the definition must be substantially more complicated than has been >originally envisioned. > >Regards, >Anna > >at 03:49 PM 4/27/00 -0500, Kent Benson wrote: > >>Anna, >> >>Thanks for your suggestions. We (my colleagues and I) aren't >exactly sure >>what kinds of behavior RFC 2598 was trying to allow and what >behaviors it >>was trying to forbid. One reasonable guess we had comes >straight from the >>first two sentences in section 2 ("The EF PHB is defined as a >forwarding >>treatment for a particular diffserv aggregate where the >departure rate of >>the aggregate's packets from any diffserv node must equal or exceed a >>configurable rate. The EF traffic SHOULD receive this rate >independent of >>the intensity of any other traffic attempting to transit the >node."). One >>possible way of interpreting these sentences would be this: >the EF aggregate >>should receive service equal to or greater than the service >it would receive >>from a fluid flow server from which it receives a minimum >service rate equal >>to some configured rate. (Note that the fluid flow server >does not have to >>be a Fluid Flow Queuing Server (Generalized Processor Sharing >Server). In >>fact, it does not even have to be work conserving.) The >discussions on the >>list have shown that this requirement needs a phrase like "within some >>tolerance" added to it somewhere for two reasons. First, realizable >>schedulers cannot give service that is identical to a fluid >flow server >>since they can only transmit one packet at a time. Thus, >packets must often >>be sent earlier or later than their fluid flow finish times. >Second, many >>routers are not purely output buffered and so cannot be modeled as a >>collection of independent multiplexers feeding output links. >A tolerance >>would allow for multistage switch fabrics with multiple >contention points. >> >>It looks like the conformance definition from your last >e-mail can give some >>behavior that does not fit with the "fluid flow server" >criterion above. >>This definition can be restated as follows (this makes the >third or fourth >>restatement from various people I think). Assume EF packet >P_i with length >>L_i arrives at time a_i. Letting Q(t) be the number of EF >bits in a device >>at time t, P_i finds Q(a_i-) bits in the system. (Note that >>Q(a_i+)=Q(a_i-)+L_i.) We require d_i, the departure time of >P_i (the time >>P_i actually leaves the system) to satisfy >> >>d_i<=a_i+[Q(a_i+)/R_c]+E >> >>where R_c is the EF configured rate and E is a tolerance/error term. >> >>Assume it takes time T to serve a packet of length L at rate >R_c. A series >>of packets of length of L arrive at times 0, T, 2T, 3T, and >so on. P_1 >>arrives at time 0, finds 0 EF bits in the system. Thus, >>d_1<=a_1+[Q(0+)/R_c]+E=0+[L/R_c]+E=T+E. If E is large enough >such that P_2 >>arrives (at time T) before P_1 begins service (at time >T+E-(L/C)) then P_2 >>could find L bits still in the system. Thus, the largest d_2 >could be is >>T+[2L/R_c]+E=3T+E. Continuing, the worst case allowable behavior is >> >>Packet # 1 2 3 4 5 6 7 8 >>a_i 0 T 2T 3T 4T 5T 6T 7T >>d_i T+E 3T+E 4T+E 6T+E 7T+E 8T+E 10T+E 11T+E >> >>The possible departure times can creep away from the fluid flow server >>ideal. Obviously, if you pick a different EF criterion then >this behavior >>might not be considered undesirable. >> >>Our restatement of the EF definition given above leads pretty >directly to >>the following requirement: >> >>F_i=max{a_i,F_(i-1)}+(L_i/R_c) >> >>d_i<=F_i+g(E) >> >>where F_i is the finish time of packet i in a fluid flow >server that gives >>the EF aggregate service of exactly R_c at all times, d_i is >the time by >>which packet i must be sent by the actual system, and g(E) is some >>tolerance/error function. I split the function g(E) out from >F_i so it >>can't loop back and accumulate in the finish times. >> >>This Virtual Clock-like criterion would allow most common >schedulers such as >>WFQ, WF2Q, SCFQ, and strict priority. This requirement has >its drawbacks, >>of course, but it is something to think about. >> >>Kent >> >> >> >-----Original Message----- >> >From: acharny@cisco.com [mailto:acharny@cisco.com] >> >Sent: Tuesday, April 18, 2000 2:29 AM >> >To: Kent.Benson@tellabs.com >> >Cc: diffserv@ietf.org >> >Subject: OOPS: CORRECTIONS TO PREVIOUS MESSAGE. RE: >[Diffserv] issues >> >with RFC 2598 >> > >> > >> >Kent and Diffservers, >> > >> >The previous message I sent earlier tonight seems to have more >> >than one >> >problem. Please see corrections below. My apologies. >> >It's a late hour... >> > >> >Anna >> >=============================================================== >> >============= >> >=================== >> > >> > >Kent, >> > >> > >Thank you for bringing up this issue. I think the point you >> >are raising >> >is very valid. My attempt to retain as much of the wording of >> >the >current EF definition as possible caused this issue that I >> >overlooked. While the definitions I gave allow many >> >reasonable >schedulers/devices to be compliant, it still does >> >not cover >> >some reasonable cases such as you are describing. Since these are >> >indeed >both reasonable and useful cases, this issue needs to >> >be addressed. >> > >> > >> >At second glance the following attempt of a definition does >> >not seem right >> >at all. Aside from a misplaced parenthes, it looks like this >> >approach >> >does not accounts for a fixed delay in the box, At the moment >> >I cannot >> >figure out how to make it right. Please disregard it for now. >> > >> > >If I understand it correctly, a standard way of dealing >> >with the problem >> >you are describing would be to say that if at time 0 there is no >> >EF >traffic in the queue, then for any t>0 the amount of >> >traffic served by >> >the EF aggregate by time t must be at least min(A(t), tR_conf-E), >> >where >A(t) denotes the number of EF bits that arrived to the >> >queue in the >> >interval (0, t), R_conf is the configured rate of the EF >> >queue, and E is >> >the >error term (tolerance term) (in bits). >> > >A straightforward conformance test would then need to look >> >at intervals >> >of type (0, t) rather than at intervals of type (t1, t2). >> > >> >The following text has been corrected to fix a typo and to >include the >> >length of the arriving packet that I previously forgot. >> >Otherwise it still appears to be correct. >> > >> > >Another way of addressing this issue might be to require >that an EF >> >packet of length L entering a device at time t and finding >Q EF bits >> >in >the device must leave the device no later than at time >> >t+E+(Q+L)/R_conf (where E is in units of time). It may be >> >convenient to >> > >split the error term into fixed and rate-proportional delay >> >similarly to >> >how it is done done in RFC 2212. Choosing E to cover the >> >fixed >delay >> >should fix your problem ( in your example the only cause of >> >the delay is >> >the fixed delay, but of course E should also account for >scheduling >> >errors, etc). >> > >A straightforward conformance test would now keep track of >> >the number of >> >bits still in the box at the time of arrival of a given packet >> >and >see if >> >its departure time conforms to the definition. >> > >> > >> > >It seems to me that these two definitions still capture >the original >> >intent of EF definition, allows all of the schedulers that would be >> >allowed >under the two alternatives I previously suggested, >> >and also take >> >care of the issues you brought up. Certainly these also need to >> >be >scrutinized for unnoticed and unwanted side effects. At >> >the moment I do >> >not see any. >> > >Unfortunately, these are much farther away from the original >> >wording of >> >the EF definition. >> > >So I guess we now have 4 options to consider. It is not >getting any >> >easier :-). >> > >> >Well, we are down to three now :-) >> > >> >Anna >> > >> > >> > > > _______________________________________________ diffserv mailing list diffserv@ietf.org http://www1.ietf.org/mailman/listinfo/diffserv Archive: http://www-nrg.ee.lbl.gov/diff-serv-arch/ From diffserv-admin@ietf.org Sun Apr 30 17:33:37 2000 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA04524; Sun, 30 Apr 2000 17:33:37 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id QAA03100; Sun, 30 Apr 2000 16:55:08 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id QAA03074 for ; Sun, 30 Apr 2000 16:55:04 -0400 (EDT) Received: from smtppop2.gte.net (smtppop2.gte.net [207.115.153.21]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA04272 for ; Sun, 30 Apr 2000 16:55:01 -0400 (EDT) Received: from 10 (lsanca1-ar5-216-197.dsl.gtei.net [4.33.216.197]) by smtppop2.gte.net with SMTP ; id PAA21967667 Sun, 30 Apr 2000 15:55:15 -0500 (CDT) Message-ID: <000701bfb2e6$5e03e900$c5d82104@dsl.gtei.net> From: "Bill Courtney" To: , "Anna Charny" Cc: References: <4.2.0.58.20000417234549.00ca2cb0@pilgrim.cisco.com> <4.2.0.58.20000427204001.00d671b0@pilgrim.cisco.com> Subject: Re: [Diffserv] issues with RFC 2598 Date: Sun, 30 Apr 2000 13:55:06 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.00.2314.1300 X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2314.1300 Content-Transfer-Encoding: 7bit Sender: diffserv-admin@ietf.org Errors-To: diffserv-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Diffserv Discussion List X-BeenThere: diffserv@ietf.org Content-Transfer-Encoding: 7bit Anna & Kent, I believe that the recent difficulties our WG has been having in defining a conforming service for the EF PHB are stemming from our trying to mold a descriptive equation of a conforming scheduler into a prescriptive equation. Specifically, I'm referring to the assignment of target departure times on a per-packet basis and at the time of the packet's arrival at the scheduler. Kent's group observed that a scheduler can benefit from an accumulation of late delivery tolerances, causing the throughput to creep away from the ideal fluid server. Anna observed that Kent's group's proposed separation of tolerance/error from the target departure time can lead to a crediting of the scheduler for past better-than-ideal service and to huge service droughts. Yet, both of these behaviors would be compliant under the respective proposed definitions. I think that the root of the problem with both unreasonably compliant behaviors lies in the attempt to define a target departure time for a packet when it arrives. If we consider the fairest packet scheduler that is known, WF2Q, we see that it assigns a start and finish time not to each queued packet, but rather to each queue. The excellent WFI that results is not part of the algorithm or even a criterion that the algorithm must satisfy. It is simply a description of the outcome of the algorithm's performance. In this vein, I'd like to propose a simple criterion as a definition of conformant EF PHB. As with WF2Q, the criterion does not assign finish times to packets. Instead, it assigns a target finish time and a tolerance to the EF queue, or, if you will, to the earliest arriving EF packet still in the system (i.e., in service or in the EF queue). The criterion uses a small number of terms, namely R, the configured rate of the EF aggregate (bits/second) L, the length of the earliest arriving EF packet in the system (bits) Q, a state variable indicating whether (Q=1) or not (Q=0) the EF aggregate has a packet in the system F, the target finish time of the earliest-arriving EF packet in the system (undefined if Q=0) (seconds) E, the tolerance/error term (seconds) t, wall-clock time (seconds) As in previous discussions, a packet is deemed to have arrived when its last bit arrives and to have departed when its last bit is transmitted. If Q=0, then F is undefined. If Q=0 when an EF packet arrives at time t, then Q = 1 F = t + L/R If Q=1, an EF packet departs at time t, and an EF packet is in the queue, F = L/R + min(t, F) If an EF packet departs and the EF queue is empty, then Q = 0 We say that the scheduler is compliant with the EF PHB if the earliest-arriving EF packet in the system departs at time d and d <= F + E (Following Jon Bennett's suggestion, E can comprise a rate-dependent term and a rate-independent term to enable more useful advertisement of the scheduler's capability.) As in Kent's group's definition, the tolerance/error term is isolated from the target departure time, so the definition avoids creeping away from the ideal. Unlike that definition, the target departure time is not defined for each packet, so the accumulation of credit that Anna observed does not occur. The scheduler is neither rewarded for past better-than-ideal service, nor is it forgiven for past worse-than-ideal service (at least not until no more EF packets are in the system). Both of the unreasonably compliant behaviors you observed would be non-compliant under this definition. I believe that most commonly used schedulers (except perhaps VC, about which I know little) have finite tolerance/error terms with this definition. It seems that WRR, WFQ, and SCFQ have relatively large t/e terms, while PQ, TDM circuits, and WF2Q have relatively small ones. This would be appropriate, since we would like more "circuit-like" schedulers to have better advertised performance. I speculate that the t/e term will be closely related to the WFI of the scheduler whenever that metric can be applied, but that's just a conjecture. Further investigation is needed to such for hidden flaws. Provided that no one discovers a glaring flaw right off the bat (in which case I'll go into hiding for a while), I'd be glad to dig depper into things. Do you think that this definition holds any water? Bill ----- Original Message ----- From: Anna Charny To: Cc: ; Sent: Thursday, April 27, 2000 10:26 PM Subject: RE: [Diffserv] issues with RFC 2598 > Kent, > > Thanks for your comments. Yes, I am by now aware of the side effect of the > last definition I gave. While it does seem to allow all the known > scheduling implementations I have thought of that appear reasonable for EF, > it also allows a compliant scheduling sequence that gives only asymptotic > rate guarantees. > > The problem that we are facing appears to be that all the "simple" > definitions we have so far come up with > appear either to disallow many or some reasonable schedulers, or allow some > schedulers which appear to obviously > not be "good" for EF. > > We have discussed at length that the current definition in RFC 2598 does > not allow any schedulers at all. > A simple addition of the busy period allows some schedulers, but imposes > rate limitations that may be unnecessary. An addition of > a slack term allows all the WFQ-like schedulers, but still does not work > for purely delay-based schedulers. As mentioned above, and as your example > indicates, the definition based on the time to drain the queue at the right > rate (with the slack term) appears to allow the common reasonable > schedulers, but in addition allows the cases such as you give in your > example, where rate is guaranteed only asymptotically. > > Finally, your definition that you give below appears to have an unwanted > side effect of the virtual clock scheduler, which is that a flow that sends > more packets initially (and gets transmitted in the absence of competing > traffic) then can get punished later. For example, suppose > EF aggregate has configured rate 1/2 of the output link speed. Suppose at > time zero a 100 packets arrive, each from a separate input. Then, when > the F_i will be updated to account for all packets, it will set to 200T, > where T is the packet time at link speed. Suppose at time 101T a new > packet arrives from yet another link. Its finish time is then set to max > (101T, 200T)+2T, and its deadline is then 202T_g(E). > > Then the following scheduling sequence is compliant under your definition: > > send packets 1-100 back to back at times 1T,2T,3T...100T, then send packet > 101 at time 202T+g(E) > > So in the interval (101T, 202T+ g(E)) nothing is sent without violating > compliance, while the queue is continuously busy in that interval. > It seems that this is not what we want either... Would you agree? > > I have been talking to Jean-Yves Le Boudec about this problem. He is of the > opinion that the only way we could avoid these problems is to use the > definition based on service curves, as introduced by Cruz, and as used in > the Intserv context. We are still in the process of figuring out some > issues surrounding this. I am copying Jean-Yves directly in case he would > like to comment. > > In any case, it seems clear that either we should settle on a simple > definition that has some known drawbacks (e.g. allows some (perhaps not as > complete as we would like) set of known schedulers that seem reasonable for > EF implementation, and does not allow those which are obviously bad), or > the definition must be substantially more complicated than has been > originally envisioned. > > Regards, > Anna > > at 03:49 PM 4/27/00 -0500, Kent Benson wrote: > > >Anna, > > > >Thanks for your suggestions. We (my colleagues and I) aren't exactly sure > >what kinds of behavior RFC 2598 was trying to allow and what behaviors it > >was trying to forbid. One reasonable guess we had comes straight from the > >first two sentences in section 2 ("The EF PHB is defined as a forwarding > >treatment for a particular diffserv aggregate where the departure rate of > >the aggregate's packets from any diffserv node must equal or exceed a > >configurable rate. The EF traffic SHOULD receive this rate independent of > >the intensity of any other traffic attempting to transit the node."). One > >possible way of interpreting these sentences would be this: the EF aggregate > >should receive service equal to or greater than the service it would receive > >from a fluid flow server from which it receives a minimum service rate equal > >to some configured rate. (Note that the fluid flow server does not have to > >be a Fluid Flow Queuing Server (Generalized Processor Sharing Server). In > >fact, it does not even have to be work conserving.) The discussions on the > >list have shown that this requirement needs a phrase like "within some > >tolerance" added to it somewhere for two reasons. First, realizable > >schedulers cannot give service that is identical to a fluid flow server > >since they can only transmit one packet at a time. Thus, packets must often > >be sent earlier or later than their fluid flow finish times. Second, many > >routers are not purely output buffered and so cannot be modeled as a > >collection of independent multiplexers feeding output links. A tolerance > >would allow for multistage switch fabrics with multiple contention points. > > > >It looks like the conformance definition from your last e-mail can give some > >behavior that does not fit with the "fluid flow server" criterion above. > >This definition can be restated as follows (this makes the third or fourth > >restatement from various people I think). Assume EF packet P_i with length > >L_i arrives at time a_i. Letting Q(t) be the number of EF bits in a device > >at time t, P_i finds Q(a_i-) bits in the system. (Note that > >Q(a_i+)=Q(a_i-)+L_i.) We require d_i, the departure time of P_i (the time > >P_i actually leaves the system) to satisfy > > > >d_i<=a_i+[Q(a_i+)/R_c]+E > > > >where R_c is the EF configured rate and E is a tolerance/error term. > > > >Assume it takes time T to serve a packet of length L at rate R_c. A series > >of packets of length of L arrive at times 0, T, 2T, 3T, and so on. P_1 > >arrives at time 0, finds 0 EF bits in the system. Thus, > >d_1<=a_1+[Q(0+)/R_c]+E=0+[L/R_c]+E=T+E. If E is large enough such that P_2 > >arrives (at time T) before P_1 begins service (at time T+E-(L/C)) then P_2 > >could find L bits still in the system. Thus, the largest d_2 could be is > >T+[2L/R_c]+E=3T+E. Continuing, the worst case allowable behavior is > > > >Packet # 1 2 3 4 5 6 7 8 > >a_i 0 T 2T 3T 4T 5T 6T 7T > >d_i T+E 3T+E 4T+E 6T+E 7T+E 8T+E 10T+E 11T+E > > > >The possible departure times can creep away from the fluid flow server > >ideal. Obviously, if you pick a different EF criterion then this behavior > >might not be considered undesirable. > > > >Our restatement of the EF definition given above leads pretty directly to > >the following requirement: > > > >F_i=max{a_i,F_(i-1)}+(L_i/R_c) > > > >d_i<=F_i+g(E) > > > >where F_i is the finish time of packet i in a fluid flow server that gives > >the EF aggregate service of exactly R_c at all times, d_i is the time by > >which packet i must be sent by the actual system, and g(E) is some > >tolerance/error function. I split the function g(E) out from F_i so it > >can't loop back and accumulate in the finish times. > > > >This Virtual Clock-like criterion would allow most common schedulers such as > >WFQ, WF2Q, SCFQ, and strict priority. This requirement has its drawbacks, > >of course, but it is something to think about. > > > >Kent > > > > > > >-----Original Message----- > > >From: acharny@cisco.com [mailto:acharny@cisco.com] > > >Sent: Tuesday, April 18, 2000 2:29 AM > > >To: Kent.Benson@tellabs.com > > >Cc: diffserv@ietf.org > > >Subject: OOPS: CORRECTIONS TO PREVIOUS MESSAGE. RE: [Diffserv] issues > > >with RFC 2598 > > > > > > > > >Kent and Diffservers, > > > > > >The previous message I sent earlier tonight seems to have more > > >than one > > >problem. Please see corrections below. My apologies. > > >It's a late hour... > > > > > >Anna > > >=============================================================== > > >============= > > >=================== > > > > > > >Kent, > > > > > > >Thank you for bringing up this issue. I think the point you > > >are raising > > >is very valid. My attempt to retain as much of the wording of > > >the >current EF definition as possible caused this issue that I > > >overlooked. While the definitions I gave allow many > > >reasonable >schedulers/devices to be compliant, it still does > > >not cover > > >some reasonable cases such as you are describing. Since these are > > >indeed >both reasonable and useful cases, this issue needs to > > >be addressed. > > > > > > > > >At second glance the following attempt of a definition does > > >not seem right > > >at all. Aside from a misplaced parenthes, it looks like this > > >approach > > >does not accounts for a fixed delay in the box, At the moment > > >I cannot > > >figure out how to make it right. Please disregard it for now. > > > > > > >If I understand it correctly, a standard way of dealing > > >with the problem > > >you are describing would be to say that if at time 0 there is no > > >EF >traffic in the queue, then for any t>0 the amount of > > >traffic served by > > >the EF aggregate by time t must be at least min(A(t), tR_conf-E), > > >where >A(t) denotes the number of EF bits that arrived to the > > >queue in the > > >interval (0, t), R_conf is the configured rate of the EF > > >queue, and E is > > >the >error term (tolerance term) (in bits). > > > >A straightforward conformance test would then need to look > > >at intervals > > >of type (0, t) rather than at intervals of type (t1, t2). > > > > > >The following text has been corrected to fix a typo and to include the > > >length of the arriving packet that I previously forgot. > > >Otherwise it still appears to be correct. > > > > > > >Another way of addressing this issue might be to require that an EF > > >packet of length L entering a device at time t and finding Q EF bits > > >in >the device must leave the device no later than at time > > >t+E+(Q+L)/R_conf (where E is in units of time). It may be > > >convenient to > > > >split the error term into fixed and rate-proportional delay > > >similarly to > > >how it is done done in RFC 2212. Choosing E to cover the > > >fixed >delay > > >should fix your problem ( in your example the only cause of > > >the delay is > > >the fixed delay, but of course E should also account for >scheduling > > >errors, etc). > > > >A straightforward conformance test would now keep track of > > >the number of > > >bits still in the box at the time of arrival of a given packet > > >and >see if > > >its departure time conforms to the definition. > > > > > > > > > >It seems to me that these two definitions still capture the original > > >intent of EF definition, allows all of the schedulers that would be > > >allowed >under the two alternatives I previously suggested, > > >and also take > > >care of the issues you brought up. Certainly these also need to > > >be >scrutinized for unnoticed and unwanted side effects. At > > >the moment I do > > >not see any. > > > >Unfortunately, these are much farther away from the original > > >wording of > > >the EF definition. > > > >So I guess we now have 4 options to consider. It is not getting any > > >easier :-). > > > > > >Well, we are down to three now :-) > > > > > >Anna > > > > > > > > > > > > _______________________________________________ > diffserv mailing list > diffserv@ietf.org > http://www1.ietf.org/mailman/listinfo/diffserv > Archive: http://www-nrg.ee.lbl.gov/diff-serv-arch/ > _______________________________________________ diffserv mailing list diffserv@ietf.org http://www1.ietf.org/mailman/listinfo/diffserv Archive: http://www-nrg.ee.lbl.gov/diff-serv-arch/ From diffserv-admin@ietf.org Sun Apr 30 19:32:26 2000 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA05186; Sun, 30 Apr 2000 19:32:26 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id SAA04050; Sun, 30 Apr 2000 18:52:52 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id SAA04021 for ; Sun, 30 Apr 2000 18:52:48 -0400 (EDT) Received: from surya.csres.utexas.edu (surya.csres.utexas.edu [128.83.140.3]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA04863 for ; Sun, 30 Apr 2000 18:52:46 -0400 (EDT) Received: from mangal.csres.utexas.edu (mangal [128.83.140.7]) by surya.csres.utexas.edu (8.9.3+Sun/8.9.3) with ESMTP id RAA12260; Sun, 30 Apr 2000 17:52:46 -0500 (CDT) Received: (from pawang@localhost) by mangal.csres.utexas.edu (8.9.3+Sun/8.9.3) id RAA06543; Sun, 30 Apr 2000 17:52:44 -0500 (CDT) From: Pawan Goyal Message-Id: <200004302252.RAA06543@mangal.csres.utexas.edu> Subject: Re: [Diffserv] issues with RFC 2598 In-Reply-To: <000701bfb2e6$5e03e900$c5d82104@dsl.gtei.net> from Bill Courtney at "Apr 30, 0 01:55:06 pm" To: the.courtneys@gte.net (Bill Courtney) Date: Sun, 30 Apr 2000 17:52:43 -0500 (CDT) Cc: Kent.Benson@tellabs.com, acharny@cisco.com, diffserv@ietf.org X-Mailer: ELM [version 2.4ME+ PL39 (25)] 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 > Kent's group observed that a scheduler can benefit from an accumulation of > late delivery tolerances, causing the throughput to creep away from the > ideal fluid server. Anna observed that Kent's group's proposed separation > of tolerance/error from the target departure time can lead to a crediting of > the scheduler for past better-than-ideal service and to huge service > droughts. Yet, both of these behaviors would be compliant under the > respective proposed definitions. > > I think that the root of the problem with both unreasonably compliant > behaviors lies in the attempt to define a target departure time for a packet > when it arrives. If we consider the fairest packet scheduler that is known, > WF2Q, we see that it assigns a start and finish time not to each queued > packet, but rather to each queue. The excellent WFI that results is not > part of the algorithm or even a criterion that the algorithm must satisfy. > It is simply a description of the outcome of the algorithm's performance. > The assertion that WF2Q assigns a start and finish tag to each queue rather than each packet is incorrect. It can be shown that if a modification is made to assign start and finish tags to each queue rather than packet, then the fairness and delay properties of WF2Q no longer hold. Pawan _______________________________________________ diffserv mailing list diffserv@ietf.org http://www1.ietf.org/mailman/listinfo/diffserv Archive: http://www-nrg.ee.lbl.gov/diff-serv-arch/