I received your first note, and sent a note to ietf-action to see if we can get SpamAssassin tuned to appreciate you a little more…

Other comments inline.

On Apr 20, 2014, at 11:11 PM, 邓灵莉 <lingli.deng@139.com> wrote:

> Hi all,
>  
> It seemed that my last email did not get through, so I am resending it via another email account. Sorry if you get duplicate copies of the same content.
>  
> Looking forward to your comments and contribution.
>  
> Cheers,
> Lingli
> 
> 
> 
> 
> 
> <11112014031114574914m7.jpg>	
> 邓灵莉
> 职务：	研究员/Researcher
> 公司：	中国移动研究院/China Mobile Research Institute
> 地址：	北京宣武门西大街32号/32 Xuanwumenxi Ave, Beijing
> 邮箱：	lingli.deng@139.com
> 手机：	13810597148
> 邮编：	100053
> 日期：	2014年04月21日 星期一
>  
> ------------------ 原始邮件 ------------------
> 发件人: "邓灵莉/Lingli Deng" <denglingli@chinamobile.com>;
> 发送时间: 2014-04-21 13:58:41
> 收件人: "lingli.deng" <lingli.deng@139.com>;
> 抄送: (无);
> 主题: 转发: planning for ietf90
>  
>  
> 发件人: 邓灵莉/Lingli Deng [mailto:denglingli@chinamobile.com] 
> 发送时间: 2014年4月19日 10:34
> 收件人: 'dclc@irtf.org'
> 主题: planning for ietf90
>  
> Hi all,
>  
> From my impression, I believe people showed interest in the following topics, and would like to invite further discussion as we start planning for ietf 90.
>  
> 1, Production data sharing: 
> It seems it is generally agreed that it would be both highly desirable and generally hard to get real data from production DCs. 
> I suspect that a security personnel would naturally tend to say “NO” if he is asked to share a piece of raw data without knowing the risk it bears. Therefore, It may help if he is provided with a concrete list of aggregated metric/parameters, which is intended to outline the “vague big picture” rather than to capture “every sensitive detail”.
> Hence, I would suggest that we start working on a more concrete “specification” about what specific data would be helpful based on the experience from the research community on working on a general problem.
> Take the incast problem for instance, the distribution of flow duration/volume traversing a given bottleneck link may be of interest. What do you think?

I agree that a specification of “what constitutes incast” might be useful. Part of that will involve, for example, the worst case queue depth that happens when an incast event occurs, and how many communications of what kind are involved. If we ask for a literal traffic trace, as you say, the risk is high and value is low. However, if we were to provide some sort of filter that a set of traffic traces could be fed through might come up with a usable summary of the information. Suppose, for example, that we were able to place a wireshark on the links into the bottleneck (Distribution or top-of-rack) switch leading to a requesting host and leading from the TOR to the host:

                     Rack
  +------------+
  |Distribution|    +----+
  |  Switch    +----+TOR |
  +------------+    +----+
                    |    |
                    |    |
                    +----+
                    |Host|
                    +----+
                    |    |
                    |    |
                    |    |
                    +----+

and capture the seconds before to after the event. We should be able to describe that at the time of the event traffic was arriving into the rack at <some byte/packet rate>, and we saw <description of stream of requests> followed by <description of stream of responses>, followed by a return to ambient traffic. What I would expect we would observe is that the traffic before used some percentage of the link in a manner common to LANs, there was a crunch of data followed by some number of aftershocks as TCP did timeout retransmissions, and when the system returned to ambient behavior the competing traffic had largely been bludgeoned off the link and took a few seconds to recover. We should be able to describe that using anonymized addresses and not reporting potentially-private data.

I would suggest that the wiresharks be time-synchronized using IEEE 1588a if possible.

Would it make sense to post an internet draft describing this kind of thing so that anyone could comment and perhaps execute it?

> 2, Problem statement/analysis
> I believe it would be of great value to work on further exploring and better understanding the potential problems at least for the early phase of DCLC.
> It is essential to have merge the understanding from DC operators (use-cases/expectations), understanding from general research (e.g. exploration of the factors contributing to a given problem and how it would affect the expectations) and the understanding from device manufactures (e.g. device features that triggers the contributing factors and affects operator’s expectation).
> From a very high level, three types of use-cases (i.e. delay-sensitive distributed applications, virtualization, and multi-tenancy) and two types of problems (i.e. incast and bufferbloat) have been mentioned in our previous discussion. I would like to invite more input and concrete work on this direction.

Agreed

> 3, Solutions, of course
> Original ideas/on-going work/experience on application of existing technologies are all welcome. Comparison or general reasoning among different solutions would also be appreciated.

Agreed

> 4, research/experimental tools
> Original ideas/on-going work/experience on general simulation platform and testing guidelines (such as testing methodology and benchmarks) for DCLC relevant scenarios.
> (We have not been discussing this on the list, but as I am planning testing myself, I find it quite desirable and believe it would be a common call.)

Agreed

> These are the ideas from my side, any other thoughts or suggestions?
>  
> Looking forward to your feedback and contribution.
>  
> Cheers,
> Lingli
> _______________________________________________
> Dclc mailing list
> Dclc@irtf.org
> https://www.irtf.org/mailman/listinfo/dclc