Re: [cso] survey on research on CSO

"Y. Richard Yang" <yry@cs.yale.edu> Wed, 23 November 2011 21:13 UTC

Return-Path: <yry@cs.yale.edu>
X-Original-To: cso@ietfa.amsl.com
Delivered-To: cso@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 89F0921F87FC for <cso@ietfa.amsl.com>; Wed, 23 Nov 2011 13:13:42 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.553
X-Spam-Level:
X-Spam-Status: No, score=-2.553 tagged_above=-999 required=5 tests=[AWL=0.045, BAYES_00=-2.599, HTML_MESSAGE=0.001]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id yIO-Wf5IYRLR for <cso@ietfa.amsl.com>; Wed, 23 Nov 2011 13:13:39 -0800 (PST)
Received: from vm-emlprdomr-05.its.yale.edu (vm-emlprdomr-05.its.yale.edu [130.132.50.146]) by ietfa.amsl.com (Postfix) with ESMTP id 7E45621F87E2 for <cso@ietf.org>; Wed, 23 Nov 2011 13:13:39 -0800 (PST)
Received: from dhcp-128-36-59-2.central.yale.edu (dhcp-128-36-59-2.central.yale.edu [128.36.59.2]) (authenticated bits=0) by vm-emlprdomr-05.its.yale.edu (8.14.4/8.14.4) with ESMTP id pANLDXoT004730 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Wed, 23 Nov 2011 16:13:35 -0500
Message-ID: <4ECD61FD.70606@cs.yale.edu>
Date: Wed, 23 Nov 2011 16:13:33 -0500
From: "Y. Richard Yang" <yry@cs.yale.edu>
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:8.0) Gecko/20111105 Thunderbird/8.0
MIME-Version: 1.0
To: cso@ietf.org
References: <7AEB3D6833318045B4AE71C2C87E8E171819601E@dfweml501-mbx>
In-Reply-To: <7AEB3D6833318045B4AE71C2C87E8E171819601E@dfweml501-mbx>
Content-Type: multipart/alternative; boundary="------------070005030903020805030903"
X-Scanned-By: MIMEDefang 2.71 on 130.132.50.146
Subject: Re: [cso] survey on research on CSO
X-BeenThere: cso@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: This list is for pre-WG technical discussion of cross stratum optimization <cso.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/cso>, <mailto:cso-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/cso>
List-Post: <mailto:cso@ietf.org>
List-Help: <mailto:cso-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/cso>, <mailto:cso-request@ietf.org?subject=subscribe>
X-List-Received-Date: Wed, 23 Nov 2011 21:13:42 -0000

Hi Young,

I support a more organized research effort on Cross Stratum 
Optimization. I feel that it is an important issue.

First a disclaimer, I attended only the CSO meeting at Quebec but missed 
this meeting at Taipei. Hence I have only limited info on the scope and 
goals of CSO from the attached ppt. Please correct me if I misunderstand 
some of the key goals of CSO.

In slide 4 of your attached ppt, CSO is "defined as cooperation between 
the application and network strata ...". I think that this is an 
important problem! The interactions/cooperation between app and net has 
been of interest in the research community.

One of the initial investigations on this topic, as I know of, started 
rigorously in the context of selfish routing (i.e., app directed routing 
w/o net). The initial results were reflected in both theoretical (e.g., 
a good summary is Roughgarden's Selfish Routing and Price of Anarchy 
thesis published by MIT Press in 2005) and real-trace-driven studies 
(e.g., our Selfish Routing paper in SIGCOMM 2003). I should say that the 
results were, in a sense, negative, in that the price-of-anarchy is low 
at linear cost functions (e.g., at low utilization); in certain sense, 
(app only) end-to-end control can have a bound on penalty. Transport 
adaption can also reduce penalty of no coordination. One can also bound 
the penalty by using "over-provision" (see Roughgarden's doubling 
capability bound).

However, the previous investigation also shows that net and app can 
interact poorly, if both conduct optimization, and the results depend on 
the mechanisms. An example we gave in the SIGCOMM'03 selfish routing 
paper was the poor interaction of (app) selfish routing and net TE (OSPF 
vs MPLS). One way to address the poor interaction is to make the network 
less responsive (i.e., not to react) and we looked along this line on 
the COPE TE approach (SIGCOMM'06) and then the R3 TE approach 
(SIGCOMM'10). But I believe that network responsive and joint net/app 
optimization can bring more benefits than app-oblivious net.

In a sense, the P4P framework in 2008 was also focused on net/app 
interactions. The specific problem domain was overlay (p2p) traffic 
selection. The theoretical framework is an app/net interface based on 
decomposition achieved by primal-dual. Such map-based net/app interface 
is also similar in spirit to the early Nimrod design. Some details on 
P4P can be found at our SIGCOMM'08 P4P paper. The Oracle approach of 
net/app gives yet another style of interface. In 2010, Freedman and 
Rexford and their students presented DONAR in SIGCOMM'10, and DONAR 
gives another interesting style of potential interface between app and 
the infrastructure (servers).

The purpose of the preceding examples is to show that app/net (or more 
generally app/infrastructure) coordination can raise interesting 
analysis and design issues. I believe that the fundamental value of net 
is to help net app to create values. Hence, interfaces between net to 
app is important. In recent talks, Scott Shenker proposes that a 
fundamental design issue of network is to come up with good 
abstractions. I feel that the basic abstractions between app and net for 
their coordination (net -> app feedback, and app->net command/hint) 
should be important abstractions and hence a more organized effort here 
can be quite valuable.

Thanks.

Richard

On 11/22/11 7:08 PM, Leeyoung wrote:
>
> Hi,
>
> Enclosed is the CSO research proposal PPT presented during the IRTF 
> Open Meeting. As previously sent meeting notes indicated, there is no 
> doubt that there is an interested party on CSO research and many 
> people have contributed to further this research in the past months.
>
> I'd like to take this opportunity to ask people on the mailing list if 
> they do/do not support forming a CSO research group. This information 
> will be used as a barometer to indicate the level of interest in the 
> community.
>
> If you do support forming a CSO research group, please say in your 
> reply, "support"; otherwise, "not support."
>
> Thanks in advance for your cooperation. Your response to this poll 
> will be very crucial in determining the future CSO research effort.
>
> Best Regards,
>
> Young
>
>
>
> _______________________________________________
> cso mailing list
> cso@ietf.org
> https://www.ietf.org/mailman/listinfo/cso