Re: [Dcpel] Dcpel BoF support

[Paulo Mendes <[e-mail]>]

  Hi Oliver,

some comments inline...

Olivier Dugeon wrote:

> Hi Paulo,
>
> Paulo Mendes a écrit :
>
>> Hi Olivier, Kathleen and all,
>>
>> It is good to know that the partners in IST EuQoS are planning to 
>> support this BoF. I was acquainted in joint QoS workshop of EuQoS and 
>> 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 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 
>> 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.
>>
>> You say that your focus in not on DiffServ to enforce QoS in the 
>> network, but on the definition of a Resource Manager framework. Good, 
>> but this Resource Management framework can still be defined with two 
>> modules for inter- and intra-domain, connected by a network 
>> interface. But, in what concerns the intra-domain resource control, I 
>> don't know why shouldn't we focus on DiffServ. First, the DiffServ 
>> model is clearly lacking a control plane; second, other QoS 
>> enforcement mechanisms, such 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.
>
>
> Ok, I'm writing a bit faster. I have in mind to built an open 
> framework 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 flexible. If we can achieve a such goal for DiffServ, 
> it could be easy to extend it to other technology. I'm agree that 
> DiffServ is lacking of a control plane and have great potential. 
> Concerning the quantitative support, do you have in mind Admission 
> Control and/or Resource Reservation ?

Both. Control of admission of new flows to the aggregate defined by the 
suitable PDB, and allocation of network resources to that PDB as needed. 
The latter issues as to do with the way the communication resources are 
divided between the implemented PDBs.

>
>>
>> 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", which will 
>> then need to collect topology information? Since a PDB is already 
>> defined in 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 
>> robustness and perhaps performance.
>
>
> Well, under the 'topology acquisition', I'm not thinking about a 
> centralized or distributed way of implementation. I'm just refering to 
> the quantitative support of QoS with DiffServ. To do this, it is 
> necessary to have a minimum knowledge of the controlled network in 
> order to perform admission control or resource reservation. Another 
> point is device configuration. If the QoS request is not following the 
> data path (i.e. coming from a SIP proxy for example) the topology 
> information is again mandatory to retrieve the correct ingress node in 
> order to configure it.

Agree. We have two options. Or the messages needed to updated the 
provision of PDBs follow the data path from ingress to egress (in this 
case the knowledge about the topology is as distributed as the routing), 
or the messages are originated in a element outside the data path (in 
this case, it seems that this element has to have a knowledge about the 
topology, not only from its point of view, but also from the point of 
view of any ingress device in the network).

>
>
>>
>> In what concerns the other standardization efforts, I would say that 
>> it would help a lot this BoF, if we had a brief document 
>> characterizing the differences between all these approaches to see 
>> where this BoF would fit.
>
>
> If you breifly look at the standardization efforts, you could obsrve 
> 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 
> core network which is completely the scope of the IETF.

If I can have something else. In the process of defining a possible 
charter, we should not forget that one reason that seems to be 
responsible for the postponing of the QoS issue in the 3GPP is the lack 
of IETF solutions to control QoS, and differentiate traffic, mainly 
between networks.

Paulo

>
> Cheers,
>
> Olivier
>



_______________________________________________
Dcpel mailing list
[e-mail]
https://www1.ietf.org/mailman/listinfo/dcpel