Re: [cso] Some thoughts from the CSO Bar BOF...

Young Lee <ylee@huawei.com> Mon, 06 December 2010 22:23 UTC

Return-Path: <ylee@huawei.com>
X-Original-To: cso@core3.amsl.com
Delivered-To: cso@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 7245428C0D7 for <cso@core3.amsl.com>; Mon, 6 Dec 2010 14:23:21 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.349
X-Spam-Level:
X-Spam-Status: No, score=-6.349 tagged_above=-999 required=5 tests=[AWL=-0.050, BAYES_00=-2.599, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_MED=-4]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id QRqL27Rjt+zD for <cso@core3.amsl.com>; Mon, 6 Dec 2010 14:23:19 -0800 (PST)
Received: from usaga04-in.huawei.com (usaga04-in.huawei.com [206.16.17.180]) by core3.amsl.com (Postfix) with ESMTP id CDCD83A68CC for <cso@ietf.org>; Mon, 6 Dec 2010 14:23:18 -0800 (PST)
Received: from huawei.com (usaga04-in [172.18.4.101]) by usaga04-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0LD1003SV295AQ@usaga04-in.huawei.com> for cso@ietf.org; Mon, 06 Dec 2010 16:24:42 -0600 (CST)
Received: from L73682 ([10.124.12.79]) by usaga04-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTPA id <0LD100KCF2953M@usaga04-in.huawei.com> for cso@ietf.org; Mon, 06 Dec 2010 16:24:41 -0600 (CST)
Date: Mon, 06 Dec 2010 16:24:40 -0600
From: Young Lee <ylee@huawei.com>
In-reply-to: <201012031537.16993.mkuehle@ikr.uni-stuttgart.de>
To: =?iso-8859-1?Q?'Mirja_K=FChlewind'?= <mirja.kuehlewind@ikr.uni-stuttgart.de>, cso@ietf.org
Message-id: <005a01cb9594$6081aa40$4f0c7c0a@china.huawei.com>
MIME-version: 1.0
X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2900.3664
X-Mailer: Microsoft Office Outlook 11
Content-type: text/plain; charset=iso-8859-1
Content-transfer-encoding: quoted-printable
Thread-index: AcuS97YblfEKfo+hRX6WsOd2MSjcAwClR1dQ
References: <4CD9AEE4.1040600@grotto-networking.com> <201012031537.16993.mkuehle@ikr.uni-stuttgart.de>
Subject: Re: [cso] Some thoughts from the CSO Bar BOF...
X-BeenThere: cso@ietf.org
X-Mailman-Version: 2.1.9
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/listinfo/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: Mon, 06 Dec 2010 22:23:21 -0000

Hi Mirja,

In your question on scoping, please make sure to understand that we have
split the CSO work into two separate items per Ron Bonica's suggestion. He
thinks the original CSO scope was too broad and suggested the separation of
the work into two distinctive work although related:

(i) Network Aware Application Resource Assignment and Mobility (this would
belong to the application area)

(ii) Network Stratum Query (this belongs to the OPS area) 

The context of both works mentioned above is the Data Centers. I think this
is an effort to narrow down the scope/context to Data Center Networks (DCN)
from which a plethora of services originates as Greg and Kathy indicated in
their emails respectively. 

In work (i) we have narrowed down the issues pertaining global load
balancing. Please read Ning's draft on the constraints we are considering to
make load balancing "global" in the DCN. 

In work (ii), we try to define application/service profile that captures the
requirement of application. This has to be "general" enough to capture all
the applications. As to what information should be conveyed to network from
application is the main work of the potential WG. We simply illustrated in
the NQ Query draft what can be passed down to network from application. 

Please see in-line for my comment to some of your specific questions.
Thanks.

Regards,
Young

-----Original Message-----
From: cso-bounces@ietf.org [mailto:cso-bounces@ietf.org] On Behalf Of Mirja
K├╝hlewind
Sent: Friday, December 03, 2010 8:37 AM
To: cso@ietf.org
Subject: Re: [cso] Some thoughts from the CSO Bar BOF...

Hi,

I participated in both Bar BoFs and I believe that in the area of
Cross-Layer 
Optimization is still a lot of space to do thing better but I don't believe 
in a generic approach. 
I would like to response to the points below and also give some feedback to 
the charter. First the points below:

(a) If you would have the global system view which has all the information 
about the application and the network state, I'm sure its possible to 
optimize the system such that all players will benefit. But we are talking 
here about a distributed system where every player tries to maximize its own

benefit. I would say even if you provide the needed information you can't be

sure that automatically everybody will benefit. Moreover, you would have to 
give for every player the right incentives to actually make a decision that 
will optimize the whole system and not only the benefit of one single
player.
Moreover, if you have several entities/different point in different layers 
which make decisions based on the same information, you have to be very 
careful that those decisions will not be counterproductive. E.g. an 
application changes the coding to lower bitrate and the network reserves
more 
capacity at the same time. It's basically impossible to show the stability
of 
such a complex system. It's already hard to make any stability
investigations 
about multi-protocol networks.

YOUNG>> We neither talk about lowering bitrate in the application nor
resource reservation in the charter at this point. All the charter is
talking about is a simple query capability. We scoped down quite a bit from
the first Bar BOF held in Maastricht. 

YOUNG>> However, what you are saying here regarding the stability concern
between application and network is a valid point in the reservation system. 

(b) I still don't get your point here. As you say 'best effort' means that
you 
always try to get the maximum but you never know what the maximum is/what
you 
get. This doesn't go in-line for me with any kind of services guarantees. If

you want guarantees you can use e.g. resource reservation. But than you know

exactly what you get and you don't need any further cross-layer state 
information.

YOUNG>> I think Greg answered well on this point already. 

(c) You say: '... definition of a "data center" as something like "a
location 
within the network where application resources maybe aggregated". What? 
Is 'the network' in your case the Internet? I would say a data center is not

in the Internet. It maybe is at the border of the Internet but its a 
completely separated network were one entity has the control over all the 
physical devices within this network. That makes it easier to solve certain 
problems in a data center than in the Internet. But I don't see how it help 
to define the problem of CSO any better.

(d) Can you provide the pointers to all this material? But for me this 
examples look already so different that I wouldn't wanne try to find one 
generic solution for all of them. We just wrote an project proposal where
the 
original idea was to do something about cross-layer optimization. But as we 
couldn't define the problem clearly, we thought it might make more sense to 
look at specific problems (one certain application in one network scenario) 
and find a solution for those problems in such a that it is generic enough
to 
be used by other applications as well. (I have to say I'm working on 
transport protocols, so we were mainly focusing on solutions in the
transport 
layer with application layer information/for one specific application type).

YOUNG>> Greg did a great job for this. 

Some remarks about the charter:
- I still don't see which information you want to exchange. Whenever I asked

this question, I got the same two examples like delay and bandwidth. But I 
don't believe that any application developer does understand what to do with

these information. Btw. you can ask your socket interface for the congestion

window and the RTT. These information are basically similar but completely 
useless for the application. You could maybe use these information
aggregated 
over a certain time. This could give you an impression about the link state 
but still doesn't give you any guaranteed information for the future as the 
link state changes permanently.
It's a really complicated task to define an interface in such a that not
only 
the right information can be exchanged but they are also represented in the 
right what. It's not only what but also how.

YOUNG>> Regarding the what part ("right" information), this is a part of the
work to be defined once the WG has started. "How" part is implementation.
IETF does not deal with algorithm or methodology. 

- From the Bar BoF I had the impression that the problem is more about which

information should be exchanged but the charter is talking about a whole 
protocol. I would say to exchange information in one point between the
layers 
you don't need a protocol but an inferface. I don't believe that you can
find 
a generic interface here that will address all problems (and will be 
implemented by all kind of applications). I would assume that you have to 
change/extend the interface for every problem separately.
If you want a protocol to expose certain information within the same layer, 
this is completely different problem. This also goes in the direction of 
measuring and monitoring network state. There are tons of proposal for 
measuring all different kind of thing. And again I would say the solution 
differ a lot depending on what information you are aiming for. 

- One more general comment: Whenever you talk about CSO I have the feeling 
that you basically want to provide more information for the application. Why

not providing more information for the lower layers about the traffic 
characteristics, requirements and maybe even user preferences of the 
application? Should the information actually go in both directions or will 
this increase the possibility of counterproductive decision?

YOUNG>> This point is not actually correct. The application provides to the
network about its service/application profiles including location and the
connectivity (such as PP, P-MP, Anycast, etc.) and other QoS profile
associated with application including user-preference. And the network
provides to the application the abstract/summary of the network resources. 




Just my thoughts. I would like to start this discussion on the list, as I 
think this is an intresting topic but your proposal it not concrete enough 
for me to see the action points in the IETF. I'm an academic and do research

on this topic up to now.

Mirja


On Tuesday 09 November 2010 21:28:20 Greg Bernstein wrote:
> Hi folks interested in cross stratum optimization (CSO) a few thoughts
> on some of the interesting points raised at the Bar BOF and to possibly
> stimulate further discussion:
>
> (a) Who benefits from CSO? The application provider or the carrier? It
> seems to be viable CSO should benefit both. The network operator
> (carrier, ISP, IT department, etc...) should benefit from more effective
> utilization of network resources (links, switches, routers, etc...) and
> gain more flexibility in dealing with fault conditions. The application
> provider benefits from being able to offer either higher quality
> services or better assurances on service quality. Essentially the
> network operator gets to influence the placement of load on the network
> while the application provider gets information that allows them to
> optimize their resources along with their customers experience.
>
> (b) Isn't the Internet "best effort"? How can you talk of providing a
> better "network experience" to applications?
> First CSO isn't strictly aimed at the "Internet" in general, but would
> start with various network domains (LAN, OSPF area, AS, etc...). Also
> "best effort" is a somewhat misleading term since it doesn't take into
> account overall statistical quality measures that are very important to
> user experiences. For example 2000 sessions sharing a link on a first
> come first serve basis are considered "best effort" whether the link is
> a T1 or an OC-192 but will generally experience greatly different
> "average" QoS ;-) . Depending on the network context and technology
> various service level guarantees may be explicit or implicit.
>
> (c) What's a "data center" and do we include "hosts"? Folks interested
> in CSO come from a number application and network areas.  The essence is
> that guidance from the network provider to the application provider
> concerning network state and capability provides benefits to both. In
> one of the drafts we tried a definition of a "data center" as something
> like "a location within the network where application resources maybe
> aggregated".
> I'd say a "host" (or my laptop) would qualify. Other ideas?
>
> (d) Examples? During some of the background work for the CSO drafts we
> looked at a number of examples that we published in the original draft.
> We've also looked at "pre-CSO" type mechanisms that are being used to
> try and optimize applications. These include "old school" and "new
> school" CDN approaches,  load balancing within and between data centers
> (local versus global),  various papers dealing with local and wide area
> VM migration, and High Performance Computing applications (radio
> astronomy being an interest of mine). Would it be useful to organize
> these in some way? We had some of these in the original CLO draft but
> the overall length was getting to long.  For our WSON work we set up web
> pages to keep track not just editors copies of our drafts (for all to
> work with) but supplemental material (some of which was later published
> in IEEE/OSA journals).
>
> Just some thoughts from a jet lagged Californian ;-)
>
> Greg B.


_______________________________________________
cso mailing list
cso@ietf.org
https://www.ietf.org/mailman/listinfo/cso