Subject: Re: [Dcpel] Dcpel BoF support

From: Paulo Mendes <[email-masked]>
Date: Wed, 02 Nov 2005 20:33:11 +0100

Dear Attila,

as I mentioned before, i fully agree that inter-domain QoS control 
should be included in the charter, although probably with lower priority 
than the intra-domain study.

About the NSIS proposal for path-decoupled signalling. In my opinion 
path-decoupled signalling is well suitable for inter-domain QoS control, 
but it is still not clear to me what is the best solution, or if we can 
have more than one complementary solutions. In what concerns this issue, 
here are for now two questions:
- Should the inter-domain signalling go through 'QoS controllers' or 
should that signalling occur between 'QoS controllers'? The answer to 
this question requires some analysis of assumptions and goals.
- Will networks want to control traffic or flows?

Regards
Paulo

Attila Báder (IJ/ETH) wrote:

>Dear All,  
>
>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 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. 
>
>Best regards, Attila
>
>  
>
>>-----Original Message-----
>>From: [email-masked] [mailto:[email-masked]]
>>Sent: Thursday, October 27, 2005 7:19 PM
>>To: [email-masked]
>>Subject: Re: [Dcpel] Dcpel BoF support
>>
>>
>>Paulo Mendes wrote:
>>...
>>    
>>
>>>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.
>>>      
>>>
>>[Kathie]I believe division is the way to go, but I think we 
>>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.
>>
>><The "you" below refers to Olivier, not to me.>
>>    
>>
>>>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.
>>>      
>>>
>>[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.
>><again, the "you" below is Olivier, I think.>
>>    
>>
>>>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.
>>>      
>>>
>>Hmm, I don't think topology acquisition necessarily means 
>>"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 
>>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.
>>    
>>
>>>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.
>>
>>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
>>[email-masked]
>>https://www1.ietf.org/mailman/listinfo/dcpel
>>
>>    
>>
>
>_______________________________________________
>Dcpel mailing list
>[email-masked]
>https://www1.ietf.org/mailman/listinfo/dcpel
>
>  
>

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

---

From: Kathleen Nichols <[email-masked]>
Date: Wed, 02 Nov 2005 12:21:43 -0800

..
> 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.
> 
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