Re: [cso] survey on research on CSO

Leeyoung <> Tue, 29 November 2011 21:43 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 5A7AB21F8CDD for <>; Tue, 29 Nov 2011 13:43:01 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -2.598
X-Spam-Status: No, score=-2.598 tagged_above=-999 required=5 tests=[AWL=-0.000, BAYES_00=-2.599, HTML_MESSAGE=0.001]
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id 1qIdW8QYU3+D for <>; Tue, 29 Nov 2011 13:42:57 -0800 (PST)
Received: from ( []) by (Postfix) with ESMTP id 50EB221F8CDE for <>; Tue, 29 Nov 2011 13:42:57 -0800 (PST)
Received: from (EHLO ([]) by (MOS 4.2.3-GA FastPath) with ESMTP id ABJ26907; Tue, 29 Nov 2011 16:42:56 -0500 (EST)
Received: from ( by ( with Microsoft SMTP Server (TLS) id; Tue, 29 Nov 2011 13:39:59 -0800
Received: from ([]) by ([]) with mapi id 14.01.0270.001; Tue, 29 Nov 2011 13:39:51 -0800
From: Leeyoung <>
To: "Y. Richard Yang" <>, "" <>
Thread-Topic: [cso] survey on research on CSO
Thread-Index: AcypdAnzi3KLuceBQMe/+dHGBykHxAA88XCAAR2MntA=
Date: Tue, 29 Nov 2011 21:39:50 +0000
Message-ID: <>
References: <7AEB3D6833318045B4AE71C2C87E8E171819601E@dfweml501-mbx> <>
In-Reply-To: <>
Accept-Language: en-US, zh-CN
Content-Language: en-US
x-cr-hashedpuzzle: HS30 I+DO JI2j KCv5 Kj4z K/3B LSCR N+ru OjCt P/7F QABU SrVr SyJz Uzre U1pS WLlc; 2; YwBzAG8AQABpAGUAdABmAC4AbwByAGcAOwB5AHIAeQBAAGMAcwAuAHkAYQBsAGUALgBlAGQAdQA=; Sosha1_v1; 7; {6710A7B5-2A7E-47BF-8824-CCD549B01809}; bABlAGUAeQBvAHUAbgBnAEAAaAB1AGEAdwBlAGkALgBjAG8AbQA=; Tue, 29 Nov 2011 21:39:45 GMT; UgBFADoAIABbAGMAcwBvAF0AIABzAHUAcgB2AGUAeQAgAG8AbgAgAHIAZQBzAGUAYQByAGMAaAAgAG8AbgAgAEMAUwBPAA==
x-cr-puzzleid: {6710A7B5-2A7E-47BF-8824-CCD549B01809}
x-originating-ip: []
Content-Type: multipart/alternative; boundary="_000_7AEB3D6833318045B4AE71C2C87E8E1718B39F5Adfweml508mbxchi_"
MIME-Version: 1.0
X-CFilter-Loop: Reflected
Subject: Re: [cso] survey on research on CSO
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: This list is for pre-WG technical discussion of cross stratum optimization <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Tue, 29 Nov 2011 21:43:01 -0000

Hi Richard,

I concur with your analysis below. See in-line for my comment.


From: [] On Behalf Of Y. Richard Yang
Sent: Wednesday, November 23, 2011 3:14 PM
Subject: Re: [cso] survey on research on CSO

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.

YOUNG>> This is the heart of CSO research.

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

YOUNG>> Google person (Eddie Crabbe) mentioned that even 5-10% saving using cso-like mechanism would be huge. KT's Kun-Yul Park also reported that over-provisioning does not help the carrier. Buying more routers would not help carrier economics. They want to be  more intelligent and smart by ways of control and management from application to transport network.

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.

YOUNG>> This is one of the key CSO goals spelled out in the PPT I sent to the group.

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.

YOUNG>> Information abstraction to scale is one of the key CSO research goals.  We need to tackle network abstraction mechanism as well we application resource abstraction.



On 11/22/11 7:08 PM, Leeyoung wrote:

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,


cso mailing list<>