Subject: Re: [Supa] review of draft-cheng-supa-ddc-use-cases-01

From: Ying Cheng <[email-masked]>
Date: Thu, 11 Dec 2014 08:39:31 +0800

Hi Juergen,

Thanks a lot for your insightful comments and questions. Please kindly review the reponse in line.

BR,
Ying

2014-12-11 

Ying CHENG  程莹
China Unicom Network Technology Research Institute 中国联通网络技术研究院
Tel: +86-10-68799999-7702
Mobile: +86-18601102971

发件人： Juergen Schoenwaelder 
发送时间： 2014-12-08  22:22:11 
收件人： [email-masked] 
抄送： 
主题： [Supa] review of draft-cheng-supa-ddc-use-cases-01 
 
Hi,
I have read draft-cheng-supa-ddc-use-cases-01 and here are some
comments.
a) You introduce the term "Distributed Data Center" and "Internet Data
   Center". I am not sure how these terms relate to each other. There
   is a pointer to draft-karagiannis-supa-problem-statement-02 but
   then this document uses the term "Inter-Data Center". So do all
   these terms mean the same or are there subtle differences?   
[Ying] Data Center can be used for multiple purposes, one of which is IDC (Internet Data Center) providing host service for websites;  "Distributed Data Center" means data center geographically located in multiple places. "Inter-Data Center" means the connection or traffic between DCs.
b) It is not clear what 'DDC traffic' is. Is this the traffic between
   DCs, excluding any user traffic to/from DCs? What does it mean to
   'schedule' DDC traffic - I assume this is only possible within
   bounds for certain kinds of DDC traffic.
[Ying]"DDC traffic" means the traffic between DCs, excluding user traffic to/from DCs. Usually a DC has multiple external links, "schedule DDC traffic" is to make full use of the link bandwidth by steering the traffic, sometimes not 
directly to the destination via the shortest path due to comprehensive link utilization consideration.
c) When you talk about Value Added Services (VAS) and the creation and
   deletion of VAS, do you include the life-cycle management of service
   instances (e.g. virtual machines) or are you strictly focusing on
   the network aspects?
[Ying]This drafts focuses on the network aspect and makes it ready for VAS service deployment. Details of VM life-cycle management are out of the scope of this draft. 
d) What does ABPD stand for?
[Ying]It stands for Application-based Policy Decision, introduced by draft-zhou-aponf-architecture-03. The reference will be updated in next version of this draft.
e) There is a reference to I-D.adel-supa-configuration-model which I
   can't resolve. Did you mean draft-zaalouk-supa-configuration-model?
[Ying]Yes, you are right. We will correct this and add references section in the next version of the draft. 
f) I do not understand the bandwidth waste argument in section 5 if
   shortest paths are used. The example that you provide is that link
   T1 is only to be used up to a utilization of 80% and then a
   secondary path comes into play. This is a policy I assume. It is
   not clear from the text who imposes this policy. If it is the
   network provider, does setting up VPNs really change the routing
   policy? If the network operator wants to run the links at 80%
   capacity max, will he not find ways to enforce that? Is the idea
   that policies work against each other in this case? Or am I
   mis-understanding the example?
[Ying]The DCs operator enforce the policy; usually a DC has multiple external links; time and/or statistic based multiplexing is possible; traffic to a destination can be steered over multiple links.
      If only the shortest path algorithm is applied, that means over provisioning is required to support traffic at peak hours. We will enhance this scenario description in the next version of this draft.
g) For the use case in section 6, why do I need to run the
   synchronization over a special VPN tunnel? What happens if the
   synchronization does not finish within the lifetime of the VPN
   tunnel?
[Ying]The synchronization is at the service level, e.g. in a video website like youtube, a end user upload a short movie (to a data center); the operator of the website will want to distribute this movie to all other DCs, maybe not 
immediately.This kind of synchronization is not bound to a specific VPN; as long as there is network connection, then it is OK.
h) The use case in section 7 talks about Skype but then I wonder which
   role Skype plays _between_ data centers. Anyway, there has been
   lots of QoS work in the past. If your goal is to have low latency
   services between DCs, why would the proposed system do better than
   what got invented in the past?
[Ying]The links between DCs may have different QoS attributes.This example suggest that we can specify QoS requirement in policies when selecting path for specific traffic/flows.It will be useful for QoS sensitive traffic.
i) The last use case described in section 8 seems to be talking about
   bundling path capacity. How does this related to the use case
   describe in section 5? Are there again multiple actors involved? If
   so, do you envision that the network and DC operators
   collaboratively work together to optimize their policies or do you
   assume that DC operator policy tries to trick^Hoptimize the network
   operator policies?
[Ying]Section 5 and 8 are independent to each other. Section 8 give the flexibility of making full use of bandwidth. Of course, an alternative solution is to split the traffic into finer granularities, then send the flows into paths
 respectively. Additionally, we will try to describe the network and DC operators as independent parties, respectively. In many actual cases, they are performed by one single entity.
I guess the biggest question I have is about who are the independent
parties involved, how much policy do the independent parties control
themselves, which policy interfaces to the parties expose to others,
and what happens if policies do not necessarily align with each
other. In case you plan to revise this I-D, it may make sense to be
more explicit about the parties involved and what they control and
expose to other parties.
[Ying]In this draft, DCs operator is the key player. If DC users, like a website, have any new requirements, they will negotiate with DC operator via SLA. 
 
/js
-- 
Juergen Schoenwaelder           Jacobs University Bremen gGmbH
Phone: +49 421 200 3587         Campus Ring 1, 28759 Bremen, Germany
Fax:   +49 421 200 3103         <http://www.jacobs-university.de/>
_______________________________________________
Supa mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/supa

如果您错误接收了该邮件，请通过电子邮件立即通知我们。[email-masked]，即可以退订此邮件。我们将立即将您的信息从我们的发送目录中删除。
If you have received this email in error please notify us immediately by e-mail. Please reply to [email-masked] if you want to unsubscribe from this mail. We will immediately remove your information from our sending catalogue.

---

From: Juergen Schoenwaelder <[email-masked]>
Date: Thu, 11 Dec 2014 09:19:22 +0100

> [Ying]In this draft, DCs operator is the key player. If DC users, like a website, have any new requirements, they will negotiate with DC operator via SLA.

My question was primarily about the relationship between the entity
operating the DCs and the entity operating the network interconnecting
the DCs. Some of the use cases seem to talk about conflicting goals of
network and DC policies but this is generally a problem too hard to
solve by machines, in particular if independent organizations are
involved. Another option is that you talk about a system that is run
by the network operator and that allows DCs to request network
services without having to worry how they are provided. But then some
use cases seem to be unclear about that interface, i.e., when
requesting a certain transport service between DC A and DC B, it
should not matter how the links actually used are loaded as long as
the service is provided. In other words, the service abstraction and
the parties involved was not clear to me.

/js

---

From: Ying Cheng <[email-masked]>
Date: Thu, 11 Dec 2014 21:32:26 +0800

Hi Juregen,

Thanks for your elaborate comments. You are right. It is vague on the distinction between DC operator and network operator in the scenario description of the current ddc draft, which should be well defined as independent entities, respectively, especially in the developement stage of service model. This issue will be addressed in the next version with high priority.

BR,
Ying

2014-12-11 

Ying CHENG  程莹

发件人： Juergen Schoenwaelder 
发送时间： 2014-12-11  16:19:36 
收件人： Ying Cheng(联通集团联通网络技术研究院) 
抄送： [email-masked] 
主题： Re: [Supa] review of draft-cheng-supa-ddc-use-cases-01