From dcpel-bounces@ietf.org Wed Nov 02 12:46:14 2005 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EXMgg-0007Iy-NO; Wed, 02 Nov 2005 12:46:14 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EXMgd-0007IS-Io for dcpel@megatron.ietf.org; Wed, 02 Nov 2005 12:46:11 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA25476 for ; Wed, 2 Nov 2005 12:45:49 -0500 (EST) Received: from p-mail1.rd.francetelecom.com ([195.101.245.15]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EXMvE-0006It-LK for dcpel@ietf.org; Wed, 02 Nov 2005 13:01:19 -0500 Received: from ftrdmel10.rd.francetelecom.fr ([10.193.117.156]) by ftrdsmtp2.rd.francetelecom.fr with Microsoft SMTPSVC(6.0.3790.211); Wed, 2 Nov 2005 18:46:04 +0100 Received: from [10.193.11.122] ([10.193.11.122]) by ftrdmel10.rd.francetelecom.fr with Microsoft SMTPSVC(6.0.3790.211); Wed, 2 Nov 2005 18:46:04 +0100 Message-ID: <4368FB5C.6060108@francetelecom.com> Date: Wed, 02 Nov 2005 18:46:04 +0100 From: Olivier Dugeon Organization: France Telecom User-Agent: Mozilla Thunderbird 1.0.6 (X11/20050716) X-Accept-Language: fr, en MIME-Version: 1.0 To: Paulo Mendes Subject: Re: [Dcpel] response (changed long subject line) References: <28F05C819859B042BBF585C4997D5A476ED7B2@deex.docomolab-euro.com> <4358D229.8050808@docomolab-euro.com> <435D630E.9010701@pollere.com> <435F5CCC.2090205@francetelecom.com> <4360BC0A.40302@docomolab-euro.com> In-Reply-To: <4360BC0A.40302@docomolab-euro.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: quoted-printable X-OriginalArrivalTime: 02 Nov 2005 17:46:04.0684 (UTC) FILETIME=[4C0C74C0:01C5DFD5] X-Spam-Score: 0.0 (/) X-Scan-Signature: 41c17b4b16d1eedaa8395c26e9a251c4 Content-Transfer-Encoding: quoted-printable Cc: dcpel@ietf.org X-BeenThere: dcpel@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Mailing list for possible diffserv control plane elements WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: dcpel-bounces@ietf.org Errors-To: dcpel-bounces@ietf.org Hi Paulo, Paulo Mendes a =E9crit : > Hi there, > > some comments inline... > > Olivier Dugeon wrote: > >> Hi Kathleen, >> >> Kathleen Nichols a =E9crit : >> >>> Paulo Mendes wrote: >>> =20 >>> >>> [ ... skip ... ] >>> >> I take the opportunity to give my understanding about COPS. I think=20 >> that COPS is more devoted to apply policy to a given set of device=20 >> rather than building a control Plane. In fact, the Dcpel could used=20 >> COPS to enforce QoS in the network and IMHO is placed on top of PDP=20 >> since it facilitate the PDP configuration. i.e. that it is not solved = >> in COPS is how/when/with which information an operator could easely=20 >> fullfill the PIB in a PDP. > > > [Paulo] Keeping in mind a modular distinction between inter- and=20 > intra-domain, I would say that based on a set of available=20 > inter-domain QoS agreements, the PDP, which control the QoS=20 > agreements, may use COPS to enforce QoS in the network, as you say.=20 > But we must see what do you mean by "enforcing the QoS in the=20 > network". IMHO there are two options: a) a centralized one, in which=20 > the PDP uses COPS to configure all the needed routers; b) a=20 > decentralized one, in which the PDP used COPS to configure the ingress = > PEP, and to inform the PEP about the PDB that needs to be setup. Based = > on this information the PEP uses an intra-domain signaling protocol to = > perform class configuration until the required egress point. This=20 > signaling may be based on a NSIS protocol. [OD]. I'm agree with your analyze. I have in mind the b) solution where=20 effectively only the ingress node need to be configured. The a) option=20 mostly refer to OSS management and not to control plane. But, the main=20 argument in favor of b) is performance issue. It is more scalable and=20 faster to just enforce QoS on the ingress node. Now, what mechanism is=20 needed to enforce QoS on ingress node vary depending on what the network = support. It could be setup a path with NSIS or RSVP or RSVP-TE or simply = configure a classifier/marker for a simple DiffServ node. Regards, Olivier --=20 Project Manager for Network architecture and switching Division & FT/DR&D/CORE/M2I | mailto:Olivier.Dugeon@francetelecom.com 2, Avenue Pierre Marzin | Phone/Fax: +(33) 296 05 2880/1470 F-22307 LANNION | Mobile: +(33) 6 82 90 37 85 _______________________________________________ Dcpel mailing list Dcpel@ietf.org https://www1.ietf.org/mailman/listinfo/dcpel From dcpel-bounces@ietf.org Wed Nov 02 12:47:32 2005 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EXMhw-0007uf-GR; Wed, 02 Nov 2005 12:47:32 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EXMhs-0007tX-J7 for dcpel@megatron.ietf.org; Wed, 02 Nov 2005 12:47:28 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA25840 for ; Wed, 2 Nov 2005 12:47:06 -0500 (EST) Received: from p-mail1.rd.francetelecom.com ([195.101.245.15]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EXMwU-0006Pu-JK for dcpel@ietf.org; Wed, 02 Nov 2005 13:02:36 -0500 Received: from ftrdmel10.rd.francetelecom.fr ([10.193.117.156]) by ftrdsmtp1.rd.francetelecom.fr with Microsoft SMTPSVC(6.0.3790.211); Wed, 2 Nov 2005 18:47:24 +0100 Received: from [10.193.11.122] ([10.193.11.122]) by ftrdmel10.rd.francetelecom.fr with Microsoft SMTPSVC(6.0.3790.211); Wed, 2 Nov 2005 18:47:23 +0100 Message-ID: <4368FBAB.1020808@francetelecom.com> Date: Wed, 02 Nov 2005 18:47:23 +0100 From: Olivier Dugeon Organization: France Telecom User-Agent: Mozilla Thunderbird 1.0.6 (X11/20050716) X-Accept-Language: fr, en MIME-Version: 1.0 To: Paulo Mendes , Kathleen Nichols Subject: Re: [Dcpel] response (changed long subject line) References: <28F05C819859B042BBF585C4997D5A476ED7B2@deex.docomolab-euro.com> <4358D229.8050808@docomolab-euro.com><435D630E.9010701@pollere.com> <4360BBFB.80907@docomolab-euro.com> In-Reply-To: <4360BBFB.80907@docomolab-euro.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: quoted-printable X-OriginalArrivalTime: 02 Nov 2005 17:47:23.0903 (UTC) FILETIME=[7B4450F0:01C5DFD5] X-Spam-Score: 0.0 (/) X-Scan-Signature: 6640e3bbe8a4d70c4469bcdcbbf0921d Content-Transfer-Encoding: quoted-printable Cc: dcpel@ietf.org X-BeenThere: dcpel@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Mailing list for possible diffserv control plane elements WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: dcpel-bounces@ietf.org Errors-To: dcpel-bounces@ietf.org Hi Paulo and Kathleen, I stronger support the Paulo proposal and I'm also in favor of the b)=20 option. Regards, Olivier Paulo Mendes a =E9crit : > Hi Kathleen, > > Kathleen Nichols wrote: > >> Paulo Mendes wrote: >> =20 >> >>> Hello, >>> >>> I'm quite interested in this BOF. Actually, for a long time that I wa= s >>> expecting a BOF like this to show up. This because it is perfectly >>> synchronized with the work that I'm currently doing at the NTT DoCoMo= >>> laboratories in Europe. Currently, we are working on the following=20 >>> topics: >>> - Dynamic control of inter-domain QoS with local configuration of PDB= s: >>> - Standard Information model >>> - Standard interface >>> - Standard protocol for local configuration of classes >>> - Distributed control of intra-domain QoS with admission control and >>> dynamic allocation of BW to different classes. >>> >>> I enumerated these two topic in a clear separation between inter-doma= in >>> and intra-domain. This because the requirements are clearly different= =2E >>> For instance, in what concerns signaling, while inter-domain must be >>> done at the network level, and a protocol much simpler than NSIS may = be >>> used, intra-domain control of classes resources should be done in the= >>> data path from ingress to egress. >>> =20 >> >> >> That has been our thinking also. And I think it makes sense to seek >> a charter that is limited to intra-domain at first. Many WGs >> (including Diffserv) recharter when it is time for new work items >> and that's a nice way to keep focus. >> =20 >> > [Paulo] I agree. We can do this is two ways: a) create a charter only=20 > for intra-domain issues, keeping in mind that the charter may be=20 > changed latter to include inter-domain issues; b) he create a charter=20 > encompassing intra- and inter- domain issues, but we define a clear=20 > work plan, which should give higher priority to intra-domain issues. I = > would prefer the option b), because this will make the WG stronger,=20 > since we aim to provide the needed E2E solution. And in the end is=20 > this that matters. If you follow option a), we are leaving behind the=20 > major reason not to have QoS deployed in the Internet, which is the=20 > lack of inter-domain control. > I'm a little afraid that if we don't include the inter-domain control=20 > in our list of priorities, it may happen that we end up again with a=20 > half-solution: control of Diffserv networks but still no end-to-end QoS= =2E > >>> It seems that for now there is only Nichols's et al. ID about a=20 >>> strawman >>> description of components. If there is already a stable idea of what >>> this control plane must, should and may provide, I agree that the nex= t >>> step may be the classification of existing solutions and identificati= on >>> of missing functionalities. Otherwise, it is better to clearly identi= fy >>> the problem statement, and a set or requirements and assumptions. >>> =20 >> >> >> I would welcome your input on any of these items. We put out a >> strawman to give something common to talk about (even if it is >> just to disagree with it. If you would like to write a brief >> draft of a proposed problem statement, we could discuss that >> on the list and at Vancouver. So, we have the possibility of >> using the COPS RFCs as a basis for a diffserv control plane, >> we have the option of looking at some solution approaches to >> see if there is a stable idea of the control plane, and >> we have the option of writing a problem statement. >> =20 >> > I would very much like to contribute to this problem statement draft,=20 > since it will clarify our goals. If we do this, can you present the=20 > draft in Vancouver? (like I said in my last email, unfortunately I=20 > cannot attend the IETF meeting in Vancouver). > >>> So, I'm available to contribute to the following actions: >>> - Classification of requirements and assumptions for the control of >>> DiffServ networks >>> - Specification of control elements/protocols (which should all have = a >>> good security assurance :) ) >>> >>> I could also help in the shape the BoF proposal, if still needed, but= >>> unfortunately, due to other travel appointments, I cannot attend the >>> Vancouver meeting. >>> >>> =20 >> >> >> Certainly shaping a proposal for a WG charter is still needed. This >> can be done through email. >> >> regards, >> Kathie Nichols >> =20 >> > Cheers > Paulo > > _______________________________________________ > Dcpel mailing list > Dcpel@ietf.org > https://www1.ietf.org/mailman/listinfo/dcpel > --=20 Project Manager for Network architecture and switching Division & FT/DR&D/CORE/M2I | mailto:Olivier.Dugeon@francetelecom.com 2, Avenue Pierre Marzin | Phone/Fax: +(33) 296 05 2880/1470 F-22307 LANNION | Mobile: +(33) 6 82 90 37 85 _______________________________________________ Dcpel mailing list Dcpel@ietf.org https://www1.ietf.org/mailman/listinfo/dcpel From dcpel-bounces@ietf.org Wed Nov 02 12:54:12 2005 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EXMoO-00031Q-OB; Wed, 02 Nov 2005 12:54:12 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EXMoM-0002zK-Bq for dcpel@megatron.ietf.org; Wed, 02 Nov 2005 12:54:10 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA26506 for ; Wed, 2 Nov 2005 12:53:48 -0500 (EST) Received: from p-mail1.rd.francetelecom.com ([195.101.245.15]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EXN2x-0006uD-Sb for dcpel@ietf.org; Wed, 02 Nov 2005 13:09:16 -0500 Received: from ftrdmel10.rd.francetelecom.fr ([10.193.117.156]) by ftrdsmtp2.rd.francetelecom.fr with Microsoft SMTPSVC(6.0.3790.211); Wed, 2 Nov 2005 18:54:05 +0100 Received: from [10.193.11.122] ([10.193.11.122]) by ftrdmel10.rd.francetelecom.fr with Microsoft SMTPSVC(6.0.3790.211); Wed, 2 Nov 2005 18:54:05 +0100 Message-ID: <4368FD3C.8050107@francetelecom.com> Date: Wed, 02 Nov 2005 18:54:04 +0100 From: Olivier Dugeon Organization: France Telecom User-Agent: Mozilla Thunderbird 1.0.6 (X11/20050716) X-Accept-Language: fr, en MIME-Version: 1.0 To: Kathleen Nichols Subject: Re: [Dcpel] Dcpel BoF support References: <43590931.5080809@francetelecom.com> <435D64E1.4000605@pollere.com><435F5B3D.40706@francetelecom.com> <435FB01A.1080306@pollere.com> In-Reply-To: <435FB01A.1080306@pollere.com> X-OriginalArrivalTime: 02 Nov 2005 17:54:05.0075 (UTC) FILETIME=[6A624E30:01C5DFD6] X-Spam-Score: 1.1 (+) X-Scan-Signature: 2086112c730e13d5955355df27e3074b Cc: dcpel@ietf.org X-BeenThere: dcpel@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Mailing list for possible diffserv control plane elements WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============0651714969==" Sender: dcpel-bounces@ietf.org Errors-To: dcpel-bounces@ietf.org --===============0651714969== Content-Type: text/html; charset=ISO-8859-15 Content-Transfer-Encoding: quoted-printable Content-Transfer-Encoding: quoted-printable Hi Kathleen,
Kathleen Nichols a =E9crit=A0: 
Olivier Dugeon wrote:
  
Kathleen Nichols a =E9crit :

    
Olivier Dugeon wrote:
      
...
  
So, do you think the charter must be only focus on=
 DiffServ or could it
be open to other QoS enforcement mechanism ? Or, for the strategy, is it
preferable to focus on DiffServ, and after the WG created, open the
scope to other technology ?
 =20
        
I'm in favor of keeping the focus limited at any one=
 time, but
rechartering is fine when some things get done. But what other QoS
enforcement mechanisms did you have in mind besides diffserv?
=20
      
In fact, inside the EuQoS project, we intend to manage=
 several
technology (in particular the access part) across a common view of the
QoS. This why, in our architecture there is 2 view of the Control Plane.
One which technology independent and manage the inter-domain and the
other which is technology dependent and manage the intra domain part.
So, from the DiffServ point of view, this could result to setup
approriate L2 mechanism in order to provide a DiffServ aware QoS
mechanism. For example, in xDSL ATM or GE network, the EF class could be
map to a CBR ATM ATC or a particular VLAN. This could be also apply if
you intend to used MPLS-DiffServ mechanism.

    

Okay, this is of course useful stuff and something we all end up doing
in adapting to a particular network. It seems like it would be useful
if it is possible to have some kind of commonality in how L2 interacts
with L3 diffserv mechansims so that the control plane can be
technology independent. Though this needs to be considered when
designing a network QoS solution, I'm not sure we should put it on
dcpel's work list. At least not immediately. It seems to me that
at some point this might need some kind of sub-category of "Advice
to Link Layer Designers".
  
I'm also very confident in this attempt since this=
 kind of functions are
now studied in various place:

        

So, in your opinion, what are the major things Dcpel could *add* to this
work?
=46rom your remarks, I think we need to add a focus on technology independent control plane with a link to L2. I.e. add a clear separation between the control part and the device configuration part in the architecture of the control plane. Concerning the device configuration, the WG could just focus on DiffServ configuration through COPS for example and let open configuration of others technology. IMHO, I think that the WG should be chartered in order to build an open framework and decline this framework for a use case which is DiffServ.

Regards,

Olivier
	Kathie


_______________________________________________
Dcpel mailing list
Dcpe=
l@ietf.org
https://www1.ietf.org/mailman/listinfo/dcpel

  

--=20
Project Manager for Network architecture and switching Division
 & FT/DR&D/CORE/M2I           | mailto:Olivier.Dugeon@=
francetelecom.com
 2, Avenue Pierre Marzin      | Phone/Fax:  +(33) 296 05 2880/1470
 F-22307 LANNION              | Mobile:     +(33) 6 82 90 37 85
--===============0651714969== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Dcpel mailing list Dcpel@ietf.org https://www1.ietf.org/mailman/listinfo/dcpel --===============0651714969==-- From dcpel-bounces@ietf.org Wed Nov 02 13:10:30 2005 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EXN4A-0007MP-Kh; Wed, 02 Nov 2005 13:10:30 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EXN4A-0007M5-0w for dcpel@megatron.ietf.org; Wed, 02 Nov 2005 13:10:30 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA28053 for ; Wed, 2 Nov 2005 13:10:08 -0500 (EST) Received: from p-mail1.rd.francetelecom.com ([195.101.245.15]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EXNIn-0007ux-Fg for dcpel@ietf.org; Wed, 02 Nov 2005 13:25:37 -0500 Received: from ftrdmel10.rd.francetelecom.fr ([10.193.117.156]) by ftrdsmtp2.rd.francetelecom.fr with Microsoft SMTPSVC(6.0.3790.211); Wed, 2 Nov 2005 19:10:28 +0100 Received: from [10.193.11.122] ([10.193.11.122]) by ftrdmel10.rd.francetelecom.fr with Microsoft SMTPSVC(6.0.3790.211); Wed, 2 Nov 2005 19:10:27 +0100 Message-ID: <43690113.3000005@francetelecom.com> Date: Wed, 02 Nov 2005 19:10:27 +0100 From: Olivier Dugeon Organization: France Telecom User-Agent: Mozilla Thunderbird 1.0.6 (X11/20050716) X-Accept-Language: fr, en MIME-Version: 1.0 To: Paulo Mendes Subject: Re: [Dcpel] Dcpel BoF support References: <43590931.5080809@francetelecom.com> <4360BBE9.3070207@docomolab-euro.com> In-Reply-To: <4360BBE9.3070207@docomolab-euro.com> Content-Type: text/plain; charset=ISO-8859-15; format=flowed Content-Transfer-Encoding: quoted-printable X-OriginalArrivalTime: 02 Nov 2005 18:10:27.0644 (UTC) FILETIME=[B40A6FC0:01C5DFD8] X-Spam-Score: 0.0 (/) X-Scan-Signature: 14582b0692e7f70ce7111d04db3781c8 Content-Transfer-Encoding: quoted-printable Cc: dcpel@ietf.org X-BeenThere: dcpel@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Mailing list for possible diffserv control plane elements WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: dcpel-bounces@ietf.org Errors-To: dcpel-bounces@ietf.org Hi Paulo, Paulo Mendes a =E9crit : > Hi Olivier, Kathleen and all, > > It is good to know that the partners in IST EuQoS are planning to=20 > support this BoF. I was acquainted in joint QoS workshop of EuQoS and=20 > Mescal with the idea to create one BoF on Resource Management. I think = > that the QoS community will gain in having all the interested parties=20 > in the same BoF. So, it will be a good exercise to merge, as possible, = > the ideas behind both proposals. Yes, it is our (the EuQoS people at least) objective. > > Concerning the charter, I think that it will be more efficient to=20 > divide the effort in inter- and intra-domain. The main reason, in my=20 > opinion is that decoupling inter- and intra- this will bring more=20 > flexibility in end-to-end operations. Modularity is always a good=20 > principle. > > You say that your focus in not on DiffServ to enforce QoS in the=20 > network, but on the definition of a Resource Manager framework. Good,=20 > but this Resource Management framework can still be defined with two=20 > modules for inter- and intra-domain, connected by a network interface. = > But, in what concerns the intra-domain resource control, I don't know=20 > why shouldn't we focus on DiffServ. First, the DiffServ model is=20 > clearly lacking a control plane; second, other QoS enforcement=20 > mechanisms, such as MPLS, already define how resources may be=20 > controlled. Moreover, I still think that DiffServ as a lot of=20 > potential, not only to support qualitative traffic, but also=20 > quantitative one. Ok, I'm writing a bit faster. I have in mind to built an open framework=20 with the DiffServ implementation. So, skip the term of Resource Manager = and just keep that the architecture of a such control must be open and=20 flexible. If we can achieve a such goal for DiffServ, it could be easy=20 to extend it to other technology. I'm agree that DiffServ is lacking of=20 a control plane and have great potential. Concerning the quantitative=20 support, do you have in mind Admission Control and/or Resource Reservatio= n ? > > Another question is related to the 'topology acquisition' item. This=20 > means that you think that the control of resources within a DiffServ=20 > network should be centralized in a "resource manager", which will then = > need to collect topology information? Since a PDB is already defined=20 > in a distributed way, why not allow the control of resources to be=20 > distributed, with most of the operations being located at the edges?=20 > This distributed approach brings the benefits of higher robustness and = > perhaps performance. Well, under the 'topology acquisition', I'm not thinking about a=20 centralized or distributed way of implementation. I'm just refering to=20 the quantitative support of QoS with DiffServ. To do this, it is=20 necessary to have a minimum knowledge of the controlled network in order = to perform admission control or resource reservation. Another point is=20 device configuration. If the QoS request is not following the data path=20 (i.e. coming from a SIP proxy for example) the topology information is=20 again mandatory to retrieve the correct ingress node in order to=20 configure it. > > In what concerns the other standardization efforts, I would say that=20 > it would help a lot this BoF, if we had a brief document=20 > characterizing the differences between all these approaches to see=20 > where this BoF would fit. If you breifly look at the standardization efforts, you could obsrve=20 that they all focus for the moment: 1/ on conversational services (based on SIP) 2/ on access network and especially on xDSL network So, there is a great opportunity for Dcpel to study data services on=20 core network which is completely the scope of the IETF. Cheers, Olivier --=20 Project Manager for Network architecture and switching Division & FT/DR&D/CORE/M2I | mailto:Olivier.Dugeon@francetelecom.com 2, Avenue Pierre Marzin | Phone/Fax: +(33) 296 05 2880/1470 F-22307 LANNION | Mobile: +(33) 6 82 90 37 85 _______________________________________________ Dcpel mailing list Dcpel@ietf.org https://www1.ietf.org/mailman/listinfo/dcpel From dcpel-bounces@ietf.org Wed Nov 02 14:34:52 2005 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EXONo-0004zX-HD; Wed, 02 Nov 2005 14:34:52 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EXONm-0004yC-D2 for dcpel@megatron.ietf.org; Wed, 02 Nov 2005 14:34:50 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA03397 for ; Wed, 2 Nov 2005 14:34:28 -0500 (EST) Received: from deprox.docomolab-euro.com ([212.119.9.186]) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1EXOcP-00031r-Ec for dcpel@ietf.org; Wed, 02 Nov 2005 14:49:58 -0500 Received: from 172.27.10.3 by deprox.docomolab-euro.com (InterScan E-Mail VirusWall NT); Wed, 02 Nov 2005 20:33:50 +0100 Received: from [172.27.100.47] ([172.27.100.47]) by deex.docomolab-euro.com with Microsoft SMTPSVC(5.0.2195.4905); Wed, 2 Nov 2005 20:33:50 +0100 Message-ID: <43691477.4080608@docomolab-euro.com> Date: Wed, 02 Nov 2005 20:33:11 +0100 From: Paulo Mendes User-Agent: Mozilla Thunderbird 1.0.2 (X11/20050317) X-Accept-Language: en-us, en MIME-Version: 1.0 To: =?ISO-8859-15?Q?=22Attila_B=E1der_=28IJ/ETH=29=22?= Subject: Re: [Dcpel] Dcpel BoF support References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-15; format=flowed X-OriginalArrivalTime: 02 Nov 2005 19:33:50.0755 (UTC) FILETIME=[5A209730:01C5DFE4] X-Spam-Score: 0.0 (/) X-Scan-Signature: 4b7d60495f1a7f2e853e8cbae7e6dbfc Content-Transfer-Encoding: quoted-printable X-MIME-Autoconverted: from 8bit to quoted-printable by ietf.org id OAA03397 Cc: dcpel@ietf.org X-BeenThere: dcpel@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Mailing list for possible diffserv control plane elements WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: dcpel-bounces@ietf.org Errors-To: dcpel-bounces@ietf.org Dear Attila, as I mentioned before, i fully agree that inter-domain QoS control=20 should be included in the charter, although probably with lower priority=20 than the intra-domain study. About the NSIS proposal for path-decoupled signalling. In my opinion=20 path-decoupled signalling is well suitable for inter-domain QoS control,=20 but it is still not clear to me what is the best solution, or if we can=20 have more than one complementary solutions. In what concerns this issue,=20 here are for now two questions: - Should the inter-domain signalling go through 'QoS controllers' or=20 should that signalling occur between 'QoS controllers'? The answer to=20 this question requires some analysis of assumptions and goals. - Will networks want to control traffic or flows? Regards Paulo Attila B=E1der (IJ/ETH) wrote: >Dear All, =20 > >Dear all, as I understand the main goal of the working group would be to= identify and define elements for DiffServ-based resource manager concept. > >I think that such concept should address inter-domain signaling as well.= Note that there is an NSIS a proposal for path-decoupled signaling. If i= t gets through, NSIS could be used as protocol between resource managers.= Anyway it should be avoided that IETF develops two protocols parallel fo= r the same purpose.=20 > >Best regards, Attila > > =20 > >>-----Original Message----- >>From: dcpel-bounces@ietf.org [mailto:dcpel-bounces@ietf.org] >>Sent: Thursday, October 27, 2005 7:19 PM >>To: dcpel@ietf.org >>Subject: Re: [Dcpel] Dcpel BoF support >> >> >>Paulo Mendes wrote: >>... >> =20 >> >>>Concerning the charter, I think that it will be more efficient to >>>divide the effort in inter- and intra-domain. The main reason, in my >>>opinion is that decoupling inter- and intra- this will bring more >>>flexibility in end-to-end operations. Modularity is always a good >>>principle. >>> =20 >>> >>[Kathie]I believe division is the way to go, but I think we=20 >>need to keep >>in mind that we have to make the step from intra- to inter-. This >>hasn't seemed all that divergent in the work I've done, but I'm >>interested to see others' approaches and concerns. For example, >>I think when one constructs in interior control plane, it is >>necessary to think about what information you are willing to >>expose to the outside, what you will send and what you will >>accept. So I think that sets you up for the inter- step. >> >> >> =20 >> >>>You say that your focus in not on DiffServ to enforce QoS in the >>>network, but on the definition of a Resource Manager=20 >>> =20 >>> >>framework. Good, >> =20 >> >>>but this Resource Management framework can still be defined with two >>>modules for inter- and intra-domain, connected by a network=20 >>> =20 >>> >>interface. >> =20 >> >>>But, in what concerns the intra-domain resource control, I=20 >>> =20 >>> >>don't know >> =20 >> >>>why shouldn't we focus on DiffServ. First, the DiffServ=20 >>> =20 >>> >>model is clearly >> =20 >> >>>lacking a control plane; second, other QoS enforcement=20 >>> =20 >>> >>mechanisms, such >> =20 >> >>>as MPLS, already define how resources may be controlled. Moreover, I >>>still think that DiffServ as a lot of potential, not only to support >>>qualitative traffic, but also quantitative one. >>> =20 >>> >>[Kathie] I really feel the focus should be on a diffserv control plane >>for exactly your reasons. I think people like Olivier can perhaps >>try to keep us on track not to conflict with other control plane >>actions. >> >> =20 >> >>>Another question is related to the 'topology acquisition' item. This >>>means that you think that the control of resources within a DiffServ >>>network should be centralized in a "resource manager",=20 >>> =20 >>> >>which will then >> =20 >> >>>need to collect topology information? Since a PDB is=20 >>> =20 >>> >>already defined in >> =20 >> >>>a distributed way, why not allow the control of resources to be >>>distributed, with most of the operations being located at the edges? >>>This distributed approach brings the benefits of higher=20 >>> =20 >>> >>robustness and >> =20 >> >>>perhaps performance. >>> =20 >>> >>Hmm, I don't think topology acquisition necessarily means=20 >>"centralized". >>After all, routing protocols construct a topology and are distributed. >>I've been bothered by the characterization of bandwidth/resource >>manager style solutions as "centralized" where I would characterize >>them as "network-wide". I think of a diffserv control plane as being >>decoupled from the forwarding path but having the network=20 >>wide awareness >>needed to enforce a PDB (so it sounds like we agree here). The actual >>entity or entities that implement this can be as "centralized" or >>"distributed" as needed. >> =20 >> >>>In what concerns the other standardization efforts, I would=20 >>> =20 >>> >>say that it >> =20 >> >>>would help a lot this BoF, if we had a brief document=20 >>> =20 >>> >>characterizing the >> =20 >> >>>differences between all these approaches to see where this=20 >>> =20 >>> >>BoF would fit. >> >>Okay. Do you mean centralized vs distributed approaches to diffserv >>control plane? I would somewhat like to see if we can do something >>that can include all of that range, but perhaps that's not possible. >> >> Kathie >> >> >>_______________________________________________ >>Dcpel mailing list >>Dcpel@ietf.org >>https://www1.ietf.org/mailman/listinfo/dcpel >> >> =20 >> > >_______________________________________________ >Dcpel mailing list >Dcpel@ietf.org >https://www1.ietf.org/mailman/listinfo/dcpel > > =20 > _______________________________________________ Dcpel mailing list Dcpel@ietf.org https://www1.ietf.org/mailman/listinfo/dcpel From dcpel-bounces@ietf.org Wed Nov 02 15:21:55 2005 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EXP7L-00022L-7r; Wed, 02 Nov 2005 15:21:55 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EXP7I-000205-FX for dcpel@megatron.ietf.org; Wed, 02 Nov 2005 15:21:52 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA06316 for ; Wed, 2 Nov 2005 15:21:30 -0500 (EST) Received: from outbound.mailhop.org ([63.208.196.171] ident=mailnull) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EXPLw-0005Df-9F for dcpel@ietf.org; Wed, 02 Nov 2005 15:37:01 -0500 Received: from c-24-6-155-12.hsd1.ca.comcast.net ([24.6.155.12] helo=[10.1.1.74]) by outbound.mailhop.org with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.51) id 1EXP7A-000JnY-35 for dcpel@ietf.org; Wed, 02 Nov 2005 15:21:44 -0500 X-Mail-Handler: MailHop Outbound by DynDNS X-Originating-IP: 24.6.155.12 X-Report-Abuse-To: abuse@dyndns.com (see http://www.mailhop.org/outbound/abuse.html for abuse reporting information) X-MHO-User: kmnichols Message-ID: <43691FD7.3070608@pollere.com> Date: Wed, 02 Nov 2005 12:21:43 -0800 From: Kathleen Nichols User-Agent: Mozilla Thunderbird 1.0 (Macintosh/20041206) X-Accept-Language: en-us, en MIME-Version: 1.0 To: dcpel@ietf.org Subject: Re: [Dcpel] Dcpel BoF support References: In-Reply-To: X-Enigmail-Version: 0.90.1.0 X-Enigmail-Supports: pgp-inline, pgp-mime Content-Type: text/plain; charset=ISO-8859-15 X-Spam-Score: 0.1 (/) X-Scan-Signature: b19722fc8d3865b147c75ae2495625f2 Content-Transfer-Encoding: quoted-printable X-MIME-Autoconverted: from 8bit to quoted-printable by ietf.org id PAA06316 X-BeenThere: dcpel@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Mailing list for possible diffserv control plane elements WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: dcpel-bounces@ietf.org Errors-To: dcpel-bounces@ietf.org Attila B=E1der (IJ/ETH) wrote: .. > Dear all, as I understand the main goal of the working group would be > to identify and define elements for DiffServ-based resource manager > concept. >=20 We should spell this out better. It's really first to specify the elements we can use to build a diffserv control plane. This lets us figure out what we already have and what is still missing (in the standards sense). I believe this of necessity includes documenting some ways to use the control plane for operational control of some useful differentiated services. > I think that such concept should address inter-domain signaling as > well. Note that there is an NSIS a proposal for path-decoupled > signaling. If it gets through, NSIS could be used as protocol between > resource managers. Anyway it should be avoided that IETF develops two > protocols parallel for the same purpose. It looks like many folks want to look at inter-domain issues. I don't believe we should address the signaling protocol issue, but certainly there needs to be some element of the intra-domain CP that handles requests, including (or perhaps particularly) those from outside the domain. I think the emphasis would be on what kind of information would need to be extracted from those requests that would be necessary and useful to the diffserv CP. If NSIS has a protocol that fits the bill, great. If not, perhaps it's possible to add some options (as in Paulo's work) working in the NSIS WG. I absolutely agree that we would not want "parallel protocols" and, in fact, I think of developing a signaling protocols (which is a transport issue not an ops issue) as a definite non-item for this group. Kathie _______________________________________________ Dcpel mailing list Dcpel@ietf.org https://www1.ietf.org/mailman/listinfo/dcpel From dcpel-bounces@ietf.org Thu Nov 03 04:59:08 2005 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EXbsC-0000Cs-3R; Thu, 03 Nov 2005 04:59:08 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EXbsA-0000Cc-Bs for dcpel@megatron.ietf.org; Thu, 03 Nov 2005 04:59:06 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA18576 for ; Thu, 3 Nov 2005 04:58:45 -0500 (EST) Received: from mailgw3.ericsson.se ([193.180.251.60]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EXc6p-0000xh-KN for dcpel@ietf.org; Thu, 03 Nov 2005 05:14:22 -0500 Received: from esealmw129.eemea.ericsson.se (unknown [153.88.254.120]) by mailgw3.ericsson.se (Symantec Mail Security) with ESMTP id 0E89DE29; Thu, 3 Nov 2005 10:58:58 +0100 (CET) Received: from esealmw127.eemea.ericsson.se ([153.88.254.171]) by esealmw129.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Thu, 3 Nov 2005 10:58:48 +0100 Content-class: urn:content-classes:message Subject: RE: [Dcpel] Dcpel BoF support MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-15" Content-Transfer-Encoding: quoted-printable Date: Thu, 3 Nov 2005 10:58:48 +0100 Message-ID: X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Thread-Topic: [Dcpel] Dcpel BoF support Thread-Index: AcXf61gfg0YW4f6ORGS7MUVF6DGKJAAaL8eg From: =?iso-8859-15?Q?Attila_B=E1der_=28IJ/ETH=29?= To: "Kathleen Nichols" , "Paulo Mendes" , X-OriginalArrivalTime: 03 Nov 2005 09:58:48.0843 (UTC) FILETIME=[2FCC5DB0:01C5E05D] X-Brightmail-Tracker: AAAAAA== X-Spam-Score: 0.0 (/) X-Scan-Signature: c0bedb65cce30976f0bf60a0a39edea4 Content-Transfer-Encoding: quoted-printable Cc: X-BeenThere: dcpel@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Mailing list for possible diffserv control plane elements WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: dcpel-bounces@ietf.org Errors-To: dcpel-bounces@ietf.org Hi Kathie, Paolo, Ok, I see now better the scope. I am thinking that one of the potential = applications will be resource management within one or muliple Diffserv = domain(s).=20 Interdomain problem would be interesting because there is lack of = standard solutions. The needed elements depends very much on the = supporteed architecture and functions, so probably defining a concrete = solution cannot be avoided. NSIS may want to address this problem from = off-path signaling point of view, but there is not a concrete proposal = what architecture and which automatism it should support.=20 Best regards, Attila =20 > -----Original Message----- > From: dcpel-bounces@ietf.org [mailto:dcpel-bounces@ietf.org] > Sent: Wednesday, November 02, 2005 9:22 PM > To: dcpel@ietf.org > Subject: Re: [Dcpel] Dcpel BoF support >=20 >=20 > Attila B=E1der (IJ/ETH) wrote: > .. > > Dear all, as I understand the main goal of the working=20 > group would be > > to identify and define elements for DiffServ-based resource manager > > concept. > >=20 > We should spell this out better. It's really first to specify the > elements we can use to build a diffserv control plane. This lets > us figure out what we already have and what is still missing (in > the standards sense). I believe this of necessity includes documenting > some ways to use the control plane for operational control of > some useful differentiated services. >=20 > > I think that such concept should address inter-domain signaling as > > well. Note that there is an NSIS a proposal for path-decoupled > > signaling. If it gets through, NSIS could be used as=20 > protocol between > > resource managers. Anyway it should be avoided that IETF=20 > develops two > > protocols parallel for the same purpose. >=20 > It looks like many folks want to look at inter-domain issues. I don't > believe we should address the signaling protocol issue, but certainly > there needs to be some element of the intra-domain CP that handles > requests, including (or perhaps particularly) those from outside the > domain. I think the emphasis would be on what kind of=20 > information would > need to be extracted from those requests that would be necessary and > useful to the diffserv CP. If NSIS has a protocol that fits the bill, > great. If not, perhaps it's possible to add some options (as=20 > in Paulo's > work) working in the NSIS WG. I absolutely agree that we would not > want "parallel protocols" and, in fact, I think of developing a > signaling protocols (which is a transport issue not an ops issue) > as a definite non-item for this group. >=20 > Kathie >=20 > _______________________________________________ > Dcpel mailing list > Dcpel@ietf.org > https://www1.ietf.org/mailman/listinfo/dcpel >=20 _______________________________________________ Dcpel mailing list Dcpel@ietf.org https://www1.ietf.org/mailman/listinfo/dcpel From dcpel-bounces@ietf.org Fri Nov 04 18:50:02 2005 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EYBJq-0007QD-4Q; Fri, 04 Nov 2005 18:50:02 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EYBJn-0007PR-HW; Fri, 04 Nov 2005 18:49:59 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA22459; Fri, 4 Nov 2005 18:49:36 -0500 (EST) Received: from outbound.mailhop.org ([63.208.196.171] ident=mailnull) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EYBYt-000725-1L; Fri, 04 Nov 2005 19:05:35 -0500 Received: from c-24-6-155-12.hsd1.ca.comcast.net ([24.6.155.12] helo=[10.1.1.74]) by outbound.mailhop.org with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.51) id 1EYBJh-0003p6-9C; Fri, 04 Nov 2005 18:49:53 -0500 X-Mail-Handler: MailHop Outbound by DynDNS X-Originating-IP: 24.6.155.12 X-Report-Abuse-To: abuse@dyndns.com (see http://www.mailhop.org/outbound/abuse.html for abuse reporting information) X-MHO-User: kmnichols Message-ID: <436BF3A4.4050707@pollere.com> Date: Fri, 04 Nov 2005 15:49:56 -0800 From: Kathleen Nichols User-Agent: Thunderbird 1.4.1 (Macintosh/20051006) MIME-Version: 1.0 To: tsvwg@ietf.org X-Enigmail-Version: 0.93.0.0 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.1 (/) X-Scan-Signature: 17bdfcaea25d1444baef0e24abc38874 Content-Transfer-Encoding: 7bit Cc: dcpel@ietf.org, diffserv-interest-request@ietf.org Subject: [Dcpel] draft-ietf-tsvwg-diffserv-service-classes-01 WGLC X-BeenThere: dcpel@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Mailing list for possible diffserv control plane elements WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: dcpel-bounces@ietf.org Errors-To: dcpel-bounces@ietf.org My concerns with this document haven't changed much from the comments I had for the authors on the original version. My major concern is that this draft rewrites many concepts that were crafted by consensus over several years in the DiffServ WG and are currently in use. Certainly, concepts and standards have to be revisited from time to time, but this draft is not being explicit about it. At the very least, this should be made clear both in the document and by the ADs, particularly since some of it is at odds with RFC2474, a standards track document. Concern 1: This draft ties "service class" to applications and to specific PHBs in all networks. This draft defines a "service class" as: "a set of traffic that requires specific delay, loss and jitter characteristics from the network for which a consistent and defined per-hop behavior (PHB) [RFC2474] applies. Conceptually, a service class pertains to applications with similar characteristics and performance requirements, such as a 'High Throughput Data' service class for applications like the web and electronic mail, or a 'Telephony' service class for real-time traffic such as voice and other telephony services." This links *applications* to requirements for specific delay, loss and jitter characteristic which is counter to the internet history of building applications that adapt to network conditions. The point of DiffServ was to provide tools to make it possible to differentiate traffic on whatever basis an operator desired, to not require that inner workings of a network be exposed, and not to require a particular PHB. If an operator can deliver certain specified treatments (in SLSs) to traffic across its network, it was considered its business what PHB and edge treatments were used. See RFC2475: "Service differentiation is desired to accommodate heterogeneous application requirements and user expectations, and to permit differentiated pricing of Internet service." and "A distinction is maintained between: o the service provided to a traffic aggregate, o the conditioning functions and per-hop behaviors used to realize services, o the DS field value (DS codepoint) used to mark packets to select a per-hop behavior, and o the particular node implementation mechanisms which realize a per-hop behavior. Service provisioning and traffic conditioning policies are sufficiently decoupled from the forwarding behaviors within the network interior to permit implementation of a wide variety of service behaviors, with room for future expansion." but this draft would erase that distinction, and (more RFC2475): "The following requirements were identified and are addressed in this architecture: o should accommodate a wide variety of services and provisioning policies, extending end-to-end or within a particular (set of) network(s), o should allow decoupling of the service from the particular application in use, ... o should decouple traffic conditioning and service provisioning functions from forwarding behaviors implemented within the core network nodes," Again DiffServ was explicit about the decoupling of services and applications. Concern 2: The definition of Service Class and its relationship to traffic aggregates. From RFC 2474: "Services are realized by the use of particular packet classification and traffic conditioning mechanisms at boundaries coupled with the concatenation of per-hop behaviors along the transit path of the traffic. A goal of the differentiated services architecture is to specify these building blocks for future extensibility, both of the number and type of the building blocks and of the services built from them." and the definition from standards track RFC2474: "Service: a description of the overall treatment of (a subset of) a customer's traffic across a particular domain, across a set of interconnected DS domains, or end-to-end. Service descriptions are covered by administrative policy and services are constructed by applying traffic conditioning to create behavior aggregates which experience a known PHB at each node within the DS domain. Multiple services can be supported by a single per-hop behavior used in concert with a range of traffic conditioners. To summarize, classifiers and traffic conditioners are used to select which packets are to be added to behavior aggregates. Aggregates receive differentiated treatment in a DS domain and traffic conditioners MAY alter the temporal characteristics of the aggregate to conform to some requirements. A packet's DS field is used to designate the packet's behavior aggregate and is subsequently used to determine which forwarding treatment the packet receives." This is turned inside out by this draft which talks about traffic aggregates as though they were traffic streams, as defined by RFC 2475, and invariant under edge conditioning and aggregation that must of necessity occur inside any non-trivial network. The effects of aggregation and the need to design PDBs and services to be careful of these is discussed in RFC3086, reflecting DiffServ WG discussions. First, from RFC 2475: "Traffic stream an administratively significant set of one or more microflows which traverse a path segment. A traffic stream may consist of the set of active microflows which are selected by a particular classifier." From the draft: "A Service Class as defined here is essentially a statement of the required characteristics of a traffic aggregate; the actual specification of the expected treatment of a traffic aggregate within a domain may also be defined as a Per Domain Behavior [RFC3086]." This is the only place in the draft where RFC 3086, a product of the DiffServ WG is mentioned. (There was no mention in the original.) From RFC 3086's abstract, giving context for this RFC: "The next step is to formulate examples of how forwarding path components (PHBs, classifiers, and traffic conditioners) can be used to compose traffic aggregates whose packets experience specific forwarding characteristics as they transit a differentiated services domain. The WG has decided to use the term per-domain behavior, or PDB, to describe the behavior experienced by a particular set of packets as they cross a DS domain." and from RFC 3086's Introduction: "Diffserv classification and traffic conditioning are applied to packets arriving at the boundary of a DS domain to impose restrictions on the composition of the resultant traffic aggregates, as distinguished by the DSCP marking, inside the domain. The classifiers and traffic conditioners are set to reflect the policy and traffic goals for that domain and may be specified in a TCA (Traffic Conditioning Agreement). Once packets have crossed the DS boundary, adherence to diffserv principles makes it possible to group packets solely according to the behavior they receive at each hop (as selected by the DSCP). This approach has well-known scaling advantages, both in the forwarding path and in the control plane. Less well recognized is that these scaling properties only result if the per-hop behavior definition gives rise to a particular type of invariance under aggregation. Since the per-hop behavior must be equivalent for every node in the domain, while the set of packets marked for that PHB may be different at every node, PHBs should be defined such that their characteristics do not depend on the traffic volume of the associated BA on a router's ingress link nor on a particular path through the DS domain taken by the packets. Specifically, different streams of traffic that belong to the same traffic aggregate merge and split as they traverse the network. If the properties of a PDB using a particular PHB hold regardless of how the temporal characteristics of the marked traffic aggregate change as it traverses the domain, then that PDB scales. " A per-hop behavior, which is just how a packet is forwarded at each node, cannot directly result in a particular end-to-end, or even edge-to-edge set of characteristics since it is dependent on how much traffic is admitted and how traffic is mixed and so on. Which brings me to: Concern 3: draft seems to equate requiring a uniform PHB with achieving an end-to-end QoS. Contrast this with the RFC 2475 and 3086 approaches of having each network domain specify the loss rate, maximum delay, and/or other metrics which it will provide to traffic streams that conform to certain agreed-upon (via SLS) behavior (e.g., interface, markings, rate). Though work remains on how to put the values from a chain of networks together, it is certain possible to figure out the maximum delay through a set of networks with services so specified. At the same time, nothing need be known about network internals. If I am told that a traffic stream will be priority queued at every router between two points, I am told nothing about the maximum delay the packets will experience. In section 1.5.3 of the draft, "Expedited Forwarding PHB [RFC3246] behavior was originally proposed as a way to implement a virtual wire, and can be used in such a manner." The EF PHB was originally proposed as a *building block* to create a service (then called virtual leased line) and both the original proposal in RFC 2598 and the update in RFC 3246 were quite clear about this. From RFC 2598: The EF PHB can be used to build a low loss, low latency, low jitter, assured bandwidth, end-to-end service through DS domains. Such a service appears to the endpoints like a point-to- point connection or a "virtual leased line". ... Creating such a service has two parts: 1) Configuring nodes so that the aggregate has a well-defined minimum departure rate. ("Well-defined" means independent of the dynamic state of the node. In particular, independent of the intensity of other traffic at the node.) 2) Conditioning the aggregate (via policing and shaping) so that its arrival rate at any node is always less than that node's configured minimum departure rate. The EF PHB provides the first part of the service. The network boundary traffic conditioners described in [RFC2475] provide the second part. From RFC 3246: "The intent of the EF PHB is to provide a building block for low loss, low delay, and low jitter services. The details of exactly how to build such services are outside the scope of this specification." and "Note that the EF PHB only defines the behavior of a single node. The specification of behavior of a collection of nodes is outside the scope of this document. A Per-Domain Behavior (PDB) specification [7] may provide such information." These DiffServ documents were clear that a PHB does not a service make. Finally, the draft specifies a lot of operational rules for networks. This is inverted from the DiffServ WG approach of putting tools into the hands of operators. Kathie Nichols _______________________________________________ Dcpel mailing list Dcpel@ietf.org https://www1.ietf.org/mailman/listinfo/dcpel From dcpel-bounces@ietf.org Sat Nov 05 07:07:51 2005 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EYMpr-00083J-3Y; Sat, 05 Nov 2005 07:07:51 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EYMpp-00083E-QR for dcpel@megatron.ietf.org; Sat, 05 Nov 2005 07:07:49 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA27288 for ; Sat, 5 Nov 2005 07:07:24 -0500 (EST) Received: from mail17.bluewin.ch ([195.186.18.64]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EYN50-0008DC-QS for Dcpel@ietf.org; Sat, 05 Nov 2005 07:23:32 -0500 Received: from malix.martel-consulting.ch (83.77.68.171) by mail17.bluewin.ch (Bluewin 7.2.068.1) id 435E00F800232B24 for Dcpel@ietf.org; Sat, 5 Nov 2005 12:07:26 +0000 Message-Id: <6.2.3.4.2.20051105125251.01e29798@mail.tiscali.ch> X-Mailer: QUALCOMM Windows Eudora Version 6.2.3.4 Date: Sat, 05 Nov 2005 13:06:10 +0100 To: Dcpel@ietf.org From: Martin Potts Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-Spam-Score: 0.0 (/) X-Scan-Signature: de4f315c9369b71d7dd5909b42224370 Cc: Subject: [Dcpel] Support for BoF X-BeenThere: dcpel@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Mailing list for possible diffserv control plane elements WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: dcpel-bounces@ietf.org Errors-To: dcpel-bounces@ietf.org Dear Kathie, all, I cannot be in VA but, as an EuQoS (www.euqos.org) project member, I wish to add my support for this BoF. The basic tools for supporting QoS in the Internet have been around now for about 15 years, but only isolated and non-compatible implementations have been deployed. The increasing interest for Triple Play and IPTV (for example) is sufficient motivation to provide ISPs with a commonly accepted approach to QoS handling. Worldwide acceptance of such a solution with finally enable the support of end-to-end (global) Internet-based services requiring QoS, thereby opening up new opportunities for network providers, service providers, equipment manufacturers and end-users. Regards, Martin _______________________________________________ Dcpel mailing list Dcpel@ietf.org https://www1.ietf.org/mailman/listinfo/dcpel From dcpel-bounces@ietf.org Sun Nov 06 00:10:40 2005 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EYcng-00086w-J6; Sun, 06 Nov 2005 00:10:40 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EYcnf-00086k-3a for dcpel@megatron.ietf.org; Sun, 06 Nov 2005 00:10:39 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA08818 for ; Sun, 6 Nov 2005 00:10:14 -0500 (EST) Received: from outbound.mailhop.org ([63.208.196.171] ident=mailnull) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EYd2z-00050m-E6 for dcpel@ietf.org; Sun, 06 Nov 2005 00:26:30 -0500 Received: from c-24-6-155-12.hsd1.ca.comcast.net ([24.6.155.12] helo=[10.1.1.74]) by outbound.mailhop.org with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.51) id 1EYcnY-000MHq-Oj for dcpel@ietf.org; Sun, 06 Nov 2005 00:10:32 -0500 X-Mail-Handler: MailHop Outbound by DynDNS X-Originating-IP: 24.6.155.12 X-Report-Abuse-To: abuse@dyndns.com (see http://www.mailhop.org/outbound/abuse.html for abuse reporting information) X-MHO-User: kmnichols Message-ID: <436D9049.2080906@pollere.com> Date: Sat, 05 Nov 2005 21:10:33 -0800 From: Kathleen Nichols User-Agent: Thunderbird 1.4.1 (Macintosh/20051006) MIME-Version: 1.0 To: dcpel@ietf.org Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.1 (/) X-Scan-Signature: 6d62ab47271805379d7172ee693a45db Content-Transfer-Encoding: 7bit Subject: [Dcpel] a draft of an I-D on requirements X-BeenThere: dcpel@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Mailing list for possible diffserv control plane elements WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: dcpel-bounces@ietf.org Errors-To: dcpel-bounces@ietf.org Paulo Mendes has put this together. I've put it up at www.pollere.com->resources for comment. Kathie _______________________________________________ Dcpel mailing list Dcpel@ietf.org https://www1.ietf.org/mailman/listinfo/dcpel From dcpel-bounces@ietf.org Sun Nov 06 19:22:31 2005 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EYumN-0008Cp-7v; Sun, 06 Nov 2005 19:22:31 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EYumM-0008Ck-44 for dcpel@megatron.ietf.org; Sun, 06 Nov 2005 19:22:30 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA29142 for ; Sun, 6 Nov 2005 19:22:04 -0500 (EST) Received: from mailgw2a.lmco.com ([192.91.147.7]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EYv1o-0000uF-6Q for dcpel@ietf.org; Sun, 06 Nov 2005 19:38:31 -0500 Received: from emss01g01.ems.lmco.com (relay1.ems.lmco.com [129.197.181.54]) by mailgw2a.lmco.com (8.12.10/8.12.10) with ESMTP id jA70MNhq023581 for ; Sun, 6 Nov 2005 19:22:23 -0500 (EST) Received: from CONVERSION-DAEMON.lmco.com by lmco.com (PMDF V6.1-1X6 #30875) id <0IPK00D016DB2O@lmco.com> for dcpel@ietf.org; Sun, 06 Nov 2005 16:22:23 -0800 (PST) Received: from EMSS01I00.us.lmco.com ([129.197.181.70]) by lmco.com (PMDF V6.1-1X6 #30875) with ESMTP id <0IPK007C26D96V@lmco.com> for dcpel@ietf.org; Sun, 06 Nov 2005 16:22:21 -0800 (PST) Received: from EMSS01M10.us.lmco.com ([129.197.181.75]) by EMSS01I00.us.lmco.com with Microsoft SMTPSVC(5.0.2195.6713); Sun, 06 Nov 2005 16:22:22 -0800 Date: Sun, 06 Nov 2005 16:22:21 -0800 From: "Pulliam, Jeffrey S" Subject: [Dcpel] informal working lunch at the Westin To: dcpel@ietf.org Message-id: MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft Exchange V6.0.6603.0 Content-type: text/plain; charset=utf-8 Content-transfer-encoding: 7BIT Thread-Topic: [Dcpel] a draft of an I-D on requirements Thread-Index: AcXikJjkeodKEP2WS6umtHhJ7PueyQAoEYWY content-class: urn:content-classes:message X-OriginalArrivalTime: 07 Nov 2005 00:22:22.0054 (UTC) FILETIME=[521E3060:01C5E331] X-Spam-Score: 0.0 (/) X-Scan-Signature: ffa9dfbbe7cc58b3fa6b8ae3e57b0aa3 Content-Transfer-Encoding: 7BIT X-BeenThere: dcpel@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Mailing list for possible diffserv control plane elements WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: dcpel-bounces@ietf.org Errors-To: dcpel-bounces@ietf.org I booked a room at the Westin, and will finalize arrangements tomorrow morning - but we should have the MacKenzie room for lunch on Tuesday for any interested in informal follow up on DCPEl issues. I have lunch coming in at 11:30 (sandwiches) for anyone interested in followup. Will offer again at the open session. Jeff Pulliam (408)219 8836 -----Original Message----- From: dcpel-bounces@ietf.org on behalf of Kathleen Nichols Sent: Sat 11/5/2005 9:10 PM To: dcpel@ietf.org Cc: Subject: [Dcpel] a draft of an I-D on requirements Paulo Mendes has put this together. I've put it up at www.pollere.com->resources for comment. Kathie _______________________________________________ Dcpel mailing list Dcpel@ietf.org https://www1.ietf.org/mailman/listinfo/dcpel _______________________________________________ Dcpel mailing list Dcpel@ietf.org https://www1.ietf.org/mailman/listinfo/dcpel From dcpel-bounces@ietf.org Mon Nov 07 23:12:26 2005 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EZKqQ-0003eR-OT; Mon, 07 Nov 2005 23:12:26 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EZKqP-0003eM-HA for dcpel@megatron.ietf.org; Mon, 07 Nov 2005 23:12:25 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA08263 for ; Mon, 7 Nov 2005 23:11:59 -0500 (EST) Received: from outbound.mailhop.org ([63.208.196.171] ident=mailnull) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EZL68-0005wf-By for dcpel@ietf.org; Mon, 07 Nov 2005 23:28:41 -0500 Received: from pp107-106.bctel.ca ([209.52.107.106]) by outbound.mailhop.org with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.51) id 1EZKqH-000IRd-4E for dcpel@ietf.org; Mon, 07 Nov 2005 23:12:17 -0500 X-Mail-Handler: MailHop Outbound by DynDNS X-Originating-IP: 209.52.107.106 X-Report-Abuse-To: abuse@dyndns.com (see http://www.mailhop.org/outbound/abuse.html for abuse reporting information) X-MHO-User: kmnichols Message-ID: <4370259F.2010905@pollere.com> Date: Mon, 07 Nov 2005 20:12:15 -0800 From: Kathleen Nichols User-Agent: Thunderbird 1.4.1 (Macintosh/20051006) MIME-Version: 1.0 To: dcpel@ietf.org Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.1 (/) X-Scan-Signature: de4f315c9369b71d7dd5909b42224370 Content-Transfer-Encoding: 7bit Subject: [Dcpel] moving into a diffserv control plane X-BeenThere: dcpel@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Mailing list for possible diffserv control plane elements WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: dcpel-bounces@ietf.org Errors-To: dcpel-bounces@ietf.org So I think we should have made it clear today in our session in the ops area that it was NOT a BoF and as it was not a BoF, we thought it would be good to try to elicit more ideas in the area so that we (collectively) could develop a BoF proposal. When the DiffServ WG got started (and indeed as is stated in the initial WG RFCs) the analogy was made to the separation of forwarding path and control plane as was originally done in the development of the internet. So we figured that the forwarding path diffserv mechanisms would initially be deployed in a static way (like static routes). But it seems like now it is time to move on to the diffserv control plane equivalent of RIP. How do we want to dynamically change the edge of a diffserv domain to reflect policies and conditions as they evolve? Kathie _______________________________________________ Dcpel mailing list Dcpel@ietf.org https://www1.ietf.org/mailman/listinfo/dcpel From dcpel-bounces@ietf.org Tue Nov 08 06:25:40 2005 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EZRbg-0003cU-Bo; Tue, 08 Nov 2005 06:25:40 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EZRbe-0003a8-Um for dcpel@megatron.ietf.org; Tue, 08 Nov 2005 06:25:39 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA29536 for ; Tue, 8 Nov 2005 06:25:12 -0500 (EST) Received: from mailgw2a.lmco.com ([192.91.147.7]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EZRrO-0000B5-9Q for dcpel@ietf.org; Tue, 08 Nov 2005 06:41:58 -0500 Received: from emss01g01.ems.lmco.com (relay1.ems.lmco.com [129.197.181.54]) by mailgw2a.lmco.com (8.12.10/8.12.10) with ESMTP id jA8BPOhq016859; Tue, 8 Nov 2005 06:25:24 -0500 (EST) Received: from CONVERSION-DAEMON.lmco.com by lmco.com (PMDF V6.1-1X6 #30875) id <0IPM00J01VQC52@lmco.com>; Tue, 08 Nov 2005 03:25:24 -0800 (PST) Received: from EMSS01I00.us.lmco.com ([129.197.181.70]) by lmco.com (PMDF V6.1-1X6 #30875) with ESMTP id <0IPM00C6EVQB8A@lmco.com>; Tue, 08 Nov 2005 03:25:23 -0800 (PST) Received: from EMSS01M10.us.lmco.com ([129.197.181.75]) by EMSS01I00.us.lmco.com with Microsoft SMTPSVC(5.0.2195.6713); Tue, 08 Nov 2005 03:25:24 -0800 Date: Tue, 08 Nov 2005 03:25:24 -0800 From: "Pulliam, Jeffrey S" Subject: [Dcpel] Purpose of a diffserv control plane To: Kathleen Nichols , dcpel@ietf.org Message-id: MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft Exchange V6.0.6603.0 Content-type: text/plain; charset=Windows-1252 Content-transfer-encoding: 7BIT Thread-Topic: [Dcpel] moving into a diffserv control plane Thread-Index: AcXkKrCmwHJVr9f/QCalkivtUFdizQAIw4wt content-class: urn:content-classes:message X-OriginalArrivalTime: 08 Nov 2005 11:25:24.0296 (UTC) FILETIME=[1C985480:01C5E457] X-Spam-Score: 0.0 (/) X-Scan-Signature: ffa9dfbbe7cc58b3fa6b8ae3e57b0aa3 Content-Transfer-Encoding: 7BIT Cc: X-BeenThere: dcpel@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Mailing list for possible diffserv control plane elements WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: dcpel-bounces@ietf.org Errors-To: dcpel-bounces@ietf.org A couple of things - - For those interested in follow up, I want to repeat the offer of lunch at the IETF on Tuesday November 8 at 11:30 - in the MacKenzie room. The room is on the first floor near the meeting registration tables. - In hopes of starting a discussion, I would like to try out the following as a starting position for discussion: The purpose of a diffserv control plane is to provide automated control of the diffserv domain, governed and constrained by policy. Control functions configure the diffserv domain to deliver services in response to requests. Requests to the control function are made by users, network operations, and network management. The control plane contains necessary rules and logic to respond to the requests automatically, with resulting actions including actions to configure the network to accept (or reject) the request, and actions to respond to the requestor with status of the request. Request can originate internal to the diffserv domain, or originate from other network domains. Actions in response to the requests are either actions affecting the internal diffserv domains, or are actions that cross domain boundaries (in the form of requests?). A quick and dirty simple picture showing the contexts (lots of room for improvement). Requestors Control Actions *********** User<------>* *<----->Network Configuration * Control * Net Op<---->* Plane * * *<----->Response to Requestor Net mgt<--->*********** What is the role, functions, and constraints of signaling within the diffserv domain? I would like to revise (or replace) the above to accurately reflect the role of signaling within a diffserv domain. Suggestions? Jeff Pulliam _______________________________________________ Dcpel mailing list Dcpel@ietf.org https://www1.ietf.org/mailman/listinfo/dcpel From dcpel-bounces@ietf.org Tue Nov 08 13:23:57 2005 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EZY8T-0005nS-0t; Tue, 08 Nov 2005 13:23:57 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EZY8Q-0005kP-O2 for dcpel@megatron.ietf.org; Tue, 08 Nov 2005 13:23:56 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA23909 for ; Tue, 8 Nov 2005 13:23:28 -0500 (EST) Received: from cedar.ugent.be ([157.193.49.14]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EZYOF-0003uj-TB for dcpel@ietf.org; Tue, 08 Nov 2005 13:40:18 -0500 Received: from localhost (localhost.localdomain [127.0.0.1]) by cedar.UGent.be (Postfix) with ESMTP id 0018C1933B9 for ; Tue, 8 Nov 2005 19:23:48 +0100 (CET) Received: from cedar.UGent.be ([127.0.0.1]) by localhost (bonobo.UGent.be [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 22715-01 for ; Tue, 8 Nov 2005 19:23:45 +0100 (CET) Received: from plinius.intec.ugent.be (plinius.intec2.rug.ac.be [157.193.214.4]) by cedar.UGent.be (Postfix) with ESMTP id 226661933AF for ; Tue, 8 Nov 2005 19:23:45 +0100 (CET) Received: from localhost (localhost [127.0.0.1]) by plinius.intec.ugent.be (Postfix) with ESMTP id C1C31BD54; Tue, 8 Nov 2005 19:23:46 +0100 (CET) Received: from [192.168.1.14] (svdberg.vpn [192.168.1.14]) by plinius.intec.ugent.be (Postfix) with ESMTP id 1F141BD53; Tue, 8 Nov 2005 19:23:46 +0100 (CET) From: Steven Van den Berghe Organization: Ghent University To: dcpel@ietf.org Subject: Re: [Dcpel] Purpose of a diffserv control plane Date: Tue, 8 Nov 2005 19:23:38 +0100 User-Agent: KMail/1.7.1 References: In-Reply-To: MIME-Version: 1.0 Message-Id: <200511081923.40828.steven.vandenberghe@intec.ugent.be> X-Virus-Scanned: by AMaViS snapshot-20020222 X-Virus-Scanned: by UGent DICT X-Spam-Score: 0.0 (/) X-Scan-Signature: 287c806b254c6353fcb09ee0e53bbc5e X-BeenThere: dcpel@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Mailing list for possible diffserv control plane elements WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============2113516366==" Sender: dcpel-bounces@ietf.org Errors-To: dcpel-bounces@ietf.org --===============2113516366== Content-Type: multipart/signed; boundary="nextPart3437043.UJWlDkEPVr"; protocol="application/pgp-signature"; micalg=pgp-sha1 Content-Transfer-Encoding: 7bit --nextPart3437043.UJWlDkEPVr Content-Type: text/plain; charset="windows-1252" Content-Disposition: inline Content-Transfer-Encoding: quoted-printable Thanks to some timezone difficulties, i had some time this morning to refle= ct=20 on the results of the ops area meeting and tried to identify some interesti= ng=20 things that would be useful for dcpel to work on, and aren't afaik tackled = in=20 the related WGs (NSIS etc).=20 One thing that came to mind was differentiated admission control (or contro= l=20 plane service differentiation): although services at the dataplane are=20 identified by their codepoint, several higher level services could use this= =20 DSCP-identified transport (e.g. you could have an EF dataplane connectivity= =20 for multimedia services, but with a business/residential user differentiati= on=20 at the control plane). I used to play around with a few of these things a while ago (in a TE=20 environment, but it is probably marginally applicable to dcpel too). The id= ea=20 was to introduce the concept of a QoS-session, using XACML as a service=20 description and access mechanism. Some slides on this work can be found on: http://www.policy-workshop.org/2004/slides/Berghe-SonarPolicy04.pdf Regards, Steven On Tuesday 08 November 2005 12:25, Pulliam, Jeffrey S wrote: > A couple of things - > > - For those interested in follow up, I want to repeat the offer of lunch = at > the IETF on Tuesday November 8 at 11:30 - in the MacKenzie room. The room > is on the first floor near the meeting registration tables. > > - In hopes of starting a discussion, I would like to try out the following > as a starting position for discussion: > > The purpose of a diffserv control plane is to provide automated control of > the diffserv domain, governed and constrained by policy. Control functio= ns > configure the diffserv domain to deliver services in response to requests= =2E=20 > Requests to the control function are made by users, network operations, a= nd > network management. The control plane contains necessary rules and log= ic > to respond to the requests automatically, with resulting actions including > actions to configure the network to accept (or reject) the request, and > actions to respond to the requestor with status of the request. > > Request can originate internal to the diffserv domain, or originate from > other network domains. Actions in response to the requests are either > actions affecting the internal diffserv domains, or are actions that cross > domain boundaries (in the form of requests?). A quick and dirty simple > picture showing the contexts (lots of room for improvement). > > Requestors Control Actions > > *********** > User<------>* *<----->Network Configuration > * Control * > Net Op<---->* Plane * > * *<----->Response to Requestor > Net mgt<--->*********** > > What is the role, functions, and constraints of signaling within the > diffserv domain? I would like to revise (or replace) the above to > accurately reflect the role of signaling within a diffserv domain. > > Suggestions? > > Jeff Pulliam > > > > _______________________________________________ > Dcpel mailing list > Dcpel@ietf.org > https://www1.ietf.org/mailman/listinfo/dcpel =2D-=20 Steven Van den Berghe Department of Information Technology Ghent University - IBBT - IMEC http://www.ibcn.intec.ugent.be Tel: +32 (0) 9 331 49 73 =46ax: +32 (0) 9 331 48 99 --nextPart3437043.UJWlDkEPVr Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.4 (GNU/Linux) iD8DBQBDcO0sOe05O+wjKOwRAv5IAJ9Huy3g6Glh12hjauTX6guDmbHd5ACfYu+X qRi3k4wJhYoUQxxwbjx2PrE= =4/1e -----END PGP SIGNATURE----- --nextPart3437043.UJWlDkEPVr-- --===============2113516366== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Dcpel mailing list Dcpel@ietf.org https://www1.ietf.org/mailman/listinfo/dcpel --===============2113516366==-- From dcpel-bounces@ietf.org Tue Nov 08 13:29:16 2005 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EZYDc-0006il-1X; Tue, 08 Nov 2005 13:29:16 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EZYDa-0006id-Tq for dcpel@megatron.ietf.org; Tue, 08 Nov 2005 13:29:15 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA24232 for ; Tue, 8 Nov 2005 13:28:48 -0500 (EST) Received: from rsys001x.roke.co.uk ([193.118.201.108]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EZYTP-00042e-28 for dcpel@ietf.org; Tue, 08 Nov 2005 13:45:38 -0500 Received: from rsys005a.comm.ad.roke.co.uk ([193.118.193.85]) by rsys001x.roke.co.uk (8.12.8/8.12.8) with ESMTP id jA8ISbWA019656; Tue, 8 Nov 2005 18:28:37 GMT X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Received: from ac78840 (orion.roke.co.uk [193.118.192.66]) by rsys002a.roke.co.uk with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2657.72) id VGTHY1X8; Tue, 8 Nov 2005 18:33:27 -0000 MIME-Version: 1.0 Content-class: urn:content-classes:message Subject: RE: [Dcpel] Purpose of a diffserv control plane Date: Tue, 8 Nov 2005 18:28:28 -0000 Message-ID: <00ba01c5e492$39d1b510$b66c34d1@comm.ad.roke.co.uk> Thread-Topic: [Dcpel] Purpose of a diffserv control plane Thread-Index: AcXkkulgz1x4zWgwSPWPdjPNRAyQug== From: "Hancock, Robert" To: "Pulliam, Jeffrey S" , "Kathleen Nichols" , X-MailScanner-rsys001x: Found to be clean X-MailScanner-From: robert.hancock@roke.co.uk X-Spam-Score: 0.5 (/) X-Scan-Signature: cd3d702b63698072ba67a75ce9e0fc9e Cc: X-BeenThere: dcpel@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Mailing list for possible diffserv control plane elements WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============1977883033==" Sender: dcpel-bounces@ietf.org Errors-To: dcpel-bounces@ietf.org This is a multi-part message in MIME format. --===============1977883033== Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C5E492.E8ADF580" Content-class: urn:content-classes:message This is a multi-part message in MIME format. ------_=_NextPart_001_01C5E492.E8ADF580 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Hi Jeff, Kathie, I think the problem that I am having (and maybe some others) in following this discussion is that the problem scope is potentially so enormous that it is difficult to work out how to start=20 discussing it, and commonplace for discussions to proceed at cross purposes because people are talking about different bits of it. Kathie's prior mail described this activity as the diffserv analogy of moving from static routes to RIP. However, if the model is of network-level controller nodes which manage groups of routers, a closer analogy (to my mind) would be moving from static routes to inter-domain MPLS. (I'm not saying this approach is wrong, just=20 trying to stress that it is quite a leap.) There is also a = terminological problem, that words like 'signaling' or 'control function' mean very specific things to some people, but to others are extremely=20 broad. My very crude take on what Jeff describes below is that one can=20 imagine 5 different components to the problem, i.e. 1) a language for describing the services that are requested 2) logic for deciding whether and how to implement the requests 3) a protocol mechanism for initiating requests with domains and carrying requests between them 4) interaction with AAA (especially authorisation/accounting)=20 functions to support the decision process 5) protocol mechanisms to implement the decision in the forwarding plane Now my question is whether the purpose of DCPEL is to work specifically on some or all of these, or whether initially it is to work on understanding how they fit together (or on some similar decomposition). Note that at least (3), (4) and (5) could all be described as=20 'signalling', and (2)-(4) as 'control functions'; OTOH I got the impression last night (maybe incorrectly) that Scott at least was=20 mainly interested in (1). Or have I missed the point entirely? Robert H. ps. see you at lunch :-) > -----Original Message----- > From: dcpel-bounces@ietf.org [mailto:dcpel-bounces@ietf.org]=20 > On Behalf Of Pulliam, Jeffrey S > Sent: 08 November 2005 03:25 > To: Kathleen Nichols; dcpel@ietf.org > Subject: [Dcpel] Purpose of a diffserv control plane >=20 >=20 > A couple of things -=20 >=20 > - For those interested in follow up, I want to repeat the=20 > offer of lunch at the IETF on Tuesday November 8 at 11:30 -=20 > in the MacKenzie room. The room is on the first floor near=20 > the meeting registration tables. =20 >=20 > - In hopes of starting a discussion, I would like to try out=20 > the following as a starting position for discussion: >=20 > The purpose of a diffserv control plane is to provide=20 > automated control of the diffserv domain, governed and=20 > constrained by policy. Control functions configure the=20 > diffserv domain to deliver services in response to requests. =20 > Requests to the control function are made by users, network=20 > operations, and network management. The control plane=20 > contains necessary rules and logic to respond to the=20 > requests automatically, with resulting actions including=20 > actions to configure the network to accept (or reject) the=20 > request, and actions to respond to the requestor with status=20 > of the request. >=20 > Request can originate internal to the diffserv domain, or=20 > originate from other network domains. Actions in response to=20 > the requests are either actions affecting the internal=20 > diffserv domains, or are actions that cross domain boundaries=20 > (in the form of requests?). A quick and dirty simple picture=20 > showing the contexts (lots of room for improvement). > =20 > Requestors Control Actions >=20 > *********** > User<------>* *<----->Network Configuration > * Control * > Net Op<---->* Plane * > * *<----->Response to Requestor > Net mgt<--->*********** >=20 > What is the role, functions, and constraints of signaling=20 > within the diffserv domain? I would like to revise (or=20 > replace) the above to accurately reflect the role of=20 > signaling within a diffserv domain. =20 >=20 > Suggestions? >=20 > Jeff Pulliam >=20 >=20 >=20 > _______________________________________________ > Dcpel mailing list > Dcpel@ietf.org > https://www1.ietf.org/mailman/listinfo/dcpel >=20 ------_=_NextPart_001_01C5E492.E8ADF580 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable RE: [Dcpel] Purpose of a diffserv control plane

Hi Jeff, Kathie,

I think the problem that I am having (and maybe some = others) in
following this discussion is that the problem scope = is potentially
so enormous that it is difficult to work out how to = start
discussing it, and commonplace for discussions to = proceed at cross
purposes because people are talking about different = bits of it.

Kathie's prior mail described this activity as the = diffserv analogy
of moving from static routes to RIP. However, if the = model is of
network-level controller nodes which manage groups of = routers, a
closer analogy (to my mind) would be moving from = static routes to
inter-domain MPLS. (I'm not saying this approach is = wrong, just
trying to stress that it is quite a leap.) There is = also a terminological
problem, that words like 'signaling' or 'control = function' mean
very specific things to some people, but to others = are extremely
broad.

My very crude take on what Jeff describes below is = that one can
imagine 5 different components to the problem, = i.e.
1) a language for describing the services that are = requested
2) logic for deciding whether and how to implement = the requests
3) a protocol mechanism for initiating requests with = domains
and carrying requests between them
4) interaction with AAA (especially = authorisation/accounting)
functions to support the decision process
5) protocol mechanisms to implement the decision in = the forwarding
plane

Now my question is whether the purpose of DCPEL is to = work specifically
on some or all of these, or whether initially it is = to work on
understanding how they fit together (or on some = similar decomposition).
Note that at least (3), (4) and (5) could all be = described as
'signalling', and (2)-(4) as 'control functions'; = OTOH I got the
impression last night (maybe incorrectly) that Scott = at least was
mainly interested in (1).

Or have I missed the point entirely?

Robert H.

ps. see you at lunch :-)

> -----Original Message-----
> From: dcpel-bounces@ietf.org [mailto:dcpel-bounces@ietf.org]=
> On Behalf Of Pulliam, Jeffrey S
> Sent: 08 November 2005 03:25
> To: Kathleen Nichols; dcpel@ietf.org
> Subject: [Dcpel] Purpose of a diffserv control = plane
>
>
> A couple of things -
>
> - For those interested in follow up, I want to = repeat the
> offer of lunch at the IETF on Tuesday November 8 = at 11:30 -
> in the MacKenzie room.  The room is on the = first floor near
> the meeting registration tables.   =
>
> - In hopes of starting a discussion, I would = like to try out
> the following as a starting position for = discussion:
>
> The purpose of a diffserv control plane is to = provide
> automated control of the diffserv domain, = governed and
> constrained by policy.  Control functions = configure the
> diffserv domain to deliver services in response = to requests. 
> Requests to the control function are made by = users, network
> operations, and  network management.  = The control plane
> contains necessary  rules and logic to = respond to the
> requests automatically, with resulting actions = including
> actions to configure the network to accept (or = reject) the
> request, and actions to respond to the requestor = with status
> of the request.
>
> Request can originate internal to the diffserv = domain, or
> originate from other network domains. Actions in = response to
> the requests are either actions affecting the = internal
> diffserv domains, or are actions that cross = domain boundaries
> (in the form of requests?).  A quick and = dirty simple picture
> showing the contexts (lots of room for = improvement).
>          =             &= nbsp; 
> Requestors     = Control         Actions
>
>          =    ***********
> = User<------>*         = *<----->Network Configuration
>          =    * Control *
> Net Op<---->*  Plane  *
>          =    *         = *<----->Response to Requestor
> Net mgt<--->***********
>
> What is the role, functions, and constraints of = signaling
> within the diffserv domain?  I would like = to revise (or
> replace) the above to accurately reflect the = role of
> signaling within a diffserv domain.  =
>
> Suggestions?
>
> Jeff Pulliam
>
>
>
> = _______________________________________________
> Dcpel mailing list
> Dcpel@ietf.org
> https://www1.ietf.o= rg/mailman/listinfo/dcpel
>

------_=_NextPart_001_01C5E492.E8ADF580-- --===============1977883033== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Dcpel mailing list Dcpel@ietf.org https://www1.ietf.org/mailman/listinfo/dcpel --===============1977883033==-- From dcpel-bounces@ietf.org Thu Nov 10 21:59:18 2005 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EaP8I-0008Ty-18; Thu, 10 Nov 2005 21:59:18 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EaP8G-0008Tt-Ss for dcpel@megatron.ietf.org; Thu, 10 Nov 2005 21:59:17 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA05798 for ; Thu, 10 Nov 2005 21:58:48 -0500 (EST) Received: from deprox.docomolab-euro.com ([212.119.9.186]) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1EaPOb-0005Bq-Nd for dcpel@ietf.org; Thu, 10 Nov 2005 22:16:10 -0500 Received: from 172.27.10.3 by deprox.docomolab-euro.com (InterScan E-Mail VirusWall NT); Fri, 11 Nov 2005 03:58:43 +0100 Received: from [172.25.56.71] ([172.25.56.71]) by deex.docomolab-euro.com with Microsoft SMTPSVC(5.0.2195.4905); Fri, 11 Nov 2005 03:58:43 +0100 Message-ID: <43740B9E.2090904@docomolab-euro.com> Date: Fri, 11 Nov 2005 04:10:22 +0100 From: Paulo Mendes User-Agent: Mozilla Thunderbird 1.0.6 (Windows/20050716) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Olivier Dugeon Subject: Re: [Dcpel] Dcpel BoF support References: <43590931.5080809@francetelecom.com> <4360BBE9.3070207@docomolab-euro.com> <43690113.3000005@francetelecom.com> In-Reply-To: <43690113.3000005@francetelecom.com> Content-Type: text/plain; charset=ISO-8859-15; format=flowed X-OriginalArrivalTime: 11 Nov 2005 02:58:43.0439 (UTC) FILETIME=[D382EFF0:01C5E66B] X-Spam-Score: 0.0 (/) X-Scan-Signature: 67c1ea29f88502ef6a32ccec927970f0 Content-Transfer-Encoding: quoted-printable X-MIME-Autoconverted: from 8bit to quoted-printable by ietf.org id VAA05798 Cc: dcpel@ietf.org X-BeenThere: dcpel@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Mailing list for possible diffserv control plane elements WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: dcpel-bounces@ietf.org Errors-To: dcpel-bounces@ietf.org Hi Oliver, some comments inline... Olivier Dugeon wrote: > Hi Paulo, > > Paulo Mendes a =E9crit : > >> Hi Olivier, Kathleen and all, >> >> It is good to know that the partners in IST EuQoS are planning to=20 >> support this BoF. I was acquainted in joint QoS workshop of EuQoS and=20 >> Mescal with the idea to create one BoF on Resource Management. I=20 >> think that the QoS community will gain in having all the interested=20 >> parties in the same BoF. So, it will be a good exercise to merge, as=20 >> possible, the ideas behind both proposals. > > > Yes, it is our (the EuQoS people at least) objective. > >> >> Concerning the charter, I think that it will be more efficient to=20 >> divide the effort in inter- and intra-domain. The main reason, in my=20 >> opinion is that decoupling inter- and intra- this will bring more=20 >> flexibility in end-to-end operations. Modularity is always a good=20 >> principle. >> >> You say that your focus in not on DiffServ to enforce QoS in the=20 >> network, but on the definition of a Resource Manager framework. Good,=20 >> but this Resource Management framework can still be defined with two=20 >> modules for inter- and intra-domain, connected by a network=20 >> interface. But, in what concerns the intra-domain resource control, I=20 >> don't know why shouldn't we focus on DiffServ. First, the DiffServ=20 >> model is clearly lacking a control plane; second, other QoS=20 >> enforcement mechanisms, such as MPLS, already define how resources=20 >> may be controlled. Moreover, I still think that DiffServ as a lot of=20 >> potential, not only to support qualitative traffic, but also=20 >> quantitative one. > > > Ok, I'm writing a bit faster. I have in mind to built an open=20 > framework with the DiffServ implementation. So, skip the term of=20 > Resource Manager and just keep that the architecture of a such control=20 > must be open and flexible. If we can achieve a such goal for DiffServ,=20 > it could be easy to extend it to other technology. I'm agree that=20 > DiffServ is lacking of a control plane and have great potential.=20 > Concerning the quantitative support, do you have in mind Admission=20 > Control and/or Resource Reservation ? Both. Control of admission of new flows to the aggregate defined by the=20 suitable PDB, and allocation of network resources to that PDB as needed.=20 The latter issues as to do with the way the communication resources are=20 divided between the implemented PDBs. > >> >> Another question is related to the 'topology acquisition' item. This=20 >> means that you think that the control of resources within a DiffServ=20 >> network should be centralized in a "resource manager", which will=20 >> then need to collect topology information? Since a PDB is already=20 >> defined in a distributed way, why not allow the control of resources=20 >> to be distributed, with most of the operations being located at the=20 >> edges? This distributed approach brings the benefits of higher=20 >> robustness and perhaps performance. > > > Well, under the 'topology acquisition', I'm not thinking about a=20 > centralized or distributed way of implementation. I'm just refering to=20 > the quantitative support of QoS with DiffServ. To do this, it is=20 > necessary to have a minimum knowledge of the controlled network in=20 > order to perform admission control or resource reservation. Another=20 > point is device configuration. If the QoS request is not following the=20 > data path (i.e. coming from a SIP proxy for example) the topology=20 > information is again mandatory to retrieve the correct ingress node in=20 > order to configure it. Agree. We have two options. Or the messages needed to updated the=20 provision of PDBs follow the data path from ingress to egress (in this=20 case the knowledge about the topology is as distributed as the routing),=20 or the messages are originated in a element outside the data path (in=20 this case, it seems that this element has to have a knowledge about the=20 topology, not only from its point of view, but also from the point of=20 view of any ingress device in the network). > > >> >> In what concerns the other standardization efforts, I would say that=20 >> it would help a lot this BoF, if we had a brief document=20 >> characterizing the differences between all these approaches to see=20 >> where this BoF would fit. > > > If you breifly look at the standardization efforts, you could obsrve=20 > that they all focus for the moment: > > 1/ on conversational services (based on SIP) > 2/ on access network and especially on xDSL network > > So, there is a great opportunity for Dcpel to study data services on=20 > core network which is completely the scope of the IETF. If I can have something else. In the process of defining a possible=20 charter, we should not forget that one reason that seems to be=20 responsible for the postponing of the QoS issue in the 3GPP is the lack=20 of IETF solutions to control QoS, and differentiate traffic, mainly=20 between networks. Paulo > > Cheers, > > Olivier > _______________________________________________ Dcpel mailing list Dcpel@ietf.org https://www1.ietf.org/mailman/listinfo/dcpel From dcpel-bounces@ietf.org Thu Nov 10 22:01:31 2005 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EaPAR-0000Z5-A9; Thu, 10 Nov 2005 22:01:31 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EaPAP-0000Yx-Aa for dcpel@megatron.ietf.org; Thu, 10 Nov 2005 22:01:29 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA05937 for ; Thu, 10 Nov 2005 22:01:00 -0500 (EST) Received: from deprox.docomolab-euro.com ([212.119.9.186]) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1EaPQj-0005GO-TL for dcpel@ietf.org; Thu, 10 Nov 2005 22:18:22 -0500 Received: from 172.27.10.3 by deprox.docomolab-euro.com (InterScan E-Mail VirusWall NT); Fri, 11 Nov 2005 04:01:09 +0100 Received: from [172.25.56.71] ([172.25.56.71]) by deex.docomolab-euro.com with Microsoft SMTPSVC(5.0.2195.4905); Fri, 11 Nov 2005 04:01:08 +0100 Message-ID: <43740C2F.5010702@docomolab-euro.com> Date: Fri, 11 Nov 2005 04:12:47 +0100 From: Paulo Mendes User-Agent: Mozilla Thunderbird 1.0.6 (Windows/20050716) X-Accept-Language: en-us, en MIME-Version: 1.0 To: "Hancock, Robert" Subject: Re: [Dcpel] Purpose of a diffserv control plane References: <00ba01c5e492$39d1b510$b66c34d1@comm.ad.roke.co.uk> In-Reply-To: <00ba01c5e492$39d1b510$b66c34d1@comm.ad.roke.co.uk> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 11 Nov 2005 03:01:09.0017 (UTC) FILETIME=[2A486090:01C5E66C] X-Spam-Score: 0.0 (/) X-Scan-Signature: a492040269d440726bfd84680622cee7 Content-Transfer-Encoding: 7bit Cc: dcpel@ietf.org X-BeenThere: dcpel@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Mailing list for possible diffserv control plane elements WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: dcpel-bounces@ietf.org Errors-To: dcpel-bounces@ietf.org Hi Robert and all, Hancock, Robert wrote: > Hi Jeff, Kathie, > > I think the problem that I am having (and maybe some others) in > following this discussion is that the problem scope is potentially > so enormous that it is difficult to work out how to start > discussing it, and commonplace for discussions to proceed at cross > purposes because people are talking about different bits of it. > The major problem that we are trying to tackle is the lack of control over DiffServ domains. More specifically, the possible static configuration of PDBs do not allow any reaction or adjustment to different intra-domain network conditions, policies, or inter-domain relationships. Hence, we need to develop a platform that allows the automatic adjustment of PDBs (IMO, updating the behavior of the edges, and the bandwidth allocated to the PDB). This is the first problem to tackle. Second, even with a platform allowing the control of DiffServ networks, how can we automatically control the interworking between neighbor domains? For this, we need a standard inter-domain interface. These are the two problems that we identified in the I-D about Requirements for DCPEL that Kathie made available before the meeting. We may argue, like we do in that I-D, that the inter-domain interface should be independent from specificities of the intra-domain control plane. In this case it is up to us to decide to develop such interface, while exemplifying its use between DiffServ domains, or to say that we don't care about the problem of inter-domain QoS. It is my opinion that developing a control plane for DiffServ domains is something that its needed, but without the inter-domain interface we are not allowing interworking of DiffServ domains, and so limiting the control of traffic differentiation and QoS in the Internet. Is this too much work to be done? Probably. Is this the functionalities to allow QoS control (including traffic differentiation) in the Internet based upon the DiffServ model? Definitely. So, I see that it is very coherent to define a working plan including the developing of solutions for these two problems, while keeping a clear priority in the work to be done. > Kathie's prior mail described this activity as the diffserv analogy > of moving from static routes to RIP. However, if the model is of > network-level controller nodes which manage groups of routers, a > closer analogy (to my mind) would be moving from static routes to > inter-domain MPLS. (I'm not saying this approach is wrong, just > trying to stress that it is quite a leap.) There is also a terminological > problem, that words like 'signaling' or 'control function' mean > very specific things to some people, but to others are extremely > broad. > How do you go from intra-domain static routes (I read this as intra-domain, since the context refers to RIP) to inter-domain MPLS? How did MPLS came to the picture? > My very crude take on what Jeff describes below is that one can > imagine 5 different components to the problem, i.e. > 1) a language for describing the services that are requested > 2) logic for deciding whether and how to implement the requests > 3) a protocol mechanism for initiating requests with domains > and carrying requests between them > 4) interaction with AAA (especially authorisation/accounting) > functions to support the decision process > 5) protocol mechanisms to implement the decision in the forwarding > plane > > Now my question is whether the purpose of DCPEL is to work specifically > on some or all of these, or whether initially it is to work on > understanding how they fit together (or on some similar decomposition). > Note that at least (3), (4) and (5) could all be described as > 'signalling', and (2)-(4) as 'control functions'; OTOH I got the > impression last night (maybe incorrectly) that Scott at least was > mainly interested in (1). > Unfortunately I couldn't participate in the Vancouver meeting, so it is difficult for me to comment on reactions to what happened in the meeting. Nevertheless, the I-D that Kathie made available tries to build a starting point for the discussion on the problem statement, assumptions and requirements. Was this document worth of some discussion? About the 5 points that Jeff mentioned, my remote possible opinion is: 1) the need for an Information Model to describe services to be requested and offered between network domains was mentioned in the I-D 2) where to implement the requests: in the I-D we refer as assumption the exiting of network-wide agents (agents with network-wide functionality) and local-agents (such as agents placed at the edges of a network). These are the places to configure due to a set of requests. How to configure them depends on what functionalities we decide to place in these two types of control elements, and on a needed intra-domain interface. 3) The I-D refers the need to develop an inter-domain interface, which will allow signaling between two adjacent domains, based on the Information Model referred in 1). Moreover, this interface should be generic enough to allow its use between DiffServ domains and between end-hosts and a DiffServ domain. (Probably I missed this requirement in the I-D). 4) the interaction with AAA is also referred in the I-D, in which an initial reference to authentication and trust is made, and in which is also said that "Authentication may be a part of the control plane, or may be an accessible external functionality". However, lots of work in the what concerns requirements still needs to be done. 5) The need for a protocol to adjust the PDBs is also mentioned in section 5.4 of the I-D. That section provides a brief example of how a mechanism to implement the decision in the forwarding plane of a DiffServ domain may be done. Nevertheless, as said, we should look at existing protocols that may fit the needed requirements, of part of it (in the latter case, DCPEL may suggest extensions, modifications, etc, to those protocols). For instance, we could analyze how the NSIS proposals could be used for this propose, in order to signal several network elements in the data path (path formed by all routers crossed by data packets) from one ingress to one egress point. To implement the mentioned inter-domain interface, IMO we need signaling decoupled from the data path. And since the elements involved in the signaling process are only the initiator (one element in one domain) and the destination (one element in a neighbor domain), it is not clear if all the functionalities provided by NTLP are needed. So, needs to be analysed how can current proposals for off-path NSIS signalling fit some of the requirements of the DCPEL (intra or inter-domain). I'm saying this since DCPEL aims, IMHO, to analyse network-to-network behaviors (traffic oriented!), and not end-to-end behaviors (flow oriented!). So, answering to your questions. IMO, DCPEL should aim to look at all these issues, since they are all needed to define the control elements of a DiffServ domain. Once more, it is up to us to schedule such work after a good understanding of assumptions and requirements. IMO, we need to discuss the problem statement and scope, the list of assumptions and the requirements for th e DCPEL. This will allow us to clearly define a charter with a coherent work priority. Paulo > Or have I missed the point entirely? > > Robert H. > > ps. see you at lunch :-) > > > -----Original Message----- > > From: dcpel-bounces@ietf.org [mailto:dcpel-bounces@ietf.org] > > On Behalf Of Pulliam, Jeffrey S > > Sent: 08 November 2005 03:25 > > To: Kathleen Nichols; dcpel@ietf.org > > Subject: [Dcpel] Purpose of a diffserv control plane > > > > > > A couple of things - > > > > - For those interested in follow up, I want to repeat the > > offer of lunch at the IETF on Tuesday November 8 at 11:30 - > > in the MacKenzie room. The room is on the first floor near > > the meeting registration tables. > > > > - In hopes of starting a discussion, I would like to try out > > the following as a starting position for discussion: > > > > The purpose of a diffserv control plane is to provide > > automated control of the diffserv domain, governed and > > constrained by policy. Control functions configure the > > diffserv domain to deliver services in response to requests. > > Requests to the control function are made by users, network > > operations, and network management. The control plane > > contains necessary rules and logic to respond to the > > requests automatically, with resulting actions including > > actions to configure the network to accept (or reject) the > > request, and actions to respond to the requestor with status > > of the request. > > > > Request can originate internal to the diffserv domain, or > > originate from other network domains. Actions in response to > > the requests are either actions affecting the internal > > diffserv domains, or are actions that cross domain boundaries > > (in the form of requests?). A quick and dirty simple picture > > showing the contexts (lots of room for improvement). > > > > Requestors Control Actions > > > > *********** > > User<------>* *<----->Network Configuration > > * Control * > > Net Op<---->* Plane * > > * *<----->Response to Requestor > > Net mgt<--->*********** > > > > What is the role, functions, and constraints of signaling > > within the diffserv domain? I would like to revise (or > > replace) the above to accurately reflect the role of > > signaling within a diffserv domain. > > > > Suggestions? > > > > Jeff Pulliam > > > > > > > > _______________________________________________ > > Dcpel mailing list > > Dcpel@ietf.org > > https://www1.ietf.org/mailman/listinfo/dcpel > > > >------------------------------------------------------------------------ > >_______________________________________________ >Dcpel mailing list >Dcpel@ietf.org >https://www1.ietf.org/mailman/listinfo/dcpel > > _______________________________________________ Dcpel mailing list Dcpel@ietf.org https://www1.ietf.org/mailman/listinfo/dcpel From dcpel-bounces@ietf.org Sun Nov 13 03:58:25 2005 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EbDgv-00082a-6W; Sun, 13 Nov 2005 03:58:25 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EbDgu-00082T-2k for dcpel@megatron.ietf.org; Sun, 13 Nov 2005 03:58:24 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA22082 for ; Sun, 13 Nov 2005 03:57:52 -0500 (EST) Received: from mailgw2a.lmco.com ([192.91.147.7]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EbDxc-0005AP-Uf for dcpel@ietf.org; Sun, 13 Nov 2005 04:15:45 -0500 Received: from emss01g01.ems.lmco.com (relay1.ems.lmco.com [129.197.181.54]) by mailgw2a.lmco.com (8.12.10/8.12.10) with ESMTP id jAD8w7hq021658; Sun, 13 Nov 2005 03:58:08 -0500 (EST) Received: from CONVERSION-DAEMON.lmco.com by lmco.com (PMDF V6.1-1X6 #30875) id <0IPV00301Y8V02@lmco.com>; Sun, 13 Nov 2005 00:58:07 -0800 (PST) Received: from EMSS01I00.us.lmco.com ([129.197.181.70]) by lmco.com (PMDF V6.1-1X6 #30875) with ESMTP id <0IPV00K4JY8S5M@lmco.com>; Sun, 13 Nov 2005 00:58:04 -0800 (PST) Received: from EMSS01M10.us.lmco.com ([129.197.181.75]) by EMSS01I00.us.lmco.com with Microsoft SMTPSVC(5.0.2195.6713); Sun, 13 Nov 2005 00:58:04 -0800 Date: Sun, 13 Nov 2005 00:58:03 -0800 From: "Pulliam, Jeffrey S" Subject: RE: [Dcpel] Purpose of a diffserv control plane To: Paulo Mendes , "Hancock, Robert" Message-id: MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft Exchange V6.0.6603.0 Content-type: text/plain; charset=us-ascii Content-transfer-encoding: 7BIT Thread-Topic: [Dcpel] Purpose of a diffserv control plane Thread-Index: AcXmbD/DK4FxPq9LSxuTgmYcnad2kABt4l/A content-class: urn:content-classes:message X-OriginalArrivalTime: 13 Nov 2005 08:58:04.0312 (UTC) FILETIME=[5B9E9180:01C5E830] X-Spam-Score: 0.0 (/) X-Scan-Signature: e95407604bef3289cd27cb4f3b3a35b4 Content-Transfer-Encoding: 7BIT Cc: dcpel@ietf.org X-BeenThere: dcpel@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Mailing list for possible diffserv control plane elements WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: dcpel-bounces@ietf.org Errors-To: dcpel-bounces@ietf.org Pablo Good start on a requirements document. I suspect we will discuss requirements a lot before this is done. A few comments: I generally agree with your assumptions in the ID you and Kathie drafted, as well as the core requirements. There are points of concern I would like to bring up. - Signaling Protocol Translations I fully concur with use of signaling protocols developed in other efforts in the IETF. In addition to NSIS, we need to recognize RSVP/ARSVP as an appropriate signaling protocol for use in a DiffServ Control Plane. Further, we should give some thought to the possibility that different domains will use different signaling protocols, and that the interdomain control plane function should allow for / provide for translation between signaling protocols. Your draft has the following language that heads in this direction ***SNIP**** from the requirements draft 4.0 Assumptions ... o Existing protocols, such as HTTP, COPS, SNMP, NETCONF, or the NSIS protocol suite. ... 5.2. Intra-domain Control o There must be a common intra-domain interface, allowing network elements to coordinate their actions, independently of the degree of control distribution. This interface can by defined by messages sent over protocols such as COPS, SNMP, or the NSIS protocol suite. ***SNIP*** I recommend including RSVP/ARSVP in both lists of protocols. Also suggest that specification of use of a specific signaling protocol should be constrained to a single domain, or a single relationship between two distinct domains. A domain should be free, and the control plane should enable a domain to interact with other domains over multiple signaling protocols, if necessary. But primarily, I don't want to leave out the RSVP/ARSVP protocol suite, and think we need to leverage the work currently underway focused on effecting precedence and pre-emption, as well as security related issues. You identify two roles a domain can play, provider, and customer. What do you think about subdividing the provider role into access provider, and transit provider? One example of a transit provider is in the assumptions in your draft ***SNIP*** from the requirements draft 4. Assumptions ... o For inter-domain considerations, although not all networks will be DiffServ, all will interact based on the same inter-domain control interface. For instance, backbone networks may be over- provisioned, but they will still offer and negotiate QoS agreements with its neighbors. ... ***SNIP*** The overprovisioned backbone provider will communicate using the DiffServ Control plane mechanisms, but will map all traffic to one of it's offered services, and provide signaled, unimpeded, albeit overprovisioned transit through it's domain as it's contribution to end to end service delivery. The fact that it is an overprovisioned network will be invisible to the neighboring interconnected diffserv domains. Which is ok if that transit meets the allocated portion of the end-to-end spec for the offered diffserv service? Media Dependent Requirements - So another recurring theme that seems to be in the requirements draft is that different domain types will have different requirements that are media dependent. In the draft, you mention mobile networks in a few places, and the need to support mobile networks. It might be useful in the requirements draft to isolate requirements that emerge that are specific to mobile networks. Another network type that would be useful to have addressed in the draft is satellite networks. A satellite network can provide diffserv enabled services, but in the case of the geostationary satellite, will impact the end to end guarantee of latency. A useful requirement that is somewhat specific to satellite networks is that when a network domain in unable to deliver services within the spec for the end to end service, that it make an offer of services to be delivered within a modified spec. For example, in a case where end to end latency requirement is under 150ms, a geostationary satellite network asked to participate might offer services with an additional 260 - 300 ms latency, resulting in an end to end service with 410-460ms latency. I feel the need for a picture, and will take a swing at it and send when complete. More Below Jeff > -----Original Message----- > From: Paulo Mendes [mailto:mendes@docomolab-euro.com] > Sent: Thursday, November 10, 2005 7:13 PM > To: Hancock, Robert > Cc: Pulliam, Jeffrey S; Kathleen Nichols; dcpel@ietf.org > Subject: Re: [Dcpel] Purpose of a diffserv control plane > > Hi Robert and all, > > Hancock, Robert wrote: > > > Hi Jeff, Kathie, > > > > I think the problem that I am having (and maybe some others) in > > following this discussion is that the problem scope is potentially > > so enormous that it is difficult to work out how to start > > discussing it, and commonplace for discussions to proceed at cross > > purposes because people are talking about different bits of it. > > > The major problem that we are trying to tackle is the lack of control > over DiffServ domains. More specifically, the possible static > configuration of PDBs do not allow any reaction or adjustment to > different intra-domain network conditions, policies, or inter-domain > relationships. Hence, we need to develop a platform that allows the > automatic adjustment of PDBs (IMO, updating the behavior of the edges, > and the bandwidth allocated to the PDB). This is the first problem to > tackle. Second, even with a platform allowing the control of DiffServ > networks, how can we automatically control the interworking between > neighbor domains? For this, we need a standard inter-domain interface. > These are the two problems that we identified in the I-D about > Requirements for DCPEL that Kathie made available before the meeting. > > We may argue, like we do in that I-D, that the inter-domain interface > should be independent from specificities of the intra-domain control > plane. In this case it is up to us to decide to develop such interface, > while exemplifying its use between DiffServ domains, or to say that we > don't care about the problem of inter-domain QoS. It is my opinion that > developing a control plane for DiffServ domains is something that its > needed, but without the inter-domain interface we are not allowing > interworking of DiffServ domains, and so limiting the control of > traffic differentiation and QoS in the Internet. > > Is this too much work to be done? Probably. Is this the functionalities > to allow QoS control (including traffic differentiation) in the Internet > based upon the DiffServ model? Definitely. So, I see that it is very > coherent to define a working plan including the developing of solutions > for these two problems, while keeping a clear priority in the work to be > done. > > > Kathie's prior mail described this activity as the diffserv analogy > > of moving from static routes to RIP. However, if the model is of > > network-level controller nodes which manage groups of routers, a > > closer analogy (to my mind) would be moving from static routes to > > inter-domain MPLS. (I'm not saying this approach is wrong, just > > trying to stress that it is quite a leap.) There is also a > terminological > > problem, that words like 'signaling' or 'control function' mean > > very specific things to some people, but to others are extremely > > broad. > > > How do you go from intra-domain static routes (I read this as > intra-domain, since the context refers to RIP) to inter-domain MPLS? How > did MPLS came to the picture? > > > My very crude take on what Jeff describes below is that one can > > imagine 5 different components to the problem, i.e. > > 1) a language for describing the services that are requested > > 2) logic for deciding whether and how to implement the requests > > 3) a protocol mechanism for initiating requests with domains > > and carrying requests between them > > 4) interaction with AAA (especially authorisation/accounting) > > functions to support the decision process > > 5) protocol mechanisms to implement the decision in the forwarding > > plane > > > > Now my question is whether the purpose of DCPEL is to work specifically > > on some or all of these, or whether initially it is to work on > > understanding how they fit together (or on some similar decomposition). > > Note that at least (3), (4) and (5) could all be described as > > 'signalling', and (2)-(4) as 'control functions'; OTOH I got the > > impression last night (maybe incorrectly) that Scott at least was > > mainly interested in (1). > > > Unfortunately I couldn't participate in the Vancouver meeting, so it is > difficult for me to comment on reactions to what happened in the > meeting. Nevertheless, the I-D that Kathie made available tries to build > a starting point for the discussion on the problem statement, > assumptions and requirements. Was this document worth of some discussion? > > About the 5 points that Jeff mentioned, my remote possible opinion is: > 1) the need for an Information Model to describe services to be > requested and offered between network domains was mentioned in the I-D [[jeff]] So I support development of an information model for diffserv control plane information, and this is certainly a part of the language in point 1. There are some higher order concepts that we should attack in route to the development of the information model, which includes a list and definition of what should be in the information model, a list of verbs that contains the actions performed by the control plane. > 2) where to implement the requests: in the I-D we refer as assumption > the exiting of network-wide agents (agents with network-wide > functionality) and local-agents (such as agents placed at the edges of a > network). These are the places to configure due to a set of requests. > How to configure them depends on what functionalities we decide to place > in these two types of control elements, and on a needed intra-domain > interface. [[jeff]] So this is a little different that Roberts point 2 - but is important. My point, which Robert phrased fairly well, was that the control plane needs to have logic for deciding how to implement the request within the domain, and where necessary, to request services from other domains. This is roughly equivalent to a routing IGP and EGP. I will be able to support a model for the control plane that is agent based, that provides for implementation flexibility. > 3) The I-D refers the need to develop an inter-domain interface, which > will allow signaling between two adjacent domains, based on the > Information Model referred in 1). Moreover, this interface should be > generic enough to allow its use between DiffServ domains and between > end-hosts and a DiffServ domain. (Probably I missed this requirement in > the I-D). [[jeff]] Sounds like we concur. As mentioned above, the protocol should be useable between DiffServ domains and "overprovisioned" networks. > 4) the interaction with AAA is also referred in the I-D, in which an > initial reference to authentication and trust is made, and in which is > also said that "Authentication may be a part of the control plane, or > may be an accessible external functionality". However, lots of work in > the what concerns requirements still needs to be done. [[jeff]] In particular on issues of trust, and use of authentication services provided external to the diffserv control plane. I don't think we want to create our own AAA function unless necessary, and in the case of authentication and authorization, we should allow for use of whatever the domain feels is necessary. > 5) The need for a protocol to adjust the PDBs is also mentioned in > section 5.4 of the I-D. That section provides a brief example of how a > mechanism to implement the decision in the forwarding plane of a > DiffServ domain may be done. Nevertheless, as said, we should look at > existing protocols that may fit the needed requirements, of part of it > (in the latter case, DCPEL may suggest extensions, modifications, etc, > to those protocols). For instance, we could analyze how the NSIS > proposals could be used for this propose, in order to signal several > network elements in the data path (path formed by all routers crossed by > data packets) from one ingress to one egress point. To implement the > mentioned inter-domain interface, IMO we need signaling decoupled from > the data path. And since the elements involved in the signaling process > are only the initiator (one element in one domain) and the destination > (one element in a neighbor domain), it is not clear if all the > functionalities provided by NTLP are needed. So, needs to be analysed > how can current proposals for off-path NSIS signalling fit some of the > requirements of the DCPEL (intra or inter-domain). I'm saying this since > DCPEL aims, IMHO, to analyse network-to-network behaviors (traffic > oriented!), and not end-to-end behaviors (flow oriented!). [[jeff]] So I was in agreement until the last - the control plane either needs to be able to translate a flow oriented requirement into a traffic oriented policy, or something else does. So I expect we will want to discuss this a bit. > > So, answering to your questions. IMO, DCPEL should aim to look at all > these issues, since they are all needed to define the control elements > of a DiffServ domain. Once more, it is up to us to schedule such work > after a good understanding of assumptions and requirements. > > IMO, we need to discuss the problem statement and scope, the list of > assumptions and the requirements for th e DCPEL. This will allow us to > clearly define a charter with a coherent work priority. [[jeff]] Agree - > > Paulo > > > Or have I missed the point entirely? > > > > Robert H. > > > > ps. see you at lunch :-) > > > > > -----Original Message----- > > > From: dcpel-bounces@ietf.org [mailto:dcpel-bounces@ietf.org] > > > On Behalf Of Pulliam, Jeffrey S > > > Sent: 08 November 2005 03:25 > > > To: Kathleen Nichols; dcpel@ietf.org > > > Subject: [Dcpel] Purpose of a diffserv control plane > > > > > > > > > A couple of things - > > > > > > - For those interested in follow up, I want to repeat the > > > offer of lunch at the IETF on Tuesday November 8 at 11:30 - > > > in the MacKenzie room. The room is on the first floor near > > > the meeting registration tables. > > > > > > - In hopes of starting a discussion, I would like to try out > > > the following as a starting position for discussion: > > > > > > The purpose of a diffserv control plane is to provide > > > automated control of the diffserv domain, governed and > > > constrained by policy. Control functions configure the > > > diffserv domain to deliver services in response to requests. > > > Requests to the control function are made by users, network > > > operations, and network management. The control plane > > > contains necessary rules and logic to respond to the > > > requests automatically, with resulting actions including > > > actions to configure the network to accept (or reject) the > > > request, and actions to respond to the requestor with status > > > of the request. > > > > > > Request can originate internal to the diffserv domain, or > > > originate from other network domains. Actions in response to > > > the requests are either actions affecting the internal > > > diffserv domains, or are actions that cross domain boundaries > > > (in the form of requests?). A quick and dirty simple picture > > > showing the contexts (lots of room for improvement). > > > > > > Requestors Control Actions > > > > > > *********** > > > User<------>* *<----->Network Configuration > > > * Control * > > > Net Op<---->* Plane * > > > * *<----->Response to Requestor > > > Net mgt<--->*********** > > > > > > What is the role, functions, and constraints of signaling > > > within the diffserv domain? I would like to revise (or > > > replace) the above to accurately reflect the role of > > > signaling within a diffserv domain. > > > > > > Suggestions? > > > > > > Jeff Pulliam > > > > > > > > > > > > _______________________________________________ > > > Dcpel mailing list > > > Dcpel@ietf.org > > > https://www1.ietf.org/mailman/listinfo/dcpel > > > > > > >----------------------------------------------------------------------- - > > > >_______________________________________________ > >Dcpel mailing list > >Dcpel@ietf.org > >https://www1.ietf.org/mailman/listinfo/dcpel > > > > > _______________________________________________ Dcpel mailing list Dcpel@ietf.org https://www1.ietf.org/mailman/listinfo/dcpel From dcpel-bounces@ietf.org Mon Nov 14 14:58:31 2005 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EbkTH-0001ZL-0i; Mon, 14 Nov 2005 14:58:31 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EZY9e-00061q-My; Tue, 08 Nov 2005 13:25:11 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA23988; Tue, 8 Nov 2005 13:24:44 -0500 (EST) Received: from sj-iport-5.cisco.com ([171.68.10.87]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EZYPU-0003wB-4j; Tue, 08 Nov 2005 13:41:34 -0500 Received: from sj-core-4.cisco.com ([171.68.223.138]) by sj-iport-5.cisco.com with ESMTP; 08 Nov 2005 10:24:58 -0800 X-IronPort-AV: i="3.97,305,1125903600"; d="scan'208"; a="228139779:sNHT29213836" Received: from imail.cisco.com (imail.cisco.com [128.107.200.91]) by sj-core-4.cisco.com (8.12.10/8.12.6) with ESMTP id jA8IOtag017536; Tue, 8 Nov 2005 10:24:56 -0800 (PST) Received: from [209.52.107.183] (sjc-vpn7-146.cisco.com [10.21.144.146]) by imail.cisco.com (8.12.11/8.12.10) with ESMTP id jA8IY3Oh027878; Tue, 8 Nov 2005 10:34:03 -0800 In-Reply-To: <436BF3A4.4050707@pollere.com> References: <436BF3A4.4050707@pollere.com> Mime-Version: 1.0 (Apple Message framework v746.2) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: Content-Transfer-Encoding: 7bit From: Fred Baker Date: Tue, 8 Nov 2005 10:24:52 -0800 To: Kathleen Nichols X-Mailer: Apple Mail (2.746.2) DKIM-Signature: a=rsa-sha1; q=dns; l=7608; t=1131474846; x=1131907046; c=nowsp; s=nebraska; h=Subject:From:Date:Content-Type:Content-Transfer-Encoding; d=cisco.com; i=fred@cisco.com; z=Subject:Re=3A=20[Tsvwg]=20draft-ietf-tsvwg-diffserv-service-classes-01=20WGLC| From:Fred=20Baker=20| Date:Tue,=208=20Nov=202005=2010=3A24=3A52=20-0800| Content-Type:text/plain=3B=20charset=3DUS-ASCII=3B=20delsp=3Dyes=3B=20format=3Dflowed| Content-Transfer-Encoding:7bit; b=bxkoPOF5HJOWujXtAQwTERjPSW/pIOUGqnMqDRnBbadT27r1AumFARom8twte1keZE0iJNin tlZw4rs30Qxucz7osfVaGdFwmTK4V1odVrji6tsKdTwIwSv+O50yPwQ4zt03qH4fzUvDq9Hi7Lf BmWCg1asnvAGbC8GAEe/vd5s= Authentication-Results: imail.cisco.com; header.From=fred@cisco.com; dkim=pass ( message from cisco.com verified; ); X-Spam-Score: 0.0 (/) X-Scan-Signature: ee80a2074afbfe28d15369f4e74e579d Content-Transfer-Encoding: 7bit X-Mailman-Approved-At: Mon, 14 Nov 2005 14:58:28 -0500 Cc: dcpel@ietf.org, diffserv-interest@ietf.org, TSVWG Subject: [Dcpel] Re: [Tsvwg] draft-ietf-tsvwg-diffserv-service-classes-01 WGLC X-BeenThere: dcpel@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Mailing list for possible diffserv control plane elements WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: dcpel-bounces@ietf.org Errors-To: dcpel-bounces@ietf.org Hi Kathy. This is a discussion we have had for quite a while now, and it is not news to you that while your reading of the consensus in the diffserv working group was as you report, there was also a significant set of people who even then were interested in end to end QoS and wanted some concept of end to end service classes. The consensus was, as we say, a rough consensus, not a uniform one. Let me try to to address your points. On Nov 4, 2005, at 3:49 PM, Kathleen Nichols wrote: > Concern 1: This draft ties "service class" to applications and to > specific PHBs in all networks. I'm not sure I agree with that. It ties the service to the behaviors of classes of applications and the requirements that they have. For example, it mentions the needs of applications that move large volumes of traffic and are relatively insensitive to their users, which is to say applications that transfer files (examples of which might include FTP, Network News, and peer-to-peer file sharing) versus transaction applications, examples of which might include web services, the web itself, SNMP, and a variety of others. It doesn't try to assign a DSCP to HTTP and another to FTP; it does assign DSCPs to classes of applications that have more-or-less-consistent PHB-type requirements and user expectations. Practically speaking, this is probably the single largest use of QoS capabilities I have worked with customers on prior to the deployment of real time applications. In the late 1960's IBM discovered that providing a sub-second response to CICS queries was important to its customers, and made a heavy marketing program regarding "sub-second response time". In developing SNA, they found it necessary, to be responsive to customer needs, to be able to differentiate between file transfer traffic and transaction traffic. In the 1980s, distinguishing between echoplex terminal traffic and (to name one example) NFS became similarly important, and both RFCs 896 (which dealt with managing telnet traffic in a congested network where telnet competed with file transfers) and RFC 970 (which generalized that to help address TCP SWS and other issues, and was seminal in the development of modern fair queuing concepts) dealt with these issues. They remain at issue in today's networks, where the fiber core is often very high capacity but the access network may involve relatively low speed links and so on. In addition, with the development of real time services such as video and voice on IP, these applications have similarly experienced problems in the access networks, but have very different PHB requirements - but requirements that can still be described in classes. Practically speaking, you will recall when you, Van, and I were all at Cisco and Cisco stopped deployment of voice networks until we got a priority queuing concept into the MQC configurations of our routers, due specifically to the requirements of these applications. We can discuss academic concepts of service classes and so on if you like, but pragmatically the traffic behaviors are not ethereal concepts: they are the behaviors of traffic generated by and depended on by applications, and by the users who use them. Pragmatically, if we don't meet those applications' and users' needs in the architecture, it is not the users who are wrong. We have developed an anachronistic architecture, and it needs to change. So yes, if (as you and France Telecom both said last night in the O&M Area Meeting) we need to develop end to end service architectures, there are a variety of things we need to have, and one of them is some form of lingua franca in which we can discuss the traffic that users and their applications generate and consume, and what our expectations are regarding that traffic. Regarding the application of DSCP values to service classes, the draft does not require users or networks to use specific DSCP values, but it does recommend values. There are two ways to look at this. One, if DSCPs are truly only of local significance, then the assignment of DSCP values to the EF and AF classes is incorrect, and in fact the division of DSCP values into for-standardization, experimental-with-possible-standardization, and experimental-use is for naught. People should simply assign DSCP values locally. On the other hand, forcing them to do so is rather a big deal - it means that the network operator now has a huge job on his hands, and at every network interchange point they must be translated. And lacking consistent classes on either side of that demarcation point, the translation is not at all obvious. So, yes, we recommend DSCP values, and do so to simplify deployment and minimize the work that must be done at network boundaries. Operators remain free to do something different. > Again DiffServ was explicit about the decoupling of services and > applications. Right. But the services must serve classes of applications, or they are very difficult to describe. I'll refer you to RFC 3246/3247, if you like; these are very distinctly about traffic that behaves in a CBR manner and requires very predictable service. In terms of applications people use today of that type, that would be ATM-over- MPLS, to a less extent frame relay over MPLS, and VoIP. It might also include some classes of video service, but does not include services using variable rate codecs like MPEG-4, which have a very different set of requirements. > Concern 2: The definition of Service Class and its relationship to > traffic aggregates. > [snip] > This is turned inside out by this draft which talks about traffic > aggregates as though they were traffic streams, as defined by RFC > 2475, and invariant under edge conditioning and aggregation that > must of necessity occur inside any non-trivial network. The effects > of aggregation and the need to design PDBs and services > to be careful of these is discussed in RFC3086, reflecting DiffServ > WG discussions. I will ask two questions. First, if a traffic aggregate is not the sum of some number of traffic streams, what is it? Second, if PDBs are so very important, would you please remind me what the RFC Number of the PDB associated with RFC 3246/3247 is? We are in fact using the PDB in RFC 3662 for the scavenger service. If this is a place where we have fallen down and deserve public censure, I think you have to agree that you are not lily-white either. > Concern 3: draft seems to equate requiring a uniform PHB with > achieving an end-to-end QoS. I'm not at all sure we said that; if you could point us to the text, I'd appreciate it. What we are saying, or what I think we're saying, is that Parehk&Gallager's proofs in Infocomm '91-'93 indicate that to deliver a predictable service from host to host across a network, one must be able to quantify the behavior of both the hosts and the relevant routed or switched interfaces across the network. There are certainly also other engineering and management issues, something we don't gain-say. But trying to provide end to end QoS *without* describing the PHBs in question is, mathematically, not possible per the available mathematical work on the topic. > These DiffServ documents were clear that a PHB does not a service > make. Agreed. Now tell me how to build a service without the PHB? > Finally, the draft specifies a lot of operational rules for > networks. This is inverted from the DiffServ WG approach of putting > tools into the hands of operators. I disagree. The tools are still in the hands of operators. That said, the operators come to me asking which tools to use and how. At Cisco, we funded the development of a simulator and a major clean-up of NS-2 with a view to helping them accomplish that, and have given a lot of free consulting to our customers helping them do this. My colleagues at Nortel find themselves similarly engaged. The discussion has gone to the ITU due to IETF's disinterest in helping out with the topic, resulting in certain aspects of the NGN architecture, and it has come back to us in IEPREP, in which various agencies have asked for additional services of various kinds, such as a DSCP for all emergency traffic. Numerous folks are looking to the IETF for guidance, and given a vacuum will go elsewhere that may be less clueful. This draft seeks to summarize that guidance, leaving the specific engineering in the operator's very capable hands. It is not our place to list our customers, who discuss their issues with us in private. There have, however, been some who commented publicly, such as Optus' request that call control traffic for voice and video not occupy the same service queue as the traffic is is about. In fact, we are in private discussions with quite a number of enterprize, access, and backbone network customers, with the GIG folks who held their BOF last night, and so on. There is significant interest in developing some set of service classes for classes of applications with more-or-less-consistent requirements. We would be happy to have your suggestions on text to change, which is why this has been in review in diffserv and in tsvwg in various forms since 2002. Kwok, Josef, and I agreed on this note before I sent it... _______________________________________________ Dcpel mailing list Dcpel@ietf.org https://www1.ietf.org/mailman/listinfo/dcpel From dcpel-bounces@ietf.org Mon Nov 14 14:58:31 2005 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EbkTH-0001Zk-AR; Mon, 14 Nov 2005 14:58:31 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EZYsi-0002LZ-7y for dcpel@megatron.ietf.org; Tue, 08 Nov 2005 14:11:44 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA26664 for ; Tue, 8 Nov 2005 14:11:17 -0500 (EST) Received: from mclmx2.mail.saic.com ([149.8.64.32]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EZZ8X-0005E0-Q2 for dcpel@ietf.org; Tue, 08 Nov 2005 14:28:08 -0500 Received: from 0015-its-ieg02.mail.saic.com ([149.8.64.21] [149.8.64.21]) by mclmx2.mail.saic.com; Tue, 8 Nov 2005 14:11:22 -0500 Received: from mclmx2.mail.saic.com ([149.8.64.32]) by 0015-its-ieg02.mail.saic.com (SMSSMTP 4.0.5.66) with SMTP id M2005110814112208467 ; Tue, 08 Nov 2005 14:11:22 -0500 Received: from bh-exchangefe.saic-abingdon.com ([149.8.64.21] [149.8.64.21]) by mclmx2.mail.saic.com with ESMTP; Tue, 8 Nov 2005 14:11:22 -0500 Received: from bh-exchange02.saic-abingdon.com ([10.42.81.226]) by bh-exchangefe.saic-abingdon.com with Microsoft SMTPSVC(6.0.3790.1830); Tue, 8 Nov 2005 14:15:17 -0500 X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Subject: RE: [Dcpel] Purpose of a diffserv control plane Date: Tue, 8 Nov 2005 14:15:14 -0500 Message-Id: <2FE23D25B7292B489A217D1965CDA866089929@bh-exchange02.saic-abingdon.com> Thread-Topic: [Dcpel] Purpose of a diffserv control plane Thread-Index: AcXkkulgz1x4zWgwSPWPdjPNRAyQugABUYgQ From: "Roy, Radhika \(AEAD\)" To: "Hancock, Robert" , "Pulliam, Jeffrey S" , "Kathleen Nichols" , X-OriginalArrivalTime: 08 Nov 2005 19:15:17.0985 (UTC) FILETIME=[C157DD10:01C5E498] X-Spam-Score: 0.3 (/) X-Scan-Signature: 90e8b0e368115979782f8b3d811b226b X-Mailman-Approved-At: Mon, 14 Nov 2005 14:58:27 -0500 Cc: X-BeenThere: dcpel@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Mailing list for possible diffserv control plane elements WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============2013795356==" Sender: dcpel-bounces@ietf.org Errors-To: dcpel-bounces@ietf.org This is a multi-part message in MIME format. --===============2013795356== Content-class: urn:content-classes:message Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C5E498.BF59BE3E" This is a multi-part message in MIME format. ------_=_NextPart_001_01C5E498.BF59BE3E Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi, all: =20 It seems to be that 5 points articulated by Robert may describe the overall DCPEL schemes. The only other point that may need to be added: "Specific to DiffServ services." =20 Cheers! Radhika =20 ________________________________ From: dcpel-bounces@ietf.org [mailto:dcpel-bounces@ietf.org] On Behalf Of Hancock, Robert Sent: Tuesday, November 08, 2005 1:28 PM To: Pulliam, Jeffrey S; Kathleen Nichols; dcpel@ietf.org Subject: RE: [Dcpel] Purpose of a diffserv control plane =20 Hi Jeff, Kathie,=20 I think the problem that I am having (and maybe some others) in=20 following this discussion is that the problem scope is potentially=20 so enormous that it is difficult to work out how to start=20 discussing it, and commonplace for discussions to proceed at cross=20 purposes because people are talking about different bits of it.=20 Kathie's prior mail described this activity as the diffserv analogy=20 of moving from static routes to RIP. However, if the model is of=20 network-level controller nodes which manage groups of routers, a=20 closer analogy (to my mind) would be moving from static routes to=20 inter-domain MPLS. (I'm not saying this approach is wrong, just=20 trying to stress that it is quite a leap.) There is also a terminological=20 problem, that words like 'signaling' or 'control function' mean=20 very specific things to some people, but to others are extremely=20 broad.=20 My very crude take on what Jeff describes below is that one can=20 imagine 5 different components to the problem, i.e.=20 1) a language for describing the services that are requested=20 2) logic for deciding whether and how to implement the requests=20 3) a protocol mechanism for initiating requests with domains=20 and carrying requests between them=20 4) interaction with AAA (especially authorisation/accounting)=20 functions to support the decision process=20 5) protocol mechanisms to implement the decision in the forwarding=20 plane=20 Now my question is whether the purpose of DCPEL is to work specifically=20 on some or all of these, or whether initially it is to work on=20 understanding how they fit together (or on some similar decomposition).=20 Note that at least (3), (4) and (5) could all be described as=20 'signalling', and (2)-(4) as 'control functions'; OTOH I got the=20 impression last night (maybe incorrectly) that Scott at least was=20 mainly interested in (1).=20 Or have I missed the point entirely?=20 Robert H.=20 ps. see you at lunch :-)=20 ------_=_NextPart_001_01C5E498.BF59BE3E Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable RE: [Dcpel] Purpose of a diffserv control plane

Hi, = all:

 

It seems to be that 5 points = articulated by Robert may describe the overall DCPEL schemes. The only other point = that may need to be added: “Specific to DiffServ = services.”

 

Cheers!

=

Radhika

=

 

From: dcpel-bounces@ietf.org [mailto:dcpel-bounces@ietf.org] On Behalf Of Hancock, Robert
Sent: Tuesday, November = 08, 2005 1:28 PM
To: Pulliam, Jeffrey S; = Kathleen Nichols; dcpel@ietf.org
Subject: RE: [Dcpel] = Purpose of a diffserv control plane

 

Hi Jeff, Kathie,

I think the problem that I am having (and maybe some others) in =
following this = discussion is that the problem scope is potentially
so enormous that it is = difficult to work out how to start
discussing it, and = commonplace for discussions to proceed at cross
purposes because people = are talking about different bits of it.

Kathie's prior mail described this activity as the diffserv analogy =
of moving from static = routes to RIP. However, if the model is of
network-level controller = nodes which manage groups of routers, a
closer analogy (to my = mind) would be moving from static routes to
inter-domain MPLS. (I'm = not saying this approach is wrong, just
trying to stress that it = is quite a leap.) There is also a terminological
problem, that words like 'signaling' or 'control function' mean
very specific things to = some people, but to others are extremely
broad. =

My very crude take on what Jeff describes below is that one can =
imagine 5 different = components to the problem, i.e.
1) a language for = describing the services that are requested
2) logic for deciding = whether and how to implement the requests
3) a protocol mechanism = for initiating requests with domains
and carrying requests = between them
4) interaction with AAA = (especially authorisation/accounting)
functions to support the = decision process
5) protocol mechanisms = to implement the decision in the forwarding
plane =

Now my question is whether the purpose of DCPEL is to work = specifically
on some or all of these, = or whether initially it is to work on
understanding how they = fit together (or on some similar decomposition).
Note that at least (3), = (4) and (5) could all be described as
'signalling', and = (2)-(4) as 'control functions'; OTOH I got the
impression last night = (maybe incorrectly) that Scott at least was
mainly interested in = (1).

Or have I missed the point entirely?

Robert H.

ps. see you at lunch :-)

------_=_NextPart_001_01C5E498.BF59BE3E-- --===============2013795356== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Dcpel mailing list Dcpel@ietf.org https://www1.ietf.org/mailman/listinfo/dcpel --===============2013795356==-- From dcpel-bounces@ietf.org Mon Nov 14 14:58:31 2005 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EbkTH-0001aC-Ji; Mon, 14 Nov 2005 14:58:31 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EZaJP-00067t-GA; Tue, 08 Nov 2005 15:43:25 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA02393; Tue, 8 Nov 2005 15:42:56 -0500 (EST) From: Black_David@emc.com Received: from mailhub.lss.emc.com ([168.159.2.31]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EZaZH-0007q1-Hu; Tue, 08 Nov 2005 15:59:48 -0500 Received: from mxic2.corp.emc.com (mxic2.corp.emc.com [128.221.12.9]) by mailhub.lss.emc.com (Switch-3.1.6/Switch-3.1.6) with ESMTP id jA8Kh3Zg015854; Tue, 8 Nov 2005 15:43:06 -0500 (EST) Received: by mxic2.corp.emc.com with Internet Mail Service (5.5.2653.19) id ; Tue, 8 Nov 2005 15:43:02 -0500 Message-ID: To: nichols@pollere.com, tsvwg@ietf.org Date: Tue, 8 Nov 2005 15:42:45 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain X-PMX-Version: 4.7.1.128075, Antispam-Engine: 2.1.0.0, Antispam-Data: 2005.11.8.22 X-PerlMx-Spam: Gauge=, SPAM=0%, Reasons='EMC_BODY_1+ -5, EMC_FROM_00+ -3, NO_REAL_NAME 0, __C230066_P5 0, __CT 0, __CT_TEXT_PLAIN 0, __HAS_MSGID 0, __HAS_X_MAILER 0, __IMS_MSGID 0, __IMS_MUA 0, __MIME_TEXT_ONLY 0, __MIME_VERSION 0, __PORN_PHRASE_15_0 0, __SANE_MSGID 0, __STOCK_CRUFT 0' X-Spam-Score: 0.3 (/) X-Scan-Signature: 3b3709b7fb3320c78bd7b1555081f0fc X-Mailman-Approved-At: Mon, 14 Nov 2005 14:58:29 -0500 Cc: dcpel@ietf.org, diffserv-interest-request@ietf.org Subject: [Dcpel] RE: [Tsvwg] draft-ietf-tsvwg-diffserv-service-classes-01 WGLC X-BeenThere: dcpel@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Mailing list for possible diffserv control plane elements WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: dcpel-bounces@ietf.org Errors-To: dcpel-bounces@ietf.org Kathie, Pulling out selected portions of your email to comment on your issues ... > My concerns with this document haven't changed much from the comments I > had for the authors on the original version. My major concern is that > this draft rewrites many concepts that were crafted by consensus over > several years in the DiffServ WG and are currently in use. > Certainly, concepts and standards have to be revisited from time to > time, but this draft is not being explicit about it. At the very least, > this should be made clear both in the document and by the ADs, > particularly since some of it is at odds with RFC2474, a standards > track document. That certainly was not the draft's intent. To the extent that the draft is at odds with RFC 2474 and 2475, I suspect the problems can be cleaned up with suitably careful selection of terminology and a suitably detailed editing pass. (NB: I'm a co-author of RFC 2474 and 2475). > Concern 1: This draft ties "service class" to applications and to > specific PHBs in all networks. > This links *applications* to requirements for specific delay, loss > and jitter characteristic which is counter to the internet history > of building applications that adapt to network conditions. The point > of DiffServ was to provide tools to make it possible to differentiate > traffic on whatever basis an operator desired, to > not require that inner workings of a network be exposed, > and not to require a particular PHB. If an operator can deliver certain > specified treatments (in SLSs) to traffic across its network, it was > considered its business what PHB and edge treatments were used. > Again DiffServ was explicit about the decoupling of services and > applications. This draft's coupling of network services to applications is deliberate and is much of the value of the draft. Diffserv has always been viewed as a toolkit - it has the equivalent of band saws, planers, drill presses, etc. In the hands of an expert, there's no limit to what can be built, but it's intimidating to the point of inaccessible to a novice who just wants to build a table and chairs. Think of this draft as a set of "project plans" for building all the furniture that a house might need. The user may choose what to build (e.g., maybe our example novice doesn't need a china cabinet right now). This is one of the reasons that it's deliberately *not* going standards track - Best Current Practice was one possible alternative to Informational. > Concern 2: The definition of Service Class and its relationship to > traffic aggregates. I think this is mostly sloppy terminology. The focus of the draft is (and should be) the traffic aggregates around which the core of the network/diffserv domain needs to be designed. The draft definitely needs to allow the situation in which aggregates are exploded into flows at the network edges and flows may "switch" aggregates when passing between networks (e.g., I'm a customer of network A, so my video download gets gold treatment from that operator, but network B carries it as best effort). To the extent that it forbids this sort of thing, the draft needs to be corrected to point out that if the behavior changes across domains, it's harder to be sure that the result is consistent QoS ... > Concern 3: draft seems to equate requiring a uniform PHB with achieving > an end-to-end QoS. The draft shouldn't "equate" - to the extent it does, it needs editing. What the draft is trying to do is describe one approach to building end-to-end QoS, namely use the same PHB (and hence PDB) uniformly across the networks (diffserv domains) involved. See the above "project plans" analogy - such a set of plans are not the only way to build furniture (e.g., plans for a novice probably won't use mortise/tenon construction). > Finally, the draft specifies a lot of operational rules for > networks. This is inverted from the DiffServ WG approach of putting > tools into the hands of operators. The "project plans" comment applies to this also. I think this draft is an important complement to the existing body of diffserv work and needs to be published as an RFC. Thanks, --David ---------------------------------------------------- David L. Black, Senior Technologist EMC Corporation, 176 South St., Hopkinton, MA 01748 +1 (508) 293-7953 FAX: +1 (508) 293-7786 black_david@emc.com Mobile: +1 (978) 394-7754 ---------------------------------------------------- > -----Original Message----- > From: tsvwg-bounces@ietf.org [mailto:tsvwg-bounces@ietf.org] > On Behalf Of Kathleen Nichols > Sent: Friday, November 04, 2005 6:50 PM > To: tsvwg@ietf.org > Cc: dcpel@ietf.org; diffserv-interest-request@ietf.org > Subject: [Tsvwg] draft-ietf-tsvwg-diffserv-service-classes-01 WGLC > > > My concerns with this document haven't changed much from the comments I > had for the authors on the original version. My major concern is that > this draft rewrites many concepts that were crafted by consensus over > several years in the DiffServ WG and are currently in use. > Certainly, concepts and standards have to be revisited from time to > time, but this draft is not being explicit about it. At the very least, > this should be made clear both in the document and by the ADs, > particularly since some of it is at odds with RFC2474, a standards > track document. > > Concern 1: This draft ties "service class" to applications and to > specific PHBs in all networks. > > This draft defines a "service class" as: > > "a set of traffic that requires specific delay, loss and jitter > characteristics from the network for which a consistent > and defined > per-hop behavior (PHB) [RFC2474] applies. > Conceptually, a service class pertains to applications with similar > characteristics and performance requirements, such as a 'High > Throughput Data' service class for applications like the web and > electronic mail, or a 'Telephony' service class for real-time traffic > such as voice and other telephony services." > > This links *applications* to requirements for specific delay, loss > and jitter characteristic which is counter to the internet history > of building applications that adapt to network conditions. The point > of DiffServ was to provide tools to make it possible to differentiate > traffic on whatever basis an operator desired, to > not require that inner workings of a network be exposed, > and not to require a particular PHB. If an operator can deliver certain > specified treatments (in SLSs) to traffic across its network, it was > considered its business what PHB and edge treatments were used. > See RFC2475: > > "Service differentiation is desired to accommodate > heterogeneous application requirements and user > expectations, and to > permit differentiated pricing of Internet service." > > and > > "A distinction is maintained between: > > o the service provided to a traffic aggregate, > > o the conditioning functions and per-hop behaviors used > to realize > services, > > o the DS field value (DS codepoint) used to mark packets > to select a > per-hop behavior, and > > o the particular node implementation mechanisms which realize a > per-hop behavior. > > Service provisioning and traffic conditioning policies are > sufficiently decoupled from the forwarding behaviors within the > network interior to permit implementation of a wide variety of > service behaviors, with room for future expansion." > > but this draft would erase that distinction, and (more RFC2475): > > "The following requirements were identified and are addressed in this > architecture: > > o should accommodate a wide variety of services and provisioning > policies, extending end-to-end or within a particular (set of) > network(s), > > o should allow decoupling of the service from the particular > application in use, > ... > o should decouple traffic conditioning and service provisioning > functions from forwarding behaviors implemented within the core > network nodes," > > Again DiffServ was explicit about the decoupling of services and > applications. > > Concern 2: The definition of Service Class and its relationship to > traffic aggregates. > > From RFC 2474: > "Services are realized by the > use of particular packet classification and traffic conditioning > mechanisms at boundaries coupled with the concatenation of per-hop > behaviors along the transit path of the traffic. A goal of the > differentiated services architecture is to specify these building > blocks for future extensibility, both of the number and type of the > building blocks and of the services built from them." > > and the definition from standards track RFC2474: > > "Service: a description of the overall treatment of (a subset of) a > customer's traffic across a particular domain, across a set of > interconnected DS domains, or end-to-end. Service descriptions are > covered by administrative policy and services are constructed by > applying traffic conditioning to create behavior aggregates which > experience a known PHB at each node within the DS domain. Multiple > services can be supported by a single per-hop behavior used in > concert with a range of traffic conditioners. > > To summarize, classifiers and traffic conditioners are used to select > which packets are to be added to behavior aggregates. Aggregates > receive differentiated treatment in a DS domain and traffic > conditioners MAY alter the temporal characteristics of the aggregate > to conform to some requirements. A packet's DS field is used to > designate the packet's behavior aggregate and is subsequently used to > determine which forwarding treatment the packet receives." > > This is turned inside out by this draft which talks about traffic > aggregates as though they were traffic streams, as defined by > RFC 2475, and invariant under edge conditioning and aggregation > that must of necessity occur inside any non-trivial network. The > effects of aggregation and the need to design PDBs and services > to be careful of these is discussed in RFC3086, reflecting DiffServ > WG discussions. First, from RFC 2475: > > "Traffic stream an administratively significant set of one > or more microflows which traverse a path > segment. A traffic stream may consist of > the set of active microflows which are > selected by a particular classifier." > From the draft: > > "A Service Class as defined here is essentially a statement of the > required characteristics of a traffic aggregate; the actual > specification of the expected treatment of a traffic aggregate within > a domain may also be defined as a Per Domain Behavior [RFC3086]." > > This is the only place in the draft where RFC 3086, a product of the > DiffServ WG is mentioned. (There was no mention in the original.) > From RFC 3086's abstract, giving context for this RFC: > > "The next step is to formulate examples of how forwarding path > components (PHBs, classifiers, and traffic conditioners) can be used > to compose traffic aggregates whose packets experience specific > forwarding characteristics as they transit a differentiated services > domain. The WG has decided to use the term per-domain behavior, or > PDB, to describe the behavior experienced by a particular set of > packets as they cross a DS domain." > > and from RFC 3086's Introduction: > "Diffserv classification and traffic conditioning are applied to > packets arriving at the boundary of a DS domain to impose > restrictions on the composition of the resultant traffic aggregates, > as distinguished by the DSCP marking, inside the domain. The > classifiers and traffic conditioners are set to reflect the policy > and traffic goals for that domain and may be specified in a TCA > (Traffic Conditioning Agreement). Once packets have crossed the DS > boundary, adherence to diffserv principles makes it possible to group > packets solely according to the behavior they receive at each hop (as > selected by the DSCP). This approach has well-known scaling > advantages, both in the forwarding path and in the control plane. > Less well recognized is that these scaling properties only result if > the per-hop behavior definition gives rise to a particular type of > invariance under aggregation. Since the per-hop behavior must be > equivalent for every node in the domain, while the set of packets > marked for that PHB may be different at every node, PHBs should be > defined such that their characteristics do not depend on the traffic > volume of the associated BA on a router's ingress link nor on a > particular path through the DS domain taken by the packets. > Specifically, different streams of traffic that belong to the same > traffic aggregate merge and split as they traverse the network. If > the properties of a PDB using a particular PHB hold regardless of how > the temporal characteristics of the marked traffic aggregate change > as it traverses the domain, then that PDB scales. " > > A per-hop behavior, which is just how a packet is forwarded at each > node, cannot directly result in a particular end-to-end, or even > edge-to-edge set of characteristics since it is dependent on how > much traffic is admitted and how traffic is mixed and so on. Which > brings me to: > > Concern 3: draft seems to equate requiring a uniform PHB with achieving > an end-to-end QoS. > > Contrast this with the RFC 2475 and 3086 approaches of having each > network domain specify the loss rate, maximum delay, and/or other > metrics which it will provide to traffic streams that conform to > certain agreed-upon (via SLS) behavior (e.g., interface, markings, > rate). Though work remains on how to put the values from a chain > of networks together, it is certain possible to figure out the > maximum delay through a set of networks with services so specified. > At the same time, nothing need be known about network internals. > If I am told that a traffic stream will be priority queued at > every router between two points, I am told nothing about the > maximum delay the packets will experience. > > In section 1.5.3 of the draft, > > "Expedited Forwarding PHB [RFC3246] behavior was originally proposed > as a way to implement a virtual wire, and can be used in such a > manner." > > The EF PHB was originally proposed as a *building block* to create > a service (then called virtual leased line) and both the original > proposal in RFC 2598 and the update in RFC 3246 were quite clear > about this. From RFC 2598: > > The EF PHB can be used to build a low loss, low > latency, low jitter, assured bandwidth, end-to-end service through DS > domains. Such a service appears to the endpoints like a point-to- > point connection or a "virtual leased line". > > ... > > Creating such a service has two parts: > > 1) Configuring nodes so that the aggregate has a well-defined > minimum departure rate. ("Well-defined" means independent of > the dynamic state of the node. In particular, independent of > the intensity of other traffic at the node.) > > 2) Conditioning the aggregate (via policing and shaping) so that > its arrival rate at any node is always less than that node's > configured minimum departure rate. > > The EF PHB provides the first part of the service. The network > boundary traffic conditioners described in [RFC2475] provide the > second part. > > From RFC 3246: > "The intent of the EF PHB is to provide a building block for low loss, > low delay, and low jitter services. The details of exactly how to > build such services are outside the scope of this specification." > > and > > "Note that the EF PHB only defines the behavior of a single node. The > specification of behavior of a collection of nodes is outside the > scope of this document. A Per-Domain Behavior (PDB) specification > [7] may provide such information." > > These DiffServ documents were clear that a PHB does not a > service make. > > Finally, the draft specifies a lot of operational rules for > networks. This is inverted from the DiffServ WG approach of putting > tools into the hands of operators. > > Kathie Nichols > > _______________________________________________ > tsvwg mailing list > tsvwg@ietf.org > https://www1.ietf.org/mailman/listinfo/tsvwg > _______________________________________________ Dcpel mailing list Dcpel@ietf.org https://www1.ietf.org/mailman/listinfo/dcpel From dcpel-bounces@ietf.org Mon Nov 14 14:58:31 2005 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EbkTH-0001aq-SK; Mon, 14 Nov 2005 14:58:31 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EZtRC-0001Xf-PY; Wed, 09 Nov 2005 12:08:42 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA22235; Wed, 9 Nov 2005 12:08:14 -0500 (EST) Received: from p-mail1.rd.francetelecom.com ([195.101.245.15]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EZthF-0002CY-Ib; Wed, 09 Nov 2005 12:25:18 -0500 Received: from ftrdmel1.rd.francetelecom.fr ([10.193.117.152]) by ftrdsmtp1.rd.francetelecom.fr with Microsoft SMTPSVC(6.0.3790.211); Wed, 9 Nov 2005 18:08:38 +0100 X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Date: Wed, 9 Nov 2005 18:08:33 +0100 Message-ID: Thread-Topic: [Tsvwg] draft-ietf-tsvwg-diffserv-service-classes-01 WGLC Thread-Index: AcXhmq+YbX0wtZ2gTiaSwep3RBssZQDs+Byg From: "LEVIS Pierre RD-CORE-CAE" To: "Kathleen Nichols" , X-OriginalArrivalTime: 09 Nov 2005 17:08:38.0098 (UTC) FILETIME=[39DEE320:01C5E550] X-Spam-Score: 0.0 (/) X-Scan-Signature: 2d133cc328f58695161c98bb4f4dc213 Content-Transfer-Encoding: quoted-printable X-Mailman-Approved-At: Mon, 14 Nov 2005 14:58:28 -0500 Cc: dcpel@ietf.org, diffserv-interest-request@ietf.org Subject: [Dcpel] RE: [Tsvwg] draft-ietf-tsvwg-diffserv-service-classes-01 WGLC X-BeenThere: dcpel@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Mailing list for possible diffserv control plane elements WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: dcpel-bounces@ietf.org Errors-To: dcpel-bounces@ietf.org About the decoupling of services and applications. There are many approaches that divide the Network layer in service = classes accordingly to applications requirements. See UMTS/GPRS TS 23 = 107 and, may be to a lesser extend, ITU Y.1541. The tendency is very = much "yet another application, yet another class". Simply because it = doesn't seem reasonable to have as many classes as applications, = applications are grouped by categories. But fundamentally the rationale = remains the network is to closely adapt to the application. This is = indeed contradictory to several architectural ideas that enable the = current Internet, like the hour glass model and the end-to-end = principle. However it's also very true that network services will be = used by applications and that there must be a certain level of coherence = between the two. The notion of Meta-QoS-Class (MQC) we have introduced in = both maintains the independence = between PDB (or service class or class of service or whatsoever you call = it) and applications, and allows dynamic linkage. Simply speaking, a MQC = is just a label associated to a type of applications that can be put on = any implemented PDB (we use the term local class) to certify this class = is suitable for this application. MQC concept makes it possible to = handle network services and applications requirements as separate = notions. MQC is particularly interesting when it comes to SLS negotiations = between ISPs (pSLS). We consider it is harmful to have pSLS QoS = guarantees that span several domains. A pSLS should only concern the QoS = of the neighbouring domain you're negotiating with. Two neighbouring = local classes can be bound together if they conform to the same MQC.=20 Pierre -----Message d'origine----- De : tsvwg-bounces@ietf.org [mailto:tsvwg-bounces@ietf.org] De la part = de Kathleen Nichols Envoy=E9 : samedi 5 novembre 2005 00:50 =C0 : tsvwg@ietf.org Cc : dcpel@ietf.org; diffserv-interest-request@ietf.org Objet : [Tsvwg] draft-ietf-tsvwg-diffserv-service-classes-01 WGLC My concerns with this document haven't changed much from the comments I = had for the authors on the original version. My major concern is that = this draft rewrites many concepts that were crafted by consensus over = several years in the DiffServ WG and are currently in use. Certainly, concepts and standards have to be revisited from time to = time, but this draft is not being explicit about it. At the very least, = this should be made clear both in the document and by the ADs, = particularly since some of it is at odds with RFC2474, a standards track = document. Concern 1: This draft ties "service class" to applications and to = specific PHBs in all networks. This draft defines a "service class" as: "a set of traffic that requires specific delay, loss and jitter=20 characteristics from the network for which a consistent and defined = per-hop behavior (PHB) [RFC2474] applies. Conceptually, a service class pertains to applications with similar = characteristics and performance requirements, such as a 'High Throughput = Data' service class for applications like the web and electronic mail, = or a 'Telephony' service class for real-time traffic such as voice and = other telephony services." This links *applications* to requirements for specific delay, loss and = jitter characteristic which is counter to the internet history of = building applications that adapt to network conditions. The point of = DiffServ was to provide tools to make it possible to differentiate = traffic on whatever basis an operator desired, to not require that inner = workings of a network be exposed, and not to require a particular PHB. = If an operator can deliver certain specified treatments (in SLSs) to = traffic across its network, it was considered its business what PHB and = edge treatments were used. See RFC2475: "Service differentiation is desired to accommodate heterogeneous application requirements and user expectations, and to permit differentiated pricing of Internet service." and "A distinction is maintained between: o the service provided to a traffic aggregate, o the conditioning functions and per-hop behaviors used to realize services, o the DS field value (DS codepoint) used to mark packets to select = a per-hop behavior, and o the particular node implementation mechanisms which realize a per-hop behavior. Service provisioning and traffic conditioning policies are sufficiently decoupled from the forwarding behaviors within the network interior to permit implementation of a wide variety of service behaviors, with room for future expansion." but this draft would erase that distinction, and (more RFC2475): "The following requirements were identified and are addressed in this architecture: o should accommodate a wide variety of services and provisioning policies, extending end-to-end or within a particular (set of) network(s), o should allow decoupling of the service from the particular application in use, ... o should decouple traffic conditioning and service provisioning functions from forwarding behaviors implemented within the core network nodes," Again DiffServ was explicit about the decoupling of services and = applications. Concern 2: The definition of Service Class and its relationship to = traffic aggregates. From RFC 2474: "Services are realized by the use of particular packet classification and traffic conditioning mechanisms at boundaries coupled with the concatenation of per-hop behaviors along the transit path of the traffic. A goal of the differentiated services architecture is to specify these building blocks for future extensibility, both of the number and type of the building blocks and of the services built from them." and the definition from standards track RFC2474: "Service: a description of the overall treatment of (a subset of) a customer's traffic across a particular domain, across a set of interconnected DS domains, or end-to-end. Service descriptions are covered by administrative policy and services are constructed by applying traffic conditioning to create behavior aggregates which experience a known PHB at each node within the DS domain. Multiple services can be supported by a single per-hop behavior used in concert with a range of traffic conditioners. To summarize, classifiers and traffic conditioners are used to = select which packets are to be added to behavior aggregates. Aggregates receive differentiated treatment in a DS domain and traffic conditioners MAY alter the temporal characteristics of the aggregate to conform to some requirements. A packet's DS field is used to designate the packet's behavior aggregate and is subsequently used = to determine which forwarding treatment the packet receives." This is turned inside out by this draft which talks about traffic = aggregates as though they were traffic streams, as defined by RFC 2475, = and invariant under edge conditioning and aggregation that must of = necessity occur inside any non-trivial network. The effects of = aggregation and the need to design PDBs and services to be careful of = these is discussed in RFC3086, reflecting DiffServ WG discussions. = First, from RFC 2475: "Traffic stream an administratively significant set of one or more microflows which traverse a path segment. A traffic stream may consist of the set of active microflows which are selected by a particular classifier." From the draft: "A Service Class as defined here is essentially a statement of the = required characteristics of a traffic aggregate; the actual = specification of the expected treatment of a traffic aggregate within a = domain may also be defined as a Per Domain Behavior [RFC3086]." This is the only place in the draft where RFC 3086, a product of the = DiffServ WG is mentioned. (There was no mention in the original.) From = RFC 3086's abstract, giving context for this RFC: "The next step is to formulate examples of how forwarding path components (PHBs, classifiers, and traffic conditioners) can be used to compose traffic aggregates whose packets experience specific forwarding characteristics as they transit a differentiated services domain. The WG has decided to use the term per-domain behavior, or PDB, to describe the behavior experienced by a particular set of packets as they cross a DS domain." and from RFC 3086's Introduction: "Diffserv classification and traffic conditioning are applied to packets arriving at the boundary of a DS domain to impose restrictions on the composition of the resultant traffic aggregates, as distinguished by the DSCP marking, inside the domain. The classifiers and traffic conditioners are set to reflect the policy and traffic goals for that domain and may be specified in a TCA (Traffic Conditioning Agreement). Once packets have crossed the DS boundary, adherence to diffserv principles makes it possible to = group packets solely according to the behavior they receive at each hop = (as selected by the DSCP). This approach has well-known scaling advantages, both in the forwarding path and in the control plane. Less well recognized is that these scaling properties only result if the per-hop behavior definition gives rise to a particular type of invariance under aggregation. Since the per-hop behavior must be equivalent for every node in the domain, while the set of packets marked for that PHB may be different at every node, PHBs should be defined such that their characteristics do not depend on the traffic volume of the associated BA on a router's ingress link nor on a particular path through the DS domain taken by the packets. Specifically, different streams of traffic that belong to the same traffic aggregate merge and split as they traverse the network. If the properties of a PDB using a particular PHB hold regardless of = how the temporal characteristics of the marked traffic aggregate change as it traverses the domain, then that PDB scales. " A per-hop behavior, which is just how a packet is forwarded at each = node, cannot directly result in a particular end-to-end, or even = edge-to-edge set of characteristics since it is dependent on how much = traffic is admitted and how traffic is mixed and so on. Which brings me = to: Concern 3: draft seems to equate requiring a uniform PHB with achieving = an end-to-end QoS. Contrast this with the RFC 2475 and 3086 approaches of having each = network domain specify the loss rate, maximum delay, and/or other = metrics which it will provide to traffic streams that conform to certain = agreed-upon (via SLS) behavior (e.g., interface, markings, rate). Though = work remains on how to put the values from a chain of networks together, = it is certain possible to figure out the maximum delay through a set of = networks with services so specified. At the same time, nothing need be known about network internals. If I am told that a traffic stream will be priority queued at every = router between two points, I am told nothing about the maximum delay the = packets will experience. In section 1.5.3 of the draft, "Expedited Forwarding PHB [RFC3246] behavior was originally proposed as a way to implement a virtual wire, and can be used in such a manner." The EF PHB was originally proposed as a *building block* to create a = service (then called virtual leased line) and both the original proposal = in RFC 2598 and the update in RFC 3246 were quite clear about this. From = RFC 2598: The EF PHB can be used to build a low loss, low latency, low jitter, assured bandwidth, end-to-end service through = DS domains. Such a service appears to the endpoints like a point-to- point connection or a "virtual leased line". ... Creating such a service has two parts: 1) Configuring nodes so that the aggregate has a well-defined minimum departure rate. ("Well-defined" means independent of the dynamic state of the node. In particular, independent of the intensity of other traffic at the node.) 2) Conditioning the aggregate (via policing and shaping) so that its arrival rate at any node is always less than that node's configured minimum departure rate. The EF PHB provides the first part of the service. The network boundary traffic conditioners described in [RFC2475] provide the second part. From RFC 3246: "The intent of the EF PHB is to provide a building block for low = loss, low delay, and low jitter services. The details of exactly how to build such services are outside the scope of this specification." and "Note that the EF PHB only defines the behavior of a single node. The specification of behavior of a collection of nodes is outside the scope of this document. A Per-Domain Behavior (PDB) specification [7] may provide such information." These DiffServ documents were clear that a PHB does not a service make. Finally, the draft specifies a lot of operational rules for networks. = This is inverted from the DiffServ WG approach of putting tools into the = hands of operators. Kathie Nichols _______________________________________________ tsvwg mailing list tsvwg@ietf.org https://www1.ietf.org/mailman/listinfo/tsvwg _______________________________________________ Dcpel mailing list Dcpel@ietf.org https://www1.ietf.org/mailman/listinfo/dcpel From dcpel-bounces@ietf.org Wed Nov 16 16:32:31 2005 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EcUtL-00081h-9w; Wed, 16 Nov 2005 16:32:31 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EcUtK-000806-1F for dcpel@megatron.ietf.org; Wed, 16 Nov 2005 16:32:30 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA01245 for ; Wed, 16 Nov 2005 16:31:56 -0500 (EST) Received: from outbound.mailhop.org ([63.208.196.171] ident=mailnull) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EcVAp-0003O1-1q for dcpel@ietf.org; Wed, 16 Nov 2005 16:50:36 -0500 Received: from c-24-6-155-12.hsd1.ca.comcast.net ([24.6.155.12] helo=[10.1.1.74]) by outbound.mailhop.org with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.51) id 1EcUtD-0000nk-9e for dcpel@ietf.org; Wed, 16 Nov 2005 16:32:23 -0500 X-Mail-Handler: MailHop Outbound by DynDNS X-Originating-IP: 24.6.155.12 X-Report-Abuse-To: abuse@dyndns.com (see http://www.mailhop.org/outbound/abuse.html for abuse reporting information) X-MHO-User: kmnichols Message-ID: <437BA56B.6010305@pollere.com> Date: Wed, 16 Nov 2005 13:32:27 -0800 From: Kathleen Nichols User-Agent: Thunderbird 1.4.1 (Macintosh/20051006) MIME-Version: 1.0 To: dcpel@ietf.org Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.1 (/) X-Scan-Signature: 08170828343bcf1325e4a0fb4584481c Content-Transfer-Encoding: 7bit Subject: [Dcpel] IETF meeting X-BeenThere: dcpel@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Mailing list for possible diffserv control plane elements WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: dcpel-bounces@ietf.org Errors-To: dcpel-bounces@ietf.org Folks, The slot we had in the Ops open area was complicated by folks thinking it was a BoF and so on. What we were looking for was to get interested parties involved. Several folks came to an informal working session on Tuesday and a problem statement draft is in preparation that captures the proposal we came up with jointly. I think the group came up with some useful and tractable problems and also good ways to use existing work. When it's done, the draft will be posted and hopefully we can incorporate any discussion into a second draft before the next IETF. Kathie _______________________________________________ Dcpel mailing list Dcpel@ietf.org https://www1.ietf.org/mailman/listinfo/dcpel From dcpel-bounces@ietf.org Mon Nov 21 04:36:41 2005 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Ee86L-0007sd-BG; Mon, 21 Nov 2005 04:36:41 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Ee86J-0007sV-29 for dcpel@megatron.ietf.org; Mon, 21 Nov 2005 04:36:40 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA16397 for ; Mon, 21 Nov 2005 04:36:01 -0500 (EST) Received: from deprox.docomolab-euro.com ([212.119.9.186]) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1Ee8Oj-0004yz-2X for dcpel@ietf.org; Mon, 21 Nov 2005 04:55:41 -0500 Received: from 172.27.10.3 by deprox.docomolab-euro.com (InterScan E-Mail VirusWall NT); Mon, 21 Nov 2005 10:36:00 +0100 Received: from [172.27.100.47] ([172.27.100.47]) by deex.docomolab-euro.com with Microsoft SMTPSVC(5.0.2195.4905); Mon, 21 Nov 2005 10:36:00 +0100 Message-ID: <438196C6.5000204@docomolab-euro.com> Date: Mon, 21 Nov 2005 10:43:34 +0100 From: Paulo Mendes User-Agent: Mozilla Thunderbird 1.0.2 (X11/20050317) X-Accept-Language: en-us, en MIME-Version: 1.0 To: "Pulliam, Jeffrey S" Subject: Re: [Dcpel] Purpose of a diffserv control plane References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 21 Nov 2005 09:36:00.0702 (UTC) FILETIME=[FBC21DE0:01C5EE7E] X-Spam-Score: 0.0 (/) X-Scan-Signature: dd887a8966a4c4c217a52303814d0b5f Content-Transfer-Encoding: 7bit Cc: dcpel@ietf.org X-BeenThere: dcpel@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Mailing list for possible diffserv control plane elements WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: dcpel-bounces@ietf.org Errors-To: dcpel-bounces@ietf.org Hi Jeffrey comments inline.. Pulliam, Jeffrey S wrote: >Pablo > >Good start on a requirements document. I suspect we will discuss >requirements a lot before this is done. A few comments: > >I generally agree with your assumptions in the ID you and Kathie >drafted, as well as the core requirements. There are points of concern >I would like to bring up. > >- Signaling Protocol Translations > >I fully concur with use of signaling protocols developed in other >efforts in the IETF. In addition to NSIS, we need to recognize >RSVP/ARSVP as an appropriate signaling protocol for use in a DiffServ >Control Plane. Further, we should give some thought to the possibility >that different domains will use different signaling protocols, and that >the interdomain control plane function should allow for / provide for >translation between signaling protocols. > > [Paulo] It is not the role of the requirements document to say what protocols should be used. IMO, different domain may use different protocols, if they fulfill the system requirements. The only protocol that different domain must have in common, it the inter-domain signalling protocol, which, as you say, must hide the intra-domain specialties, as said in section 5.3 of the document. >Your draft has the following language that heads in this direction > >***SNIP**** from the requirements draft >4.0 Assumptions >... > o Existing protocols, such as HTTP, COPS, SNMP, NETCONF, or the > NSIS protocol suite. >... > >5.2. Intra-domain Control > o There must be a common intra-domain interface, allowing network > elements to coordinate their actions, independently of the degree > of control distribution. This interface can by defined by > messages sent over protocols such as COPS, SNMP, or the NSIS > protocol suite. >***SNIP*** > >I recommend including RSVP/ARSVP in both lists of protocols. Also >suggest that specification of use of a specific signaling protocol >should be constrained to a single domain, or a single relationship >between two distinct domains. A domain should be free, and the control >plane should enable a domain to interact with other domains over >multiple signaling protocols, if necessary. But primarily, I don't want >to leave out the RSVP/ARSVP protocol suite, and think we need to >leverage the work currently underway focused on effecting precedence and >pre-emption, as well as security related issues. > > [Paulo] I'll add RSVP to the list of protocols that may be analyse against the requirements. >You identify two roles a domain can play, provider, and customer. What >do you think about subdividing the provider role into access provider, >and transit provider? One example of a transit provider is in the >assumptions in your draft > > [Paulo] I the document I don't mention two, but three roles: customer, provider, and both, this is customer-provider. In the case of access and transit network, I'll say that an access network can be a customer or a provider, while a transit network is a customer-provider network. >***SNIP*** from the requirements draft > >4. Assumptions >... > o For inter-domain considerations, although not all networks will be > > DiffServ, all will interact based on the same inter-domain control > interface. For instance, backbone networks may be over- > provisioned, but they will still offer and negotiate QoS > agreements with its neighbors. >... >***SNIP*** > >The overprovisioned backbone provider will communicate using the >DiffServ Control plane mechanisms, but will map all traffic to one of >it's offered services, and provide signaled, unimpeded, albeit >overprovisioned transit through it's domain as it's contribution to end >to end service delivery. The fact that it is an overprovisioned network >will be invisible to the neighboring interconnected diffserv domains. >Which is ok if that transit meets the allocated portion of the >end-to-end spec for the offered diffserv service? > > [Paulo] So, you agree with what is currently written in the ID document, right? >Media Dependent Requirements - > >So another recurring theme that seems to be in the requirements draft is >that different domain types will have different requirements that are >media dependent. In the draft, you mention mobile networks in a few >places, and the need to support mobile networks. It might be useful in >the requirements draft to isolate requirements that emerge that are >specific to mobile networks. Another network type that would be useful >to have addressed in the draft is satellite networks. A satellite >network can provide diffserv enabled services, but in the case of the >geostationary satellite, will impact the end to end guarantee of >latency. A useful requirement that is somewhat specific to satellite >networks is that when a network domain in unable to deliver services >within the spec for the end to end service, that it make an offer of >services to be delivered within a modified spec. For example, in a case >where end to end latency requirement is under 150ms, a geostationary >satellite network asked to participate might offer services with an >additional 260 - 300 ms latency, resulting in an end to end service with >410-460ms latency. > >I feel the need for a picture, and will take a swing at it and send when >complete. > > [Paulo] The mobility of networks may impact the inter-domain control only. So, I can create a sub-section to describe the requirements for moving networks in the inter-domain control section. However, I would like to generalize this to include not only moving networks but all kind of discontinuity. This before the mobility of network can be seen as a particular example of an environment in which networks may be mostly disconnected. This may not be the case in the backbone of the Internet, but may be the case of edge networks. In the case of satellite networks, I think that we can also generalize this situation, since any network may not be able to fulfill some e2e QoS requirements. The fact that a network may be allowed to offer services, may give to a customer some indication about what provider to select. For instance, in the example that you gave, if a customer network gets from a satellite provider network an offer of 260 - 300 ms, and a offer of 150 - 200 ms from another neighbour, it might decide to negotiate an agreement with the second provider and not with the satellite network. If this is what you are thinking about, I think that the following requirement is suitable: "The inter-domain interface must allow network domains to offer, request/negotiate, and monitor agreements/SLSs.". I can provide an example of this announcements and negotiations. >More Below > >Jeff > > > > *** Some part of my original mail removed *** > > >[[jeff]] So I support development of an information model for diffserv >control plane information, and this is certainly a part of the language >in point 1. There are some higher order concepts that we should attack >in route to the development of the information model, which includes a >list and definition of what should be in the information model, a list >of verbs that contains the actions performed by the control plane. > [Paulo] IMO the inclusion of requirements specific for this information model will be beneficial. I'll create a sub-section dedicated to identify the requirements of such information model. > > > >>2) where to implement the requests: in the I-D we refer as assumption >>the exiting of network-wide agents (agents with network-wide >>functionality) and local-agents (such as agents placed at the edges of >> >> >a > > >>network). These are the places to configure due to a set of requests. >>How to configure them depends on what functionalities we decide to >> >> >place > > >>in these two types of control elements, and on a needed intra-domain >>interface. >> >> > >[[jeff]] So this is a little different that Roberts point 2 - but is >important. My point, which Robert phrased fairly well, was that the >control plane needs to have logic for deciding how to implement the >request within the domain, and where necessary, to request services from >other domains. This is roughly equivalent to a routing IGP and EGP. > >I will be able to support a model for the control plane that is agent >based, that provides for implementation flexibility. > > [Paulo] My only concern at this point was to work a little on the type of network elements that we'll need to consider. I didn't want to write requirements to rule the behaviour of such agents. But I might say that the network-wide agent (a central or distributed element) may be responsible for the inter-domain control and making the needed interface to the local-agents, which may be responsible for the intra-domain control. For instance we can see the inter-domain responsibilities of a network-wide agent as a 'broker' to negotiate agreements between networks. And we can also see local-agents placed, implementing measurement-based or flow-based (supported by path-coupled signalling) admission control mechanisms, and allocating the needed resources to the requested PDB. > > > > >>4) the interaction with AAA is also referred in the I-D, in which an >>initial reference to authentication and trust is made, and in which is >>also said that "Authentication may be a part of the control plane, or >>may be an accessible external functionality". However, lots of work in >>the what concerns requirements still needs to be done. >> >> >[[jeff]] In particular on issues of trust, and use of authentication >services provided external to the diffserv control plane. I don't think >we want to create our own AAA function unless necessary, and in the case >of authentication and authorization, we should allow for use of whatever >the domain feels is necessary. > > [Paulo] Agree. This is why on requirements says that : "Authentication may be a part of the control plane, or may be an accessible external functionality." Is this what you meant? > > >>5) The need for a protocol to adjust the PDBs is also mentioned in >>section 5.4 of the I-D. That section provides a brief example of how a >>mechanism to implement the decision in the forwarding plane of a >>DiffServ domain may be done. Nevertheless, as said, we should look at >>existing protocols that may fit the needed requirements, of part of it >>(in the latter case, DCPEL may suggest extensions, modifications, etc, >>to those protocols). For instance, we could analyze how the NSIS >>proposals could be used for this propose, in order to signal several >>network elements in the data path (path formed by all routers crossed >> >> >by > > >>data packets) from one ingress to one egress point. To implement the >>mentioned inter-domain interface, IMO we need signaling decoupled from >>the data path. And since the elements involved in the signaling >> >> >process > > >>are only the initiator (one element in one domain) and the destination >>(one element in a neighbor domain), it is not clear if all the >>functionalities provided by NTLP are needed. So, needs to be analysed >>how can current proposals for off-path NSIS signalling fit some of the >>requirements of the DCPEL (intra or inter-domain). I'm saying this >> >> >since > > >>DCPEL aims, IMHO, to analyse network-to-network behaviors (traffic >>oriented!), and not end-to-end behaviors (flow oriented!). >> >> >[[jeff]] So I was in agreement until the last - the control plane either >needs to be able to translate a flow oriented requirement into a traffic >oriented policy, or something else does. So I expect we will want to >discuss this a bit. > > [Paulo] I agree that this needs more work, so at least I'm opened to discuss this. IMO, DCPEL will give DiffServ networks capability to dynamically control they internal resources, and to be able to interact with they neighbours. I think that the intra-domain and the inter-domain control are tight together, since changes inside a network may impact the inter-domain relationship, and vice-versa. So, within DCPEL what we have is network-to-network interactions and not end-to-end. However, we need then to analyse what type of relationship will DCPEL have with end-to-end signalling in oder to target e2e QoS assurance. Just to add another though to this issue, maybe in a chain of DCPEL networks, the e2e signalling to set resources for a flow may be simpler or faster, since what we may only need is a mechanism to check PDBs in each network. For instance we may use QoS-NSLP to signal only ingress points of DCPEL networks in order to trigger the needed PDB allocation. > > >>So, answering to your questions. IMO, DCPEL should aim to look at all >>these issues, since they are all needed to define the control elements >>of a DiffServ domain. Once more, it is up to us to schedule such work >>after a good understanding of assumptions and requirements. >> >>IMO, we need to discuss the problem statement and scope, the list of >>assumptions and the requirements for th e DCPEL. This will allow us to >>clearly define a charter with a coherent work priority. >> >> >[[jeff]] Agree - > > Paulo _______________________________________________ Dcpel mailing list Dcpel@ietf.org https://www1.ietf.org/mailman/listinfo/dcpel