From daemon@optimus.ietf.org Fri Jun 14 05:02:00 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA23234 for ; Fri, 14 Jun 2002 05:01:59 -0400 (EDT) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id FAA29066 for diffserv-interest-archive@odin.ietf.org; Fri, 14 Jun 2002 05:02: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 FAA29006; Fri, 14 Jun 2002 05:01:09 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id DAA26266 for ; Fri, 14 Jun 2002 03:54:45 -0400 (EDT) Received: from david.siemens.de (david.siemens.de [192.35.17.14]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA22490 for ; Fri, 14 Jun 2002 03:54:08 -0400 (EDT) Received: from mail1.siemens.de (mail1.siemens.de [139.23.33.14]) by david.siemens.de (8.11.6/8.11.6) with ESMTP id g5E7shC29579 for ; Fri, 14 Jun 2002 09:54:43 +0200 (MEST) Received: from mail-y.mchp.siemens.de (mail-y.mchp.siemens.de [139.23.203.56]) by mail1.siemens.de (8.11.6/8.11.6) with ESMTP id g5E7sgi04357 for ; Fri, 14 Jun 2002 09:54:43 +0200 (MEST) Received: from mchp.siemens.de (york [139.23.202.159]) by mail-y.mchp.siemens.de with ESMTP id g5E7sgVZ024154 for ; Fri, 14 Jun 2002 09:54:42 +0200 (MET DST) Message-ID: <3D09A142.12BEE0C8@mchp.siemens.de> Date: Fri, 14 Jun 2002 09:54:42 +0200 From: Nicolas Caudron X-Mailer: Mozilla 4.78 [en] (X11; U; SunOS 5.7 sun4u) X-Accept-Language: en MIME-Version: 1.0 To: diffserv-interest@ietf.org Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Subject: [Diffserv-interest] Diffserv for wireless networks Sender: diffserv-interest-admin@ietf.org Errors-To: diffserv-interest-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Differentiated services general discussion X-BeenThere: diffserv-interest@ietf.org Content-Transfer-Encoding: 7bit Hello, I would like to know if there is anybody who has already on the wireless networks worked with Diffserv in Network Simulator 2. I think that Diffserv in NS2 doesn't work with wireless networks so which modifications do I have to do to modify it for WLAN? Any help would be appreciated Nicolas _______________________________________________ Diffserv-interest mailing list Diffserv-interest@ietf.org https://www1.ietf.org/mailman/listinfo/diffserv-interest From daemon@optimus.ietf.org Fri Jun 14 08:25:29 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA26672 for ; Fri, 14 Jun 2002 08:25:29 -0400 (EDT) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id IAA08400 for diffserv-interest-archive@odin.ietf.org; Fri, 14 Jun 2002 08:26: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 IAA08340; Fri, 14 Jun 2002 08:25:37 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id IAA08311 for ; Fri, 14 Jun 2002 08:25:36 -0400 (EDT) Received: from loquat.bbn.com (crodrigues.bbn.com [128.89.72.49]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA26634 for ; Fri, 14 Jun 2002 08:24:58 -0400 (EDT) Received: (from crodrigu@localhost) by loquat.bbn.com (8.11.2/8.11.2) id g5ECOml18539; Fri, 14 Jun 2002 08:24:48 -0400 Date: Fri, 14 Jun 2002 08:24:48 -0400 From: Craig Rodrigues To: Nicolas Caudron Cc: diffserv-interest@ietf.org Subject: Re: [Diffserv-interest] Diffserv for wireless networks Message-ID: <20020614082448.A18534@bbn.com> References: <3D09A142.12BEE0C8@mchp.siemens.de> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: <3D09A142.12BEE0C8@mchp.siemens.de>; from nicolas.caudron@mchp.siemens.de on Fri, Jun 14, 2002 at 09:54:42AM +0200 Sender: diffserv-interest-admin@ietf.org Errors-To: diffserv-interest-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Differentiated services general discussion X-BeenThere: diffserv-interest@ietf.org On Fri, Jun 14, 2002 at 09:54:42AM +0200, Nicolas Caudron wrote: > Hello, > > I would like to know if there is anybody who has already on the wireless > networks worked with Diffserv in Network Simulator 2. I think that > Diffserv in NS2 doesn't work with wireless networks so which > modifications do I have to do to modify it for WLAN? > > Any help would be appreciated There was an article published in the May 2002 issue of IEEE Communications magazine: "DiffServ Resource Allocation for Fast Handoff in Wireless Mobile Internet", Yu Cheng and Weihua Zhuang , University of Waterloo. http://www.comsoc.org/livepubs/ci1/public/2002/may/index.html You may want to ask the authors of that article if they did any Diffserv experiments with NS-2 and wireless. -- Craig Rodrigues Distributed Systems and Logistics, Office 6/304 crodrigu@bbn.com BBN Technologies, a Verizon company (617) 873-4725 Cambridge, MA _______________________________________________ Diffserv-interest mailing list Diffserv-interest@ietf.org https://www1.ietf.org/mailman/listinfo/diffserv-interest From daemon@optimus.ietf.org Thu Jun 27 05:29:58 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA07343 for ; Thu, 27 Jun 2002 05:29:58 -0400 (EDT) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id FAA15568 for diffserv-interest-archive@odin.ietf.org; Thu, 27 Jun 2002 05:30: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 FAA15008; Thu, 27 Jun 2002 05:21: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 FAA14979 for ; Thu, 27 Jun 2002 05:21:48 -0400 (EDT) Received: from d12lmsgate.de.ibm.com (d12lmsgate.de.ibm.com [195.212.91.199]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA07222 for ; Thu, 27 Jun 2002 05:21:02 -0400 (EDT) Received: from d12relay02.de.ibm.com (d12relay02.de.ibm.com [9.165.215.23]) by d12lmsgate.de.ibm.com (8.12.3/8.12.3) with ESMTP id g5R9LDuA061658; Thu, 27 Jun 2002 11:21:14 +0200 Received: from etzel.zurich.ibm.com (etzel.zurich.ibm.com [9.4.64.140]) by d12relay02.de.ibm.com (8.11.1m3/NCO/VER6.1) with SMTP id g5R9LDZ73822; Thu, 27 Jun 2002 11:21:13 +0200 Received: from dhcp23-199.zurich.ibm.com by etzel.zurich.ibm.com (AIX 4.3/UCB 5.64/4.03) id AA54620 from ; Thu, 27 Jun 2002 11:21:12 +0200 Message-Id: <3D1AD93C.BF908433@hursley.ibm.com> Date: Thu, 27 Jun 2002 11:22:04 +0200 From: Brian E Carpenter Organization: IBM X-Mailer: Mozilla 4.79 [en] (Windows NT 5.0; U) X-Accept-Language: en,fr,de Mime-Version: 1.0 To: Dan Grossman Cc: Kathleen Nichols , diffserv-interest@ietf.org References: <3D0D2D77.656BEAF0@packetdesign.com> <29029742.1024958245@[192.168.102.207]> <3D178EAF.68DE503B@dma.isg.mot.com> <3D182076.813B1492@hursley.ibm.com> <3D18D5A3.88943D48@dma.isg.mot.com> <3D19A7B6.A291F710@hursley.ibm.com> <3D19F179.1040507@packetdesign.com> <3D1A027F.18D9711B@dma.isg.mot.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Subject: [Diffserv-interest] Re: [Diffserv] Hard questions (was: Diffserv PIB approved as InformationalRFC) Sender: diffserv-interest-admin@ietf.org Errors-To: diffserv-interest-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Differentiated services general discussion X-BeenThere: diffserv-interest@ietf.org Content-Transfer-Encoding: 7bit [also switched to differv-interest] Dan Grossman wrote: ... > Sometimes it best to just lock down the path and accept the possibility of a hard failure to meet the > SLS, than to have the SLS fail to be met in a transient fashion. And sometimes it isn't. This sounds like a decision that will be taken by individual operators, like many other traffic engineering decisions. I doubt if there's much to be said in general about this. It seems to argue that traffic engineering tools need to have DSCP value as a parameter, for operators that want to pin routes per DSCP. Brian _______________________________________________ Diffserv-interest mailing list Diffserv-interest@ietf.org https://www1.ietf.org/mailman/listinfo/diffserv-interest From daemon@optimus.ietf.org Thu Jun 27 07:08:12 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA10909 for ; Thu, 27 Jun 2002 07:08:12 -0400 (EDT) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id HAA23377 for diffserv-interest-archive@odin.ietf.org; Thu, 27 Jun 2002 07:08:56 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id HAA23305; Thu, 27 Jun 2002 07:08:22 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id GAA20884 for ; Thu, 27 Jun 2002 06:43:57 -0400 (EDT) Received: from iere.net.avaya.com (iere.net.avaya.com [198.152.12.101]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA09951 for ; Thu, 27 Jun 2002 06:43:13 -0400 (EDT) Received: from iere.net.avaya.com (localhost [127.0.0.1]) by iere.net.avaya.com (8.11.2/8.9.3) with ESMTP id g5RAg0411113 for ; Thu, 27 Jun 2002 06:42:00 -0400 (EDT) Received: from IS0004AVEXU1.global.avaya.com (h135-64-105-51.avaya.com [135.64.105.51]) by iere.net.avaya.com (8.11.2/8.9.3) with ESMTP id g5RAfxF11104 for ; Thu, 27 Jun 2002 06:41:59 -0400 (EDT) X-MimeOLE: Produced By Microsoft Exchange V6.0.5762.3 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C21DC7.87B13495" Date: Thu, 27 Jun 2002 13:43:53 +0300 Message-ID: Thread-Topic: Admission Control In DiffServ Thread-Index: AcIdx2ZGmuIITYpBQfm7M4YUEg8xWw== From: "Ashkenazi, Liat (Liat)" To: Subject: [Diffserv-interest] Admission Control In DiffServ Sender: diffserv-interest-admin@ietf.org Errors-To: diffserv-interest-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Differentiated services general discussion X-BeenThere: diffserv-interest@ietf.org This is a multi-part message in MIME format. ------_=_NextPart_001_01C21DC7.87B13495 Content-Type: text/plain; charset="windows-1255" Content-Transfer-Encoding: quoted-printable Hello! I'm investigating the DiffServ Issue. I don=92t understand how we can do admission control in DiffServ? How the administrator can know the condition of the network (is it = loaded or available to get another =93call=94)? In ATM for example we know that the administrator check for each = =93call=94 if there is enough bandwidth and decide by advance the end to = end path. How it works in DiffServ? Is there relation between the admission control and the routing = algorithm? Thank You, Liat Ashkenazi. lashkena@avaya.com ------_=_NextPart_001_01C21DC7.87B13495 Content-Type: text/html; charset="windows-1255" Content-Transfer-Encoding: quoted-printable Admission Control In DiffServ

Hello!

I'm = investigating the DiffServ Issue.

I = don=92t understand how we can do admission control in = DiffServ?

How the = administrator can know the condition of the network (is it loaded or = available to get another =93call=94)?

In ATM = for example we know that the administrator check for each =93call=94 if = there is enough bandwidth and decide by advance the end to end = path.

How it = works in DiffServ?

Is there = relation between the admission control and the routing = algorithm?

Thank = You, Liat Ashkenazi.

lashkena@avaya.com

------_=_NextPart_001_01C21DC7.87B13495-- _______________________________________________ Diffserv-interest mailing list Diffserv-interest@ietf.org https://www1.ietf.org/mailman/listinfo/diffserv-interest From daemon@optimus.ietf.org Thu Jun 27 08:04:31 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA13284 for ; Thu, 27 Jun 2002 08:04:30 -0400 (EDT) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id IAA28326 for diffserv-interest-archive@odin.ietf.org; Thu, 27 Jun 2002 08:05: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 IAA28264; Thu, 27 Jun 2002 08:04:39 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id IAA28235 for ; Thu, 27 Jun 2002 08:04:37 -0400 (EDT) Received: from d12lmsgate-2.de.ibm.com (d12lmsgate-2.de.ibm.com [195.212.91.200]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA13200 for ; Thu, 27 Jun 2002 08:03:52 -0400 (EDT) Received: from d12relay02.de.ibm.com (d12relay02.de.ibm.com [9.165.215.23]) by d12lmsgate-2.de.ibm.com (8.12.3/8.12.3) with ESMTP id g5RC43IU068518; Thu, 27 Jun 2002 14:04:03 +0200 Received: from etzel.zurich.ibm.com (etzel.zurich.ibm.com [9.4.64.140]) by d12relay02.de.ibm.com (8.11.1m3/NCO/VER6.1) with SMTP id g5RC42Z44456; Thu, 27 Jun 2002 14:04:02 +0200 Received: from dhcp222-70.zurich.ibm.com by etzel.zurich.ibm.com (AIX 4.3/UCB 5.64/4.03) id AA59514 from ; Thu, 27 Jun 2002 14:04:02 +0200 Message-Id: <3D1AFF66.53D90515@hursley.ibm.com> Date: Thu, 27 Jun 2002 14:04:54 +0200 From: Brian E Carpenter Organization: IBM X-Mailer: Mozilla 4.79 [en] (Windows NT 5.0; U) X-Accept-Language: en,fr,de Mime-Version: 1.0 To: "Ashkenazi, Liat (Liat)" Cc: diffserv-interest@ietf.org Subject: Re: [Diffserv-interest] Admission Control In DiffServ References: Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by optimus.ietf.org id IAA28236 Sender: diffserv-interest-admin@ietf.org Errors-To: diffserv-interest-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Differentiated services general discussion X-BeenThere: diffserv-interest@ietf.org Content-Transfer-Encoding: 8bit Diffserv does not deal with individual "calls". Traffic entering a given behaviour aggregate may be policed at the ingress router, if the particular PHB requires policing. That is as close as we get to admission control in the architecture. Beyond that, it gets philiosphical. Some people believe we should go further, and extend the diffserv model to handle "calls"... but that's exactly why we invented diffserv, to get away from the "call" nature of intserv, which doesn't scale. To some extent, RFC 2998 achieves intserv/diffserv integration, and that is perhaps the best answer to your question today. The NSIS working group may produce another answer (see the current dialogue under the "hard questions" subject). Brian > "Ashkenazi, Liat (Liat)" wrote: > > Hello! > > I'm investigating the DiffServ Issue. > > I don’t understand how we can do admission control in DiffServ? > > How the administrator can know the condition of the network (is it loaded or available to get another “call”)? > > In ATM for example we know that the administrator check for each “call” if there is enough bandwidth and decide by advance the > end to end path. > > How it works in DiffServ? > > Is there relation between the admission control and the routing algorithm? > > Thank You, Liat Ashkenazi. > > lashkena@avaya.com -- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - Brian E Carpenter Distinguished Engineer, Internet Standards & Technology, IBM On assignment at the IBM Zurich Laboratory, Switzerland _______________________________________________ Diffserv-interest mailing list Diffserv-interest@ietf.org https://www1.ietf.org/mailman/listinfo/diffserv-interest From daemon@optimus.ietf.org Thu Jun 27 08:28:17 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA14216 for ; Thu, 27 Jun 2002 08:28:17 -0400 (EDT) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id IAA29837 for diffserv-interest-archive@odin.ietf.org; Thu, 27 Jun 2002 08:29: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 IAA29756; Thu, 27 Jun 2002 08:27: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 IAA29725 for ; Thu, 27 Jun 2002 08:27:36 -0400 (EDT) Received: from d12lmsgate-2.de.ibm.com (d12lmsgate-2.de.ibm.com [195.212.91.200]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA14154 for ; Thu, 27 Jun 2002 08:26:50 -0400 (EDT) Received: from d12relay01.de.ibm.com (d12relay01.de.ibm.com [9.165.215.22]) by d12lmsgate-2.de.ibm.com (8.12.3/8.12.3) with ESMTP id g5R9Ci5H068312; Thu, 27 Jun 2002 11:12:53 +0200 Received: from etzel.zurich.ibm.com (etzel.zurich.ibm.com [9.4.64.140]) by d12relay01.de.ibm.com (8.11.1m3/NCO/VER6.1) with SMTP id g5R9CZa48250; Thu, 27 Jun 2002 11:12:36 +0200 Received: from dhcp23-199.zurich.ibm.com by etzel.zurich.ibm.com (AIX 4.3/UCB 5.64/4.03) id AA36550 from ; Thu, 27 Jun 2002 11:12:29 +0200 Message-Id: <3D1AD731.7957F7B7@hursley.ibm.com> Date: Thu, 27 Jun 2002 11:13:21 +0200 From: Brian E Carpenter Organization: IBM X-Mailer: Mozilla 4.79 [en] (Windows NT 5.0; U) X-Accept-Language: en,fr,de Mime-Version: 1.0 To: Dan Grossman Cc: brunner@ccrle.nec.de, Kathleen Nichols , diffserv-interest@ietf.org References: <3D0D2D77.656BEAF0@packetdesign.com> <29029742.1024958245@[192.168.102.207]> <3D178EAF.68DE503B@dma.isg.mot.com> <3D182076.813B1492@hursley.ibm.com> <3D18D5A3.88943D48@dma.isg.mot.com> <3D19A7B6.A291F710@hursley.ibm.com> <3D19E347.7848A18B@dma.isg.mot.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Subject: [Diffserv-interest] Re: [Diffserv] Hard questions (was: Diffserv PIB approved as Informational RFC) Sender: diffserv-interest-admin@ietf.org Errors-To: diffserv-interest-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Differentiated services general discussion X-BeenThere: diffserv-interest@ietf.org Content-Transfer-Encoding: 7bit [switched to diffserv-interest] Dan Grossman wrote: > > Brian E Carpenter wrote: > > > > > > > > We may be disagreeing about the exact boundary between technical and business issues - but > > see my earlier comment on Mai Trang's note - I agree there is scope for some signalling work. > > I don't know which trade association - all I know is that the IETF isn't suitable for the > > discussion of business practices. > > I'm sorry to be blunt, but this is a red herring. Nobody is proposing to talk about business > practices. The IETF and other bodies have been producing service definitions for years without having > to get into business practices (c.f., the aforementioned RFC 2211 and 2212). The Diffserv working > group nonetheless chose to perform some interesting semantic contortions to avoid any perception that > it might be working on business practices. Nobody is proposing that we should. The problem remains: > in order to have anything other than best effort services in the Internet, > end-to-end/end-to-edge/edge-to-edge behaviors must be defined and the mechanisms to support them -- > including between adminstrative domains -- specified. We added an item to the WG charter to do that, > and then failed to do so. Well, we defined what a PDB is, but then we discovered the lack of both mathematical and experimental understanding of how to characterise PDBs, and we still haven't made much progress on that. That's why we haven't seen any PDBs yet that are ripe for publication. See below for some comments on end2end. > > > > > > > > > > > > > > > > > > > > > > > > > > There may be some cause for hope that the NSIS work will ultimately provide much of the > > > > > needed mechanism to allow capacity reservation. > > > > > > > > You're begging the question of whether that is an appropriate mechanism for the Internet. > > > > > > I believe that that is in NSIS' charter. And in any event, this is a tired debate. There is a > > > significant portion of the community (not necessarily tier-1 ISPs) that does believe in bandwidth > > > reservations to support telephony and multimedia services. > > > > Yes, there is. That's exactly what I mean. But I don't think this list is the place > > to debate it. As you say, if it is an IETF issue it's over in NSIS. > > I partially agree, but think that it is necessary that the collective experience of the WG be drawn in > to that discussion. In particular, the framework draft, which exposed a number of what are now NSIS > issues, has long since expired. Memories of people on this list may be needed to inform the > discussion in NSIS. That should certainly happen. But frankly the framework draft was highly speculative and the lack of math or experiment still keeps us in speculation mode. > > > > > > > > > > > > mechanisms to > > > > > manage DSCP mappings between DS domains, > > > > > > > > Again, trade association work. > > > > > > So RFC2836 (which is necessary but not sufficient to the solution to the problem) should have > > > been done by a trade association? Again, I'm mildly hopeful that the NSIS protocol(s) will > > > prove helpful in this regard. > > > > No, what I meant is that before we can invent a technical solution we need to > > have some idea of the requirements, and those are currently hidden in secret bilateral > > agreements. > > Bilateral agreements don't scale. Actually, I think they do. They scale like o(N) where N is the number of ISPs that a given ISP is connected to, and that is quite tractable. What they don't do is associate (in the mathematical sense)- concatenated bilats don't create a multilat. That's where constructing e2e behaviours gets difficult. I believe that we also don't understand yet whether PDBs are associative. That's why the whole question of end2end is still open. > > > You're also assuming that some sort of dynamic mechanism is needed; my > > assumption is that static mechanisms will suffice initially, for which no > > signaling is needed. > > Static mechanisms don't scale. Again, I think they do. In fact, if a given ISP (or enterprise network) operates a few (3 or 4) classes of service, they can have a pretty much standard and invariant router config in a central management database; the incremental config for diffserv will be pretty small. If you try to run a very large number of classes or do dynamic resource allocation, things don't scale (and you certainly need signalling). My concern is that this topic isn't well enough understood yet for committee work. > > > > > . > > > > > > Unfortunately, none of the Diffserv RFCs are Experimental, which says that the group claims a > > > degree of maturity for them. Equally unfortunately, they are at best necessary but not > > > sufficient to actually providing useful services, even within a Diffserv domain, much less > > > between domains. Worse, there is a perception -- which neither the Diffserv working group nor > > > the IESG has acted to counter -- that they actually are sufficient to do anything useful. This, > > > IMHO, has been a disservice to the community. > > > > Diffserv is only now getting shipped and we only recently finalised the MIB and PIB. > > I think it's way too soon to make judgements about usefulness, but if you want a > > statement of my belief, it's this: We have done what we set out to do, i.e. define > > mechanisms for simple, stateless, scaleable, manageable class-of-service support > > that require only static configuration and no signaling. This is entirely deployable > > as-is by ISPs and enterprises that want to provide simple service differentiation > > I think we can debate simple, scaleable and manageable. I frankly think that with all the issues, > there are grave doubts that it is deployable, but we shall see. I do note that routers have been > shipping for at least two years that claim to do Diffserv, yet we don't see broad scale deployment. True, but it's only now that we have a MIB and begin to see operating systems capable of classifying traffic at source. I think enterprise networks will be the first to adopt diffserv, and I think it will be a stealth technology in ISPs - there is no reason you will know it's there, as with any other traffic engineering mechanisms. > And finally, the folks in the wireless and cable industries who think they see a use for Diffserv > aren't thinking simple service differentiation... they're thinking telephony and multimedia. Indeed. And I think this is where we are seeing people most keen on adding signalling and per-flow handling. I don't fully understand this, because telephone systems have always been provisioned on a 0.1 or 0.2 Erlang basis, and I don't fully understand why VoIP or multimedia over IP can't be statistically provisioned too. It's exactly at busy hour that you need diffserv, so if you provision the traffic aggregate for VoIP for the busy hour, it's hard to see how signalling and dynamic allocation will create bandwidth out of thin air. There is a tricky issue of how you deal with land line or base station outages, or with extreme hot spots (emergency situations or traffic jams) but we should be able to solve that at an aggregate level, not per-call. So my conclusion is that the telephony community in particular is over-constraining the solution by sticking with notions of per-call QOS. > > > . > > > > For what lies beyond that, see RFC 2990. I agree that we've made little progress > > on the issues raised in that document, but that doesn't prevent deployment of > > diffserv in its intended (very simple) role. > > Where do we say that's what we intended? Honestly, if the intent is only "simple service > differentiation", then a Diffserv applicability statement is needed to state this, because that's not > what some elements of the community expect. I'm thinking back to the BOF in April 1997 and the early meetings where the diffserv direction was set. The diffserv charter starts: There is a clear need for relatively simple and coarse methods of providing differentiated classes of service for Internet traffic, to support various types of applications, and specific business requirements. and I believe this text has been there from the beginning; it was certainly there in February 1998 from my records. Also, RFC 2474 starts by saying: Differentiated services enhancements to the Internet protocol are intended to enable scalable service discrimination in the Internet without the need for per-flow state and signaling at every hop. (That carefully doesn't exclude state and signalling totally, but there is nothing in 2474 or 2475 that implies either flow state or signalling.) So what can we say in an applicability statement in addition to "read the Abstract of RFC 2474"? > > > > > > > OK, enough philosophy for this mailing list. People who believe that NSIS is not doing > > everything necessary should write to NSIS or to the Transport Area Directors. > > I believe this is the Diffserv standardization list. This discussion relates directly to the work of > the Diffserv WG and the history, current state and future needs of Diffserv standardization. I also > assume that the Transport ADs are listening and hope they'll appreciate the concerns raised. > > But I do need to send a few words to the NSIS list concerning their requirments draft, as well. Certainly, because if NSIS does produce a new protocol, it needs to be able to handle whatever we discover about dynamic resource allocation for diffserv in the future. Brian _______________________________________________ Diffserv-interest mailing list Diffserv-interest@ietf.org https://www1.ietf.org/mailman/listinfo/diffserv-interest From daemon@optimus.ietf.org Thu Jun 27 09:33:25 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA17665 for ; Thu, 27 Jun 2002 09:33:25 -0400 (EDT) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id JAA05985 for diffserv-interest-archive@odin.ietf.org; Thu, 27 Jun 2002 09:34: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 JAA05772; Thu, 27 Jun 2002 09:32: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 JAA05742 for ; Thu, 27 Jun 2002 09:32:14 -0400 (EDT) Received: from catete.gta.ufrj.br (catete.gta.ufrj.br [146.164.69.21]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA17492 for ; Thu, 27 Jun 2002 09:31:29 -0400 (EDT) Received: from localhost (vaz@localhost) by catete.gta.ufrj.br (8.11.6/8.11.6) with ESMTP id g5RDOgG02390; Thu, 27 Jun 2002 10:24:42 -0300 X-Authentication-Warning: catete.gta.ufrj.br: vaz owned process doing -bs Date: Thu, 27 Jun 2002 10:24:42 -0300 (BRT) From: Saulo Vaz de Vasconcellos To: "Ashkenazi, Liat (Liat)" cc: Subject: Re: [Diffserv-interest] Admission Control In DiffServ In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=ISO-8859-1 Content-Transfer-Encoding: 8BIT Content-Transfer-Encoding: 8BIT Sender: diffserv-interest-admin@ietf.org Errors-To: diffserv-interest-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Differentiated services general discussion X-BeenThere: diffserv-interest@ietf.org Content-Transfer-Encoding: 8BIT Hi, In the DiffServ, the Admission control may be performed in a pacet basis (in this case, called traffic control), or in a per call basis, but in this last case one must have information about the domain's load in order to admit or reject a call. There exists some frameworks to do a centralizad admission control, based in bandwith brokers or a central "oracle" (who knows the entire domain and the routes) and some distributed AC, based on new protoclos, like the RMD framework (the signalling messages flows the same path as the data). There are also some proposes using probe based AC in AF. Yours, Saulo On Thu, 27 Jun 2002, Ashkenazi, Liat (Liat) wrote: > Hello! > > I'm investigating the DiffServ Issue. > I don’t understand how we can do admission control in DiffServ? > How the administrator can know the condition of the network (is it loaded or available to get another “call”)? > In ATM for example we know that the administrator check for each “call” if there is enough bandwidth and decide by advance the end to end path. > How it works in DiffServ? > Is there relation between the admission control and the routing algorithm? > > Thank You, Liat Ashkenazi. > lashkena@avaya.com > > -- Saulo Vaz de Vasconcellos MSc. Student - GTA/COPPE - Brazil tel: +55 21 2260-5010 ext. 240 http://www.gta.ufrj.br/~vaz _______________________________________________ Diffserv-interest mailing list Diffserv-interest@ietf.org https://www1.ietf.org/mailman/listinfo/diffserv-interest From daemon@optimus.ietf.org Thu Jun 27 11:12:20 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA22847 for ; Thu, 27 Jun 2002 11:12:20 -0400 (EDT) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id LAA14865 for diffserv-interest-archive@odin.ietf.org; Thu, 27 Jun 2002 11:13: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 LAA14716; Thu, 27 Jun 2002 11:11: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 LAA14688 for ; Thu, 27 Jun 2002 11:11:34 -0400 (EDT) Received: from d12lmsgate-3.de.ibm.com (d12lmsgate-3.de.ibm.com [195.212.91.201]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA22723 for ; Thu, 27 Jun 2002 11:10:48 -0400 (EDT) Received: from d12relay01.de.ibm.com (d12relay01.de.ibm.com [9.165.215.22]) by d12lmsgate-3.de.ibm.com (8.12.3/8.12.3) with ESMTP id g5RFAv2F027340; Thu, 27 Jun 2002 17:10:58 +0200 Received: from etzel.zurich.ibm.com (etzel.zurich.ibm.com [9.4.64.140]) by d12relay01.de.ibm.com (8.11.1m3/NCO/VER6.1) with SMTP id g5RFAua82960; Thu, 27 Jun 2002 17:10:56 +0200 Received: from dhcp23-199.zurich.ibm.com by etzel.zurich.ibm.com (AIX 4.3/UCB 5.64/4.03) id AA48202 from ; Thu, 27 Jun 2002 17:10:55 +0200 Message-Id: <3D1B2B33.D6F56D18@hursley.ibm.com> Date: Thu, 27 Jun 2002 17:11:47 +0200 From: Brian E Carpenter Organization: IBM X-Mailer: Mozilla 4.79 [en] (Windows NT 5.0; U) X-Accept-Language: en,fr,de Mime-Version: 1.0 To: iokumus@mailbox.syr.edu Cc: "Ashkenazi, Liat (Liat)" , diffserv-interest@ietf.org References: Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by optimus.ietf.org id LAA14689 Subject: [Diffserv-interest] Re: [Diffserv] Admission Control In DiffServ Sender: diffserv-interest-admin@ietf.org Errors-To: diffserv-interest-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Differentiated services general discussion X-BeenThere: diffserv-interest@ietf.org Content-Transfer-Encoding: 8bit iokumus@mailbox.syr.edu wrote: > > Hi Liat, > In diffserv Bandwidth Brokers(BB) are responsible for admission control > and related issues. Not true. That is simply one possible model, and there are no BB standards to my knowledge. > Every diffserv domain will have a BB Not true. DS domains do not require a BB. Regular ingress routers can perform admission control if it's needed. > and these BBs > talk to each other in order to support the inter-domain traffic. BBs are > responsible for admission control, resource allocation and provisioning > etc. BBs are centralized agents That's one model. I've seen talk of federated BBs. Brian > and requests are forwarded to BBs to let > it decide whether resources are available to support the request. > Hope this helps. > > _______________________________ > Ibrahim Taner OKUMUS > Electrical&Computer Eng. Dept. > Syracuse University > Syracuse New York > _______________________________ > > On Thu, 27 Jun 2002, Ashkenazi, Liat (Liat) wrote: > > > Hello! > > > > I'm investigating the DiffServ Issue. > > I don’t understand how we can do admission control in DiffServ? > > How the administrator can know the condition of the network (is it loaded or available to get another “call”)? > > In ATM for example we know that the administrator check for each “call” if there is enough bandwidth and decide by advance the end to end path. > > How it works in DiffServ? > > Is there relation between the admission control and the routing algorithm? > > > > Thank You, Liat Ashkenazi. > > lashkena@avaya.com > > > > > > > > _______________________________________________ > diffserv mailing list > diffserv@ietf.org > https://www1.ietf.org/mailman/listinfo/diffserv > Archive: http://www.ietf.org/mail-archive/working-groups/diffserv/current/maillist.html -- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - Brian E Carpenter Distinguished Engineer, Internet Standards & Technology, IBM On assignment at the IBM Zurich Laboratory, Switzerland _______________________________________________ Diffserv-interest mailing list Diffserv-interest@ietf.org https://www1.ietf.org/mailman/listinfo/diffserv-interest From daemon@optimus.ietf.org Thu Jun 27 11:37:32 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA24852 for ; Thu, 27 Jun 2002 11:37:32 -0400 (EDT) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id LAA18625 for diffserv-interest-archive@odin.ietf.org; Thu, 27 Jun 2002 11:38: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 LAA17372; Thu, 27 Jun 2002 11:30: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 LAA17330 for ; Thu, 27 Jun 2002 11:30:53 -0400 (EDT) Received: from mailer.syr.edu (mailer.syr.edu [128.230.18.29]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA24353 for ; Thu, 27 Jun 2002 11:30:08 -0400 (EDT) From: iokumus@mailbox.syr.edu Received: from rodan.syr.edu by mailer.syr.edu (LSMTP for Windows NT v1.1b) with SMTP id <0.009F2C4C@mailer.syr.edu>; Thu, 27 Jun 2002 11:30:28 -0400 Received: from localhost (iokumus@localhost) by rodan.syr.edu (8.8.7/8.8.7) with ESMTP id LAA13673; Thu, 27 Jun 2002 11:30:27 -0400 (EDT) X-Authentication-Warning: rodan.syr.edu: iokumus owned process doing -bs Date: Thu, 27 Jun 2002 11:30:27 -0400 (EDT) X-Sender: iokumus@rodan.syr.edu To: Brian E Carpenter cc: "Ashkenazi, Liat (Liat)" , diffserv-interest@ietf.org In-Reply-To: <3D1B2B33.D6F56D18@hursley.ibm.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=X-UNKNOWN Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from QUOTED-PRINTABLE to 8bit by optimus.ietf.org id LAA17334 Subject: [Diffserv-interest] Re: [Diffserv] Admission Control In DiffServ Sender: diffserv-interest-admin@ietf.org Errors-To: diffserv-interest-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Differentiated services general discussion X-BeenThere: diffserv-interest@ietf.org Content-Transfer-Encoding: 8bit > > Hi Liat, > > In diffserv Bandwidth Brokers(BB) are responsible for admission control > > and related issues. > > Not true. That is simply one possible model, and there are no BB standards > to my knowledge. That's correct, this is one possible model, but I am not aware of any other model that has BB capabilities. > > > Every diffserv domain will have a BB > > Not true. DS domains do not require a BB. Regular ingress routers can > perform admission control if it's needed. Again this is a feature of the model. Regular ingress routers can perform admission control, but how do we handle dynamic SLAs between DS domains? BB model also has this capability. > > > and these BBs > > talk to each other in order to support the inter-domain traffic. BBs are > > responsible for admission control, resource allocation and provisioning > > etc. BBs are centralized agents > > That's one model. I've seen talk of federated BBs. BBs are centralized agents. You can use them in a hierarchy, but every domain has a single BB representing that domain and contacts only with a single representing BB in another domain. Large domains can have areas and BBs can manage those areas in a hierarchical order. You can think of this as an extanded use of centralized BB notion. > > Brian > > > and requests are forwarded to BBs to let > > it decide whether resources are available to support the request. > > Hope this helps. > > > > _______________________________ > > Ibrahim Taner OKUMUS > > Electrical&Computer Eng. Dept. > > Syracuse University > > Syracuse New York > > _______________________________ > > > > On Thu, 27 Jun 2002, Ashkenazi, Liat (Liat) wrote: > > > > > Hello! > > > > > > I'm investigating the DiffServ Issue. > > > I don’t understand how we can do admission control in DiffServ? > > > How the administrator can know the condition of the network (is it loaded or available to get another “call”)? > > > In ATM for example we know that the administrator check for each “call” if there is enough bandwidth and decide by advance the end to end path. > > > How it works in DiffServ? > > > Is there relation between the admission control and the routing algorithm? > > > > > > Thank You, Liat Ashkenazi. > > > lashkena@avaya.com > > > > > > > > > > > > > _______________________________________________ > > diffserv mailing list > > diffserv@ietf.org > > https://www1.ietf.org/mailman/listinfo/diffserv > > Archive: http://www.ietf.org/mail-archive/working-groups/diffserv/current/maillist.html > > -- > - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - > Brian E Carpenter > Distinguished Engineer, Internet Standards & Technology, IBM > On assignment at the IBM Zurich Laboratory, Switzerland > _______________________________________________ Diffserv-interest mailing list Diffserv-interest@ietf.org https://www1.ietf.org/mailman/listinfo/diffserv-interest From daemon@ns.ietf.org Thu Jun 27 16:01:22 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA12951 for ; Thu, 27 Jun 2002 16:01:21 -0400 (EDT) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id QAA18247 for diffserv-interest-archive@odin.ietf.org; Thu, 27 Jun 2002 16:02: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 QAA18117; Thu, 27 Jun 2002 16:01: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 QAA18072 for ; Thu, 27 Jun 2002 16:01:25 -0400 (EDT) Received: from tokyo.ccrle.nec.de (tokyo.ccrle.nec.de [195.37.70.2]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA12899 for ; Thu, 27 Jun 2002 16:00:39 -0400 (EDT) Received: from wallace.heidelberg.ccrle.nec.de (root@wallace.heidelberg.ccrle.nec.de [192.168.102.1]) by tokyo.ccrle.nec.de (8.11.6/8.11.6) with ESMTP id g5RJxcK36812; Thu, 27 Jun 2002 21:59:38 +0200 (CEST) (envelope-from brunner@ccrle.nec.de) Received: from imap.heidelberg.ccrle.nec.de (imap.heidelberg.ccrle.nec.de [192.168.102.11]) by wallace.heidelberg.ccrle.nec.de (8.9.3/8.9.3/SuSE Linux 8.9.3-0.1) with ESMTP id VAA26933; Thu, 27 Jun 2002 21:54:26 +0200 Received: from [192.168.102.207] (marcus.heidelberg.ccrle.nec.de [192.168.102.207]) by imap.heidelberg.ccrle.nec.de (Postfix on SuSE Linux eMail Server 3.0) with ESMTP id 17AA84E282; Thu, 27 Jun 2002 21:54:25 +0200 (CEST) Date: Thu, 27 Jun 2002 21:54:25 +0200 From: Marcus Brunner Reply-To: brunner@ccrle.nec.de To: Kathleen Nichols , Dan Grossman , diffserv-interest@ietf.org, Brian E Carpenter Message-ID: <37268849.1025214865@[192.168.102.207]> In-Reply-To: <3D19F179.1040507@packetdesign.com> References: <3D19F179.1040507@packetdesign.com> X-Mailer: Mulberry/2.2.0 (Win32) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline Content-Transfer-Encoding: 7bit Subject: [Diffserv-interest] Re: [Diffserv] Hard questions (was: Diffserv PIB approved as Informational RFC) Sender: diffserv-interest-admin@ietf.org Errors-To: diffserv-interest-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Differentiated services general discussion X-BeenThere: diffserv-interest@ietf.org Content-Transfer-Encoding: 7bit [switched to diffserv-interest] > By the way, using diffserv for cable data networks and wireless > networks is rather different than using diffserv for a more > mesh-y network cloud. What those folks are actually doing is > creating PDBs that apply across their very specific network > topologies. We define also PDBs but with our very specific DiffServ implementation by fixing quite a number of parameters before even think about a PDB. We found that the openness of the DiffServ specs are a hindrence in defining crisp PDBs, therefore we can only do propriatary ones, and these are complicated and not very crisp as well. Marcus -------------------------------------- Dr. Marcus Brunner Network Laboratories NEC Europe Ltd. E-Mail: brunner@ccrle.nec.de WWW: http://www.ccrle.nec.de/ personal home page: http://www.brubers.org/marcus _______________________________________________ Diffserv-interest mailing list Diffserv-interest@ietf.org https://www1.ietf.org/mailman/listinfo/diffserv-interest From daemon@optimus.ietf.org Fri Jun 28 07:39:53 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA20761 for ; Fri, 28 Jun 2002 07:39:53 -0400 (EDT) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id HAA17983 for diffserv-interest-archive@odin.ietf.org; Fri, 28 Jun 2002 07:40: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 HAA17921; Fri, 28 Jun 2002 07:40: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 HAA17890 for ; Fri, 28 Jun 2002 07:40:00 -0400 (EDT) Received: from d12lmsgate-3.de.ibm.com (d12lmsgate-3.de.ibm.com [195.212.91.201]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA20712 for ; Fri, 28 Jun 2002 07:39:14 -0400 (EDT) Received: from d12relay02.de.ibm.com (d12relay02.de.ibm.com [9.165.215.23]) by d12lmsgate-3.de.ibm.com (8.12.3/8.12.3) with ESMTP id g5SBdP2F050462; Fri, 28 Jun 2002 13:39:25 +0200 Received: from etzel.zurich.ibm.com (etzel.zurich.ibm.com [9.4.64.140]) by d12relay02.de.ibm.com (8.11.1m3/NCO/VER6.1) with SMTP id g5SBdOu109696; Fri, 28 Jun 2002 13:39:25 +0200 Received: from dhcp23-199.zurich.ibm.com by etzel.zurich.ibm.com (AIX 4.3/UCB 5.64/4.03) id AA61512 from ; Fri, 28 Jun 2002 13:39:24 +0200 Message-Id: <3D1C4B20.CA6E2892@hursley.ibm.com> Date: Fri, 28 Jun 2002 13:40:16 +0200 From: Brian E Carpenter Organization: IBM X-Mailer: Mozilla 4.79 [en] (Windows NT 5.0; U) X-Accept-Language: en,fr,de Mime-Version: 1.0 To: "Ashkenazi, Liat (Liat)" Cc: diffserv interest Subject: Re: [Diffserv-interest] Admission Control In DiffServ References: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: diffserv-interest-admin@ietf.org Errors-To: diffserv-interest-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Differentiated services general discussion X-BeenThere: diffserv-interest@ietf.org Content-Transfer-Encoding: 7bit "Ashkenazi, Liat (Liat)" wrote: > > Thank you for Your Answer: > > If we don't deal with "calls" and we deal with flow aggregate. > I still don't understand how we can know if it can enter the network (or domain)? > The policy unit rely just on the class of the flow and then decide whether to drop the packets or not but Is it consider the network condition (is it available or not)? That's an implementation and deployment choice. For example you might allocate some Mbit/s to EF traffic, and admit up to N VoIP calls where N is calculated to almost fill those Mbit/s. (Real life is more complicated since you have to allow for link failures etc.) But the rest of the capacity could be split between an AF class (for important business traffic) and a best effort class (for everything else). As you will gather I belive in extremely simple diffserv scenarios - complex is bad. > > If there is no admission control is like best-effort thing. Similar, but the model is that traffic will be sent in the class of service that is most appropriate for the application. Diffserv is not a revolution, it's fine-tuning the Internet's existing service model. Brian _______________________________________________ Diffserv-interest mailing list Diffserv-interest@ietf.org https://www1.ietf.org/mailman/listinfo/diffserv-interest From daemon@optimus.ietf.org Fri Jun 28 07:48:22 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA21069 for ; Fri, 28 Jun 2002 07:48:22 -0400 (EDT) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id HAA18471 for diffserv-interest-archive@odin.ietf.org; Fri, 28 Jun 2002 07:49: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 HAA18360; Fri, 28 Jun 2002 07:47:44 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id HAA18339 for ; Fri, 28 Jun 2002 07:47:42 -0400 (EDT) Received: from d12lmsgate-2.de.ibm.com (d12lmsgate-2.de.ibm.com [195.212.91.200]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA21019 for ; Fri, 28 Jun 2002 07:46:56 -0400 (EDT) Received: from d12relay01.de.ibm.com (d12relay01.de.ibm.com [9.165.215.22]) by d12lmsgate-2.de.ibm.com (8.12.3/8.12.3) with ESMTP id g5SBkuEr006378; Fri, 28 Jun 2002 13:46:56 +0200 Received: from etzel.zurich.ibm.com (etzel.zurich.ibm.com [9.4.64.140]) by d12relay01.de.ibm.com (8.11.1m3/NCO/VER6.1) with SMTP id g5SBkqK154628; Fri, 28 Jun 2002 13:46:52 +0200 Received: from dhcp23-199.zurich.ibm.com by etzel.zurich.ibm.com (AIX 4.3/UCB 5.64/4.03) id AA58170 from ; Fri, 28 Jun 2002 13:46:37 +0200 Message-Id: <3D1C4CD1.5D9FAE2A@hursley.ibm.com> Date: Fri, 28 Jun 2002 13:47:29 +0200 From: Brian E Carpenter Organization: IBM X-Mailer: Mozilla 4.79 [en] (Windows NT 5.0; U) X-Accept-Language: en,fr,de Mime-Version: 1.0 To: brunner@ccrle.nec.de Cc: Kathleen Nichols , Dan Grossman , diffserv-interest@ietf.org Subject: Re: [Diffserv-interest] Re: [Diffserv] Hard questions (was: Diffserv PIB approved asInformational RFC) References: <3D19F179.1040507@packetdesign.com> <37268849.1025214865@[192.168.102.207]> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: diffserv-interest-admin@ietf.org Errors-To: diffserv-interest-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Differentiated services general discussion X-BeenThere: diffserv-interest@ietf.org Content-Transfer-Encoding: 7bit Marcus Brunner wrote: > > [switched to diffserv-interest] > > > By the way, using diffserv for cable data networks and wireless > > networks is rather different than using diffserv for a more > > mesh-y network cloud. What those folks are actually doing is > > creating PDBs that apply across their very specific network > > topologies. > > We define also PDBs but with our very specific DiffServ implementation by > fixing quite a number of parameters before even think about a PDB. We found > that the openness of the DiffServ specs are a hindrence in defining crisp > PDBs, therefore we can only do propriatary ones, and these are complicated > and not very crisp as well. That's an interesting comment. Can you be more specific? By the way, this isn't unusual in the IETF. We often have to fix basic behaviour and leave many paramters free, because that is all we can get consensus on until several years of deployment has gone by. Another (related) example is the IPv6 flow label, where we are only now defining even its basic rules. Brian _______________________________________________ Diffserv-interest mailing list Diffserv-interest@ietf.org https://www1.ietf.org/mailman/listinfo/diffserv-interest From daemon@optimus.ietf.org Fri Jun 28 09:01:48 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA24310 for ; Fri, 28 Jun 2002 09:01:44 -0400 (EDT) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id JAA24164 for diffserv-interest-archive@odin.ietf.org; Fri, 28 Jun 2002 09:02: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 JAA23958; Fri, 28 Jun 2002 09:01: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 JAA23922 for ; Fri, 28 Jun 2002 09:01:22 -0400 (EDT) Received: from tokyo.ccrle.nec.de (tokyo.ccrle.nec.de [195.37.70.2]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA24220 for ; Fri, 28 Jun 2002 09:00:33 -0400 (EDT) Received: from wallace.heidelberg.ccrle.nec.de (root@wallace.heidelberg.ccrle.nec.de [192.168.102.1]) by tokyo.ccrle.nec.de (8.11.6/8.11.6) with ESMTP id g5SD0kK64548; Fri, 28 Jun 2002 15:00:46 +0200 (CEST) (envelope-from brunner@ccrle.nec.de) Received: from imap.heidelberg.ccrle.nec.de (imap.heidelberg.ccrle.nec.de [192.168.102.11]) by wallace.heidelberg.ccrle.nec.de (8.9.3/8.9.3/SuSE Linux 8.9.3-0.1) with ESMTP id OAA04275; Fri, 28 Jun 2002 14:55:35 +0200 Received: from [192.168.102.207] (marcus.heidelberg.ccrle.nec.de [192.168.102.207]) by imap.heidelberg.ccrle.nec.de (Postfix on SuSE Linux eMail Server 3.0) with ESMTP id E288C4DFA6; Fri, 28 Jun 2002 14:55:33 +0200 (CEST) Date: Fri, 28 Jun 2002 14:55:34 +0200 From: Marcus Brunner Reply-To: brunner@ccrle.nec.de To: Brian E Carpenter Cc: Kathleen Nichols , Dan Grossman , diffserv-interest@ietf.org Subject: Re: [Diffserv-interest] Re: [Diffserv] Hard questions (was: Diffserv PIB approved asInformational RFC) Message-ID: <8301096.1025276134@[192.168.102.207]> In-Reply-To: <3D1C4CD1.5D9FAE2A@hursley.ibm.com> References: <3D1C4CD1.5D9FAE2A@hursley.ibm.com> X-Mailer: Mulberry/2.2.0 (Win32) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline Content-Transfer-Encoding: 7bit Sender: diffserv-interest-admin@ietf.org Errors-To: diffserv-interest-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Differentiated services general discussion X-BeenThere: diffserv-interest@ietf.org Content-Transfer-Encoding: 7bit --On Freitag, 28. Juni 2002 13:47 +0200 Brian E Carpenter wrote: > Marcus Brunner wrote: >> >> [switched to diffserv-interest] >> >> > By the way, using diffserv for cable data networks and wireless >> > networks is rather different than using diffserv for a more >> > mesh-y network cloud. What those folks are actually doing is >> > creating PDBs that apply across their very specific network >> > topologies. >> >> We define also PDBs but with our very specific DiffServ implementation by >> fixing quite a number of parameters before even think about a PDB. We >> found that the openness of the DiffServ specs are a hindrence in >> defining crisp PDBs, therefore we can only do propriatary ones, and >> these are complicated and not very crisp as well. > > That's an interesting comment. Can you be more specific? > > By the way, this isn't unusual in the IETF. We often have to fix basic > behaviour and leave many paramters free, because that is all we can get > consensus on until several years of deployment has gone by. Another > (related) example is the IPv6 flow label, where we are only now defining > even its basic rules. > > Brian Brian, I completely understand that. I even think since the definition of crisp PDB is very complicated, it adds value to solution, which people don't just want to give away for standardization. E.g., we the did the following PDB: - p2p - guaranteed throughput no loss for packets within CIR profile - maximum delay bound We defined configuration rules for our DiffServ implementation. And we are sure this PDB is not implementable with some of the other DiffServ implementations (even if they conform to the standard). >From the process we actually first looked into our implementation and then tried to figure out how the PDB looks like. On the other hand, for the community and for helping the deployment, a small set of PDBs (even if they are very loose without stringent guarantees) would help. whether we are able to agree on them is a different question, because some of the people are not able to implement them with they DiffServ nodes. Marcus -------------------------------------- Dr. Marcus Brunner Network Laboratories NEC Europe Ltd. E-Mail: brunner@ccrle.nec.de WWW: http://www.ccrle.nec.de/ personal home page: http://www.brubers.org/marcus _______________________________________________ Diffserv-interest mailing list Diffserv-interest@ietf.org https://www1.ietf.org/mailman/listinfo/diffserv-interest From daemon@optimus.ietf.org Fri Jun 28 17:12:24 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA22396 for ; Fri, 28 Jun 2002 17:12:24 -0400 (EDT) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id RAA03304 for diffserv-interest-archive@odin.ietf.org; Fri, 28 Jun 2002 17:13:11 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id RAA03238; Fri, 28 Jun 2002 17:12:35 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id PAA26315 for ; Fri, 28 Jun 2002 15:46:11 -0400 (EDT) Received: from motgate3.mot.com (motgate3.mot.com [144.189.100.103]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA17506 for ; Fri, 28 Jun 2002 15:45:24 -0400 (EDT) Received: [from pobox.mot.com (pobox.mot.com [129.188.137.100]) by motgate3.mot.com (motgate3 2.1) with ESMTP id MAA26767; Fri, 28 Jun 2002 12:45:19 -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 MAA28568; Fri, 28 Jun 2002 12:46:01 -0700 (MST)] Received: from dma.isg.mot.com (ma07-0056.dma.isg.mot.com [150.21.30.201]) by noah.dma.isg.mot.com (8.8.8+Sun/8.8.8) with ESMTP id PAA16318; Fri, 28 Jun 2002 15:42:51 -0400 (EDT) Message-ID: <3D1CBC3A.55E72178@dma.isg.mot.com> Date: Fri, 28 Jun 2002 15:42:51 -0400 From: Dan Grossman X-Mailer: Mozilla 4.5 [en] (WinNT; U) X-Accept-Language: en MIME-Version: 1.0 To: brunner@ccrle.nec.de CC: Brian E Carpenter , Kathleen Nichols , diffserv-interest@ietf.org Subject: Re: [Diffserv-interest] Re: [Diffserv] Hard questions (was:Diffserv PIB approved asInformational RFC) References: <3D1C4CD1.5D9FAE2A@hursley.ibm.com> <8301096.1025276134@[192.168.102.207]> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: diffserv-interest-admin@ietf.org Errors-To: diffserv-interest-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Differentiated services general discussion X-BeenThere: diffserv-interest@ietf.org Content-Transfer-Encoding: 7bit > All this is very discouraging, perhaps indicative of a massive failure of the Diffserv standardization exercise. It also raises questions as to whether the historical accomodation between the IETF standarization process and the business needs of its participants' employers hasn't in fact broken down. > I completely understand that. I even think since the definition of crisp > PDB is very complicated, it adds value to solution, which people don't just > want to give away for standardization. > > E.g., we the did the following PDB: > - p2p Can you explain this one? > > - guaranteed throughput no loss for packets within CIR profile > - maximum delay bound > > We defined configuration rules for our DiffServ implementation. And we are > sure this PDB is not implementable with some of the other DiffServ > implementations (even if they conform to the standard). Is the problem that PHBs are underspecified? Or is the issue in classifiers, conditioners, queuing systems and/or schedulers? > > > >From the process we actually first looked into our implementation and then > tried to figure out how the PDB looks like. Can you explain a bit more, and, in particular, were you looking at quantifiable parameters only, or were there also temporal or other behaviors that were affected? > > > On the other hand, for the community and for helping the deployment, a > small set of PDBs (even if they are very loose without stringent > guarantees) would help. whether we are able to agree on them is a different > question, because some of the people are not able to implement them with > they DiffServ nodes. If this is true, then we have created a bunch of standards that don't advance interoperability, and thus have failed. I knew that there were problems, but didn't realize that it was this bad. Is there anything that can be learned from this? _______________________________________________ Diffserv-interest mailing list Diffserv-interest@ietf.org https://www1.ietf.org/mailman/listinfo/diffserv-interest