From mirja.kuehlewind@ikr.uni-stuttgart.de Fri Dec 3 06:36:05 2010 Return-Path: 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 CF1E328C0EB for ; Fri, 3 Dec 2010 06:36:05 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.949 X-Spam-Level: X-Spam-Status: No, score=-1.949 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_DE=0.35, MIME_8BIT_HEADER=0.3] 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 B3JxeraB8Cqf for ; Fri, 3 Dec 2010 06:36:02 -0800 (PST) Received: from mailsrv.ikr.uni-stuttgart.de (mailsrv.ikr.uni-stuttgart.de [129.69.170.2]) by core3.amsl.com (Postfix) with ESMTP id 12D9C28C10E for ; Fri, 3 Dec 2010 06:36:02 -0800 (PST) Received: from netsrv1.ikr.uni-stuttgart.de (netsrv1-c [10.11.12.12]) by mailsrv.ikr.uni-stuttgart.de (Postfix) with ESMTP id C9FFE633B6 for ; Fri, 3 Dec 2010 15:37:17 +0100 (CET) Received: from vpn-2-cl177 (vpn-2-cl177 [10.41.21.177]) by netsrv1.ikr.uni-stuttgart.de (Postfix) with ESMTP id AE80A59A8A for ; Fri, 3 Dec 2010 15:37:17 +0100 (CET) From: Mirja =?iso-8859-1?q?K=FChlewind?= To: cso@ietf.org Date: Fri, 3 Dec 2010 15:37:16 +0100 User-Agent: KMail/1.9.10 (enterprise35 0.20090731.1005176) References: <4CD9AEE4.1040600@grotto-networking.com> In-Reply-To: <4CD9AEE4.1040600@grotto-networking.com> X-KMail-QuotePrefix: > MIME-Version: 1.0 Content-Type: Text/Plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 03 Dec 2010 14:36:06 -0000 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. (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. (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). 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. - 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? 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. From k.mcewen@verizon.net Fri Dec 3 09:11:45 2010 Return-Path: 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 C75D428C178 for ; Fri, 3 Dec 2010 09:11:44 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.594 X-Spam-Level: X-Spam-Status: No, score=-0.594 tagged_above=-999 required=5 tests=[AWL=-0.156, BAYES_20=-0.74, HTML_MESSAGE=0.001, MIME_8BIT_HEADER=0.3, UNPARSEABLE_RELAY=0.001] 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 h5dDvjlaM7bw for ; Fri, 3 Dec 2010 09:11:22 -0800 (PST) Received: from smtp103.vzn.mail.ne1.yahoo.com (smtp103.vzn.mail.ne1.yahoo.com [98.138.85.46]) by core3.amsl.com (Postfix) with SMTP id A3F0528C152 for ; Fri, 3 Dec 2010 09:11:20 -0800 (PST) Received: (qmail 75786 invoked from network); 3 Dec 2010 17:12:35 -0000 Received: from IridescentKathy (k.mcewen@12.133.149.197 with login) by smtp103.vzn.mail.ne1.yahoo.com with SMTP; 03 Dec 2010 09:12:34 -0800 PST X-Yahoo-SMTP: 0oTc.aiswBATml9UvnuZnOzzTXTzZTa6NV7Bbr9Wm3OL X-YMail-OSG: hIsD28IVM1lTnj7vuCmUJBP.Xbi.XIt9WrSqZzf95Kk7v4Y Ky1dvSbr2GJDhiyr_4M6Pjzc.pgZTQkna4wRYCusHmj.MOMRepJ6TOfUUhNa 0wQJpP1jb3ATGaBnC4w7_ITf9oSdkbXHbNLdg4eyGAmmiVAOMqJq6HNRFA.R PBxdLURPGid5jKzwzNvLwf84q.e1z00444ycFKPiAgsYR5iej0FiZs7TtKfg PW4gRiP_8Rw1XdFVoeqPDlx0m50RSIw5g0eWvM9H0cM7GxWCxM_V.TfQvGCO dZbtU3RQUZaxQdu1BWfWCeRZGRRk- X-Yahoo-Newman-Property: ymail-3 From: "Kathy McEwen" To: =?iso-8859-1?Q?'Mirja_K=FChlewind'?= , References: <4CD9AEE4.1040600@grotto-networking.com> <201012031537.16993.mkuehle@ikr.uni-stuttgart.de> In-Reply-To: <201012031537.16993.mkuehle@ikr.uni-stuttgart.de> Date: Fri, 3 Dec 2010 11:12:32 -0600 Message-ID: <021201cb930d$47fef420$d7fcdc60$@verizon.net> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0213_01CB92DA.FD6BB010" X-Mailer: Microsoft Outlook 14.0 Thread-index: AQJv1kZX/XuJxotsrHPd+W2rSDd5GgGHnBIqkjoZAxA= Content-Language: en-us 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 03 Dec 2010 17:11:45 -0000 This is a multipart message in MIME format. ------=_NextPart_000_0213_01CB92DA.FD6BB010 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Interesting thoughts, I have some additional comments inserted below... =20 -----Original Message----- From: cso-bounces@ietf.org [mailto:cso-bounces@ietf.org] On Behalf Of = Mirja K=FChlewind Sent: Friday, December 03, 2010 8:37 AM To: cso@ietf.org Subject: Re: [cso] Some thoughts from the CSO Bar BOF... =20 Hi, =20 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.=20 I would like to response to the points below and also give some feedback = to the charter. First the points below: =20 (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.=20 =20 KCM:: First of all, this is possible, we have built a system that is = taking both a global cross network view and implemented to be distributed = across networks and nodes. The protocols (Layers 2, 3/4, and 7) we have = defined do not attempt to "maximize" to the individual nodes benefit, rather to = enable a cross-network cooperation in negotiating resources and managing = delivery end-to-end. I am also aware of at least 2 or 3 other disruptive start = up competitors that are looking at doing something uncomfortably similar, = as well as numerous Tier 1 network equipment providers exploring ways to deliver exactly this functionality. =20 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. =20 KCM:: Agreed, which is why Layer 7 protocols are needed, to enable the network to share in intelligence about the "application" or "data" being communicated or delivered. In the case of any professional media = (music, video, news, entertainment, pictures, ...) there are strict "digital = rights" management that must be respected. There is also the need for monetization, and the same content that is protected, generally has an = owner that expects to be paid or has been paid for such content to be delivered/provided. Today there are "caches" created by Content = Delivery Network (CDN) companies, such as Akamai, Level 3, Limelight, ..., that = are fully aware of these "digital rights", and in many cases may participate = in the subscription/authentication portion of the exchange as they take = over the roles of caching entire websites. More and more, network providers = and content providers are moving in a direction of pushing content closer = and closer to the edges of networks. In the case of the internet, this traditionally has landed at broadband access providers peering points, = and is not really anywhere near the actual consumer edge. Many network providers are now looking at how to extend the CDN inside these = broadband ISP network borders, take a look at announcements from Verizon, = Telefonica, AT&T, DT, BT, etc.. CDN=92s interoperate with each other, acting as = their own overlay =93islands=94 in the networks, clearly benefiting them as one = single player. Today=92s CDN and IP/MPLS protocols do not cooperate to extend services in a managed way across multiple network domains. So, yes = some monetization is needed for these providers to agree to cooperate as = well, again this is something very well done in Layer 7, with subscription, billing, and admission control methods, without impacting the packet = flows at layer 1/2-3. By standardizing and agreeing on some protocols here perhaps this can enable many, many players, =85multiple network = providers, media providers and CDN providers, as well as application providers and consumers to benefit. =20 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. =20 KCM:: Agreed, which is the motivation to have clear APIs and standards = to enable communication of key information between layers 2/3, 7 and into = the application itself. If a connection is created source to destination, enabling a massive transfer of data at a very high bit rate, then the application decides to =93adapt=94 the codec rate, and doesn=92t inform = the network, then the only way for the network to =93know=94 the rate has = changed is to monitor the flows. Take video for example, one can do some level of = deep packet inspection to monitor the video control protocols (RTSP, RTMP, RTMP-WM, etc=85) for adaptive rate change messages coming up from the = clients (as this is how they all work today). But this is costly relative to a server actually sending a message in real time to notify the network = that a rate change is going to take place just before they start sending the modified rate. This application message can then be shared with the = lower layer 2/3 sub network systems to notify them to modify the capacity as = well. One only needs to take a look at the example posted to NANOG recently by = BBC of what is yet to come on the networks=85 =20 (Hot topic: Level 3 Communications Issues Statement Concerning Comcast's Actions) extracted from post: Whatever marketing feel like, there is no absolute High Definition, it's really Higher Definition where the reference is undefined. When access speeds get to 1Gbit/s they'll no doubt be unhappy that we = may stream something like this - http://www.bbc.co.uk/news/technology-11436939 http://www.bbc.co.uk/blogs/researchanddevelopment/2010/10/super-hi-vision= -tr ials =20 =20 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. =20 KCM:: Disagree, today=92s SS7 voice networks deliver voice globally, = across many network domain owners, fixed and wireless, out to endpoints that = are both digital and analog, across fiber (PON), coax/cable (DOCSYS, DS3), copper (DSL, ADSL, VDSL, T1/EI, =85) and the air (GSM, CDMA, AMPS, UMTS, = WiFi, WiMAX, =85 soon LTE), satellite links, and in many different container formats. Codecs are managed end to end, and negotiated in the mobile = domain to allow for end to end transcoding free connections, as well as = dynamically beginning a transcoding as needed if a user makes a handover to a = different system. The network nodes are all running Layer 7 protocols to achieve = the end to end cooperation, cut billing records (enabling monetization), = verify subscription/roaming rights (enabling monetization between providers), negotiate admission with =93reservation=94 that is totally aware of codec/bandwidth/L1/L2/L3 (including a large variety of TDM, IP, ATM and = MPLS protocols) and working in tight cooperation with those layers to achieve = the end to end globally connected Quality with stability that is in most = cases regulated to provide availability to 5 9=92s (99.999% of the time the = system is up and stably running =3D 5.26 minutes per year). Contrast this with = your average internet system availability, then perhaps you may be right.=20 =20 (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. =20 KCM:: Networks, even IP/MPLS are not just =93best effort=94 today, = they have DiffServ (TOS), ATM PVC, MPLS-TE/RSVP, etc. The data network providers offer private network connections with everything from very strict = service level agreements (SLA) to very loose or none. Unfortunately, today = these tight SLA agreements cannot easily be extended to applications demanding = the connections in real time. Is there any network provider that is = offering on-demand 2-3 Mbps connections source to destination within = milliseconds, or even seconds? Or even 1 Gbps connections? NTT, in the first CSO Bar = BoF in Europe did show that they have demonstrated it can be done with optical layer components given a request from applications. I wonder if they = used this to enable the BBC demo referenced above from London to Tokyo?? Wouldn=92t this be a cool thing to enable a very high definition = broadcast of a real time event at the London Summer 2012 Olympics across the net? Coordinated, in cooperation with multiple network and media providers = across UK, Canada, USA, Japan and the rest of the world. Conversely today, consumers and media providers alike depend on satellites, dedicated = access links from their edit/origination points to distribution points then out = to closed network Satellite, Broadcast, and Cable/IPTV. Consumers may not understand SLA and =93services guarantees=94 but they do understand = quality, they do pay for it, and they do change providers when they are = dissatisfied with the quality of the service they are experiencing. Application and media providers understand SLA very well, and they often go to great = lengths to ensure their consumers get the very best experience they can from = their web sites. Unfortunately, for consumers and these providers, today they cannot extend that guarantee through the ISP down to the consumer. =20 =20 (c) You say: '... definition of a "data center" as something like "a location within the network where application resources maybe = aggregated". What?=20 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. =20 KCM:: If you ignore the data center, you will be ignoring the = requirements of the end-to-end solution. The data center is the source on the web, = and the source can come from your PC (if you have your own web server on = one), a server at an enterprise, a server in a big data center, a CDN cache = server, or a network cache server. The location where the application resides could be on a mobile device, connecting to a server in the mobile = network or outside the mobile network. Understanding where the source and = destination points are, what they are capable of, and what protocols they are = capable of communicating or not, and how those applications and devices will = interwork with the network. Our solution (products and protocols), have = incorporated these requirements into a network solution that is capable of adapting = to the dynamic changing needs of the devices, access and the applications. Without an understanding of these it would be very difficult to define = what the Layer 7 protocols need (subscription, billing, service enablement) = and what they need to interwork with the Layer 2/3 protocols for an = end-to-end service delivery. =20 =20 (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). =20 KCM:: We have focused first on a specific application too, that being = video delivery from web sites to consumers.=20 =20 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. =20 - 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.=20 =20 - 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? =20 KCM:: We would be happy to interwork with other network equipment to = share some of our protocols and application information that could be shared across the layers, to enable the lower layers to work cooperatively with = the applications. We would very much like to see some movement within IETF, particularly around the layers in MPLS and optical that they do own the protocols for. We have some very innovative ways of handling video = packets, including for multicast/broadcast, that could easily be extending to = work cooperatively with other network platforms. On the Layer 7, application side, we have used much of the protocols defined in 3GPP, as our = solution is intended for both the fixed and mobile markets, and 3GPP has already = worked out all the mobility/roaming subscription/billing tricks in their = protocols. We plan to take what we have modified in the 3GPP protocols back to them = to see if they will extend their standards to incorporate these = modifications too. =20 =20 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. =20 Mirja =20 =20 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=20 > possibly stimulate further discussion: >=20 > (a) Who benefits from CSO? The application provider or the carrier? It = > seems to be viable CSO should benefit both. The network operator=20 > (carrier, ISP, IT department, etc...) should benefit from more=20 > effective utilization of network resources (links, switches, routers,=20 > etc...) and gain more flexibility in dealing with fault conditions.=20 > The application provider benefits from being able to offer either=20 > higher quality services or better assurances on service quality.=20 > Essentially the network operator gets to influence the placement of=20 > load on the network while the application provider gets information=20 > that allows them to optimize their resources along with their = customers experience. >=20 > (b) Isn't the Internet "best effort"? How can you talk of providing a=20 > 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=20 > "best effort" is a somewhat misleading term since it doesn't take into = > account overall statistical quality measures that are very important=20 > to user experiences. For example 2000 sessions sharing a link on a=20 > first come first serve basis are considered "best effort" whether the=20 > link is a T1 or an OC-192 but will generally experience greatly=20 > different "average" QoS ;-) . Depending on the network context and=20 > technology various service level guarantees may be explicit or = implicit. >=20 > (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=20 > is that guidance from the network provider to the application provider = > concerning network state and capability provides benefits to both. In=20 > one of the drafts we tried a definition of a "data center" as=20 > something like "a location within the network where application=20 > resources maybe aggregated". > I'd say a "host" (or my laptop) would qualify. Other ideas? >=20 > (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=20 > try and optimize applications. These include "old school" and "new=20 > school" CDN approaches, load balancing within and between data=20 > centers (local versus global), various papers dealing with local and=20 > wide area VM migration, and High Performance Computing applications=20 > (radio astronomy being an interest of mine). Would it be useful to=20 > organize these in some way? We had some of these in the original CLO=20 > draft but the overall length was getting to long. For our WSON work=20 > we set up web pages to keep track not just editors copies of our=20 > drafts (for all to work with) but supplemental material (some of which = > was later published in IEEE/OSA journals). >=20 > Just some thoughts from a jet lagged Californian ;-) >=20 > Greg B. =20 =20 _______________________________________________ cso mailing list cso@ietf.org https://www.ietf.org/mailman/listinfo/cso ------=_NextPart_000_0213_01CB92DA.FD6BB010 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable

Interesting thoughts, I have some additional = comments inserted below...

 

-----Original Message-----
From: = cso-bounces@ietf.org [mailto:cso-bounces@ietf.org] On Behalf Of Mirja = K=FChlewind
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.

 

KCM:: = =A0First of all, this is possible, we have built a system that is taking = both a global cross network view and implemented to be distributed = across networks and nodes.=A0 The protocols (Layers 2, 3/4, and 7) we = have defined do not attempt to "maximize" to the individual = nodes benefit, rather to enable a cross-network cooperation in = negotiating resources and managing delivery end-to-end.=A0 I am also = aware of at least 2 or 3 other disruptive start up competitors that are = looking at doing something uncomfortably similar, as well as numerous = Tier 1 network equipment providers exploring ways to deliver exactly = this functionality.

 

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.

 

KCM::=A0 Agreed, which is why Layer 7 protocols are = needed, to enable the network to share in intelligence about the = "application" or "data" being communicated or = delivered.=A0 In the case of any professional media (music, video, news, = entertainment, pictures, ...) there are strict "digital = rights" management that must be respected. =A0=A0There is also the = need for monetization, and the same content that is protected, generally = has an owner that expects to be paid or has been paid for such content = to be delivered/provided.=A0 =A0=A0Today there are "caches" = created by Content Delivery Network (CDN) companies, such as Akamai, = Level 3, Limelight, ..., that are fully aware of these "digital = rights", and in many cases may participate in the = subscription/authentication portion of the exchange as they take over = the roles of caching entire websites.=A0 More and more, network = providers and content providers are moving in a direction of pushing = content closer and closer to the edges of networks.=A0 In the case of = the internet, this traditionally has landed at broadband access = providers peering points, and is not really anywhere near the actual = consumer edge.=A0 Many network providers are now looking at how to = extend the CDN inside these broadband ISP network borders, take a look = at announcements from Verizon, Telefonica, AT&T, DT, BT, etc..=A0 = CDN’s interoperate with each other, acting as their own overlay = “islands” in the networks, clearly benefiting them as one = single player.=A0 Today’s CDN and IP/MPLS protocols do not = cooperate to extend services in a managed way across multiple network = domains.=A0 =A0=A0So, yes some monetization is needed for these = providers to agree to cooperate as well, again this is something very = well done in Layer 7, with subscription, billing, and admission control = methods, without impacting the packet flows at layer 1/2-3.=A0 =A0By = standardizing and agreeing on some protocols here perhaps this can = enable many, many players, …multiple network providers, media = providers and CDN providers, as well=A0 as application providers and = consumers to benefit.

 

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.

 

KCM::=A0 Agreed, which is the motivation to have = clear APIs and standards to enable communication of key information = between layers 2/3, 7 and into the application itself.=A0 If a = connection is created source to destination, enabling a massive transfer = of data at a very high bit rate, then the application decides to = “adapt” the codec rate, and doesn’t inform the = network, then the only way for the network to “know” the = rate has changed is to monitor the flows.=A0 Take video for example, one = can do some level of deep packet inspection to monitor the video control = protocols (RTSP, RTMP, RTMP-WM, etc…) for adaptive rate change = messages coming up from the clients (as this is how they all work = today).=A0 But this is costly relative to a server actually sending a = message in real time to notify the network that a rate change is going = to take place just before they start sending the modified rate.=A0 This = application message can then be shared with the lower layer 2/3 sub = network systems to notify them to modify the capacity as well.=A0 =A0One = only needs to take a look at the example posted to NANOG recently by BBC = of what is yet to come on the networks…

 

(Hot topic: Level 3 Communications Issues = Statement Concerning Comcast's Actions) extracted from = post:

Whatever marketing feel like, there is no = absolute High Definition, it's really Higher Definition where the = reference is undefined.

When access speeds get to 1Gbit/s they'll no = doubt be unhappy that we may stream something like this = -

http://www.bbc.co.= uk/news/technology-11436939

http://www.bbc.co.uk/blogs/researchanddevelopment/20= 10/10/super-hi-vision-trials

 

 

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.

 

KCM::=A0 Disagree, today’s SS7 voice networks = deliver voice globally, across many network domain owners, fixed and = wireless, out to endpoints that are both digital and analog, across = fiber (PON), coax/cable (DOCSYS, DS3), copper (DSL, ADSL, VDSL, T1/EI, = …) and the air (GSM, CDMA, AMPS, UMTS, WiFi, WiMAX, … soon = LTE), satellite links, and in many different container formats.=A0 = Codecs are managed end to end, and negotiated in the mobile domain to = allow for end to end transcoding free connections, as well as = dynamically beginning a transcoding as needed if a user makes a handover = to a different system.=A0 The network nodes are all running Layer 7 = protocols to achieve the end to end cooperation, cut billing records = (enabling monetization), verify subscription/roaming rights (enabling = monetization between providers), =A0negotiate admission with = “reservation” that is totally aware of = codec/bandwidth/L1/L2/L3 (including a large variety of TDM, IP, ATM and = MPLS protocols) and working in tight cooperation with those layers to = achieve the end to end globally connected Quality with stability that is = in most cases regulated to provide availability to 5 9’s (99.999% = of the time the system is up and stably running =3D 5.26 minutes per = year).=A0 Contrast this with your average internet system availability, = then perhaps you may be right.

 

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

 

KCM::=A0 =A0Networks, even IP/MPLS are not just = “best effort” today, they have DiffServ (TOS), ATM PVC, = MPLS-TE/RSVP, etc.=A0 The data network providers offer private network = connections with everything from very strict service level agreements = (SLA) to very loose or none.=A0 Unfortunately, today these tight SLA = agreements cannot easily be extended to applications demanding the = connections in real time.=A0 Is there any network provider that is = offering on-demand 2-3 Mbps connections source to destination within = milliseconds, or even seconds?=A0 Or even 1 Gbps connections?=A0 NTT, in = the first CSO Bar BoF in Europe did show that they have demonstrated it = can be done with optical layer components given a request from = applications.=A0=A0 I wonder if they used this to enable the BBC demo = referenced above from London to Tokyo??=A0 Wouldn’t this be a cool = thing to enable a very high definition broadcast of a real time event at = the London Summer 2012 Olympics across the net?=A0 Coordinated, in = cooperation with multiple network and media providers across UK, Canada, = USA, Japan and the rest of the world.=A0 Conversely today, consumers and = media providers alike depend on satellites, dedicated access links from = their edit/origination points to distribution points then out to closed = network Satellite, Broadcast, and Cable/IPTV.=A0 Consumers may not = understand SLA and “services guarantees” but they do = understand quality, they do pay for it, and they do change providers = when they are dissatisfied with the quality of the service they are = experiencing.=A0 Application and media providers understand SLA very = well, and they often go to great lengths to ensure their consumers get = the very best experience they can from their web sites.=A0 = Unfortunately, for consumers and these providers, today they cannot = extend that guarantee through the ISP down to the consumer. = =A0=A0=A0=A0=A0

 

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

 

KCM:: =A0If you ignore the data center, you will = be ignoring the requirements of the end-to-end solution.=A0 The data = center is the source on the web, and the source can come from your PC = (if you have your own web server on one), a server at an enterprise, a = server in a big data center, a CDN cache server, or a network cache = server.=A0=A0 The location where the application resides could be on a = mobile device, connecting to a server in the mobile network or outside = the mobile network.=A0 Understanding where the source and destination = points are, what they are capable of, and what protocols they are = capable of communicating or not, and how those applications and devices = will interwork with the network.=A0 Our solution (products and = protocols), have incorporated these requirements into a network solution = that is capable of adapting to the dynamic changing needs of the = devices, access and the applications. =A0=A0Without an understanding of = these it would be very difficult to define what the Layer 7 protocols = need (subscription, billing, service enablement) and what they need to = interwork with the Layer 2/3 protocols for an end-to-end service = delivery.=A0 =A0

 

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

 

KCM:: =A0We = have focused first on a specific application too, that being video = delivery from web sites to consumers.

 

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.

 

- 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?

 

KCM:: =A0We would be happy to interwork with = other network equipment to share some of our protocols and application = information that could be shared across the layers, to enable the lower = layers to work cooperatively with the applications.=A0 We would very = much like to see some movement within IETF, particularly around the = layers in MPLS and optical that they do own the protocols for.=A0 We = have some very innovative ways of handling video packets, including for = multicast/broadcast, that could easily be extending to work = cooperatively with other network platforms.=A0 On the Layer 7, = application side, we have used much of the protocols defined in 3GPP, as = our solution is intended for both the fixed and mobile markets, and 3GPP = has already worked out all the mobility/roaming subscription/billing = tricks in their protocols.=A0 We plan to take what we have modified in = the 3GPP protocols back to them to see if they will extend their = standards to incorporate these modifications too.=A0=A0=A0 =

 

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.=A0 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,=A0 load balancing within and between data

> centers (local versus global),=A0 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.=A0 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/mail= man/listinfo/cso

------=_NextPart_000_0213_01CB92DA.FD6BB010-- From gregb@grotto-networking.com Mon Dec 6 10:45:15 2010 Return-Path: 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 922353A687D for ; Mon, 6 Dec 2010 10:45:14 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.002 X-Spam-Level: X-Spam-Status: No, score=0.002 tagged_above=-999 required=5 tests=[BAYES_50=0.001, HTML_MESSAGE=0.001] 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 RNUKgUW+162v for ; Mon, 6 Dec 2010 10:44:47 -0800 (PST) Received: from mail32c40.carrierzone.com (mail32c40.carrierzone.com [209.235.156.172]) by core3.amsl.com (Postfix) with ESMTP id E7B073A6852 for ; Mon, 6 Dec 2010 10:44:46 -0800 (PST) X-Authenticated-User: gregb.grotto-networking.com Received: from [192.168.0.124] (c-71-202-41-133.hsd1.ca.comcast.net [71.202.41.133]) (authenticated bits=0) by mail32c40.carrierzone.com (8.13.6/8.13.1) with ESMTP id oB6Ik7rj026798 for ; Mon, 6 Dec 2010 18:46:09 GMT Message-ID: <4CFD2F6C.6040300@grotto-networking.com> Date: Mon, 06 Dec 2010 10:46:04 -0800 From: Greg Bernstein User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.1; en-US; rv:1.9.2.12) Gecko/20101027 Lightning/1.0b2 Thunderbird/3.1.6 MIME-Version: 1.0 To: cso@ietf.org References: <4CD9AEE4.1040600@grotto-networking.com> <201012031537.16993.mkuehle@ikr.uni-stuttgart.de> In-Reply-To: <201012031537.16993.mkuehle@ikr.uni-stuttgart.de> Content-Type: multipart/alternative; boundary="------------080408050107070102000903" X-CSC: 0 X-CHA: v=1.1 cv=/R9yLkzXQF1AkW1rvynMMP1Ds2c3RiDiXcXDyRV60RM= c=1 sm=1 a=oFQL7mihLikA:10 a=OkPnmgdRXU7//wtL+yd+jg==:17 a=48vgC7mUAAAA:8 a=__L-i5l9aq-x8ISOJsYA:9 a=-ad44Z0AOpXh7zzPZHcA:7 a=0Yl0Op2PzXTHOO1_z_v9Zx82wrgA:4 a=wPNLvfGTeEIA:10 a=EgY3od2ZU2QA:10 a=pA-Ff6K6GocA:10 a=h-I_03WOSDMA:10 a=lZB815dzVvQA:10 a=fTL90a6gCzz9ZAjR:21 a=UMfTl4Tdk4W-zZzx:21 a=bdawPHtWnb86HWdSwtYA:9 a=oI7aGPPd2X0a1kbEpeUA:7 a=cHxs_2z2RKhESPUeuZmUD9p-BasA:4 a=CNw7plz2xtgXveQz:21 a=1t_aZc76AOp-F8CY:21 a=OkPnmgdRXU7//wtL+yd+jg==:117 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 06 Dec 2010 18:45:15 -0000 This is a multi-part message in MIME format. --------------080408050107070102000903 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit Hi Mirja, lots of good questions. See comments below. Note when some of us were (and still are) working on WSON efforts in the CCAMP working group we had very good interactions with researchers at Universities and other institutes. Best Regards Greg B. On 12/3/2010 6:37 AM, Mirja Kühlewind wrote: > 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. --> Our job in trying to develop standards is to find the "common ground" between various approaches not to constrain solutions. For example in the (Path computation entity) PCE working group various mechanisms were put in place to support problems of a particular type (e.g. concurrent optimization of paths), however no algorithms are specified as part of that effort. In GMPLS routing various types of useful information for path computation can be distributed, e.g., a shared risk link group (SRLG) indicator for a link, however a network using GMPLS may or may not distribute SRLG information via routing. > 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. --> Hmm, I know that Kathy M. responded to this point and her response made sense to me, but this brings up an interesting issue concerning the entities (or actors) involved. I see three main sets of actors: (a) the application service provider (possibly distributed in locations around a "network"), (b) the "network" (in its most complicated an interconnected set of independently managed domains, in its simplest a LAN under a single administration), (c) users of the application service (lots of them in different places around the network). Hence I guess I primarily see interactions between the application service provider and the "network" on behalf of the application service's users rather than a competition between all three to maximize some type of individual benefit. > 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. --> Lots of good points in here and this hits the notion of what "timescales" are we talking about optimizing over. Efficiently planning and provisioning a multi-layer network is a non-trivial task. It usually starts with some type of information on traffic demand (traffic matrix historical information and estimates). This is done for rather long timescales, while various forms of congestion control work on shorter time scales. I would say that we are trying to do something in between, kind of like Connection Admission Control, but taking into account application service flexibility too. > (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. --> Kathy M. addressed this... > (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. --> Hmm, I thought in one of our documents or discussions we discussed that we are interested in: (a) user to data center networking, (b) intra-data center networking (the data center applications making good use of the data centers local network), and (c) inter-data center networking. In all cases we are interested in application quality and networking resources. See the papers by A. Greenberg's group on data center networks (things are changing...). > (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). --> See end of e-mail for references... > 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. --> This is a bit of an application "traffic engineering" problem hence a "general" application developer probably wouldn't know what to do with it today, but they are getting more sophisticated and have been dealing with server performance issues for quite some time so I don't see this as preventing CSO being used. > 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. --> Current CDNs do a lot of these types of measurements but in a bit more sophisticated way to estimate bandwidth and delay. > 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. --> Folks at the IETF and other standards bodies are always challenged with this issue, can't escape it. > - 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. --> Its a bit early to say. At the IETF we try to reuse as much as possible. First step is always getting a good handle on the problem space, from that everything seems to flow... > 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). --> Our goal isn't to address all problems or to enable some type of "global optimization" to occur. Our goal is to enable better (improved) use of network and application resources through the sharing of a limited amount of information between these two entities. For example reference [33] shows how an application overlay network and server selection can be performed based on relatively limited information and how this is an improvement over no information sharing. > 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? --> Good question. We've had some discussions about where a CSO entity would be located (application layer or network layer) and hence who should be sharing what kind of information. It currently seems that application services and their internal structure are changing at a rapid pace and hence may be hard to come up with a generic abstract model. While for those of us in the networking field it seems like we've been dealing with links, nodes, bandwidth, delay, jitter models for quite some time ;-) > 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. --> Remember that as a standards effort we are very constrained into what aspects of this area we would actually take on. From a research & development point of view things are wide open. > Mirja > > > On Tuesday 09 November 2010 21:28:20 Greg Bernstein wrote: >> snip --> references [1]J. van der Ham, F. Dijkstra, P. Grosso, R. van der Pol, A. Toonk, and C. de Laat, "A distributed topology information system for optical networks based on the semantic web," /Optical Switching and Networking/,vol. 5, Jun. 2008, pp. 85-93. [2]E. Walker, "Creating private network overlays for high performance scientific computing," /Proceedings of the ACM/IFIP/USENIX 2007 International Conference on Middleware/,Newport Beach, California: Springer-Verlag New York, Inc., 2007, pp. 204-222. [3]Y. Birk and V. Zdornov, "Improving communication-phase completion times in HPC clusters through congestion mitigation," /Proceedings of SYSTOR 2009: The Israeli Experimental Systems Conference/,Haifa, Israel: ACM, 2009, pp. 1-11. [4]Y. Deng and F. Wang, "A heterogeneous storage grid enabled by grid service," /SIGOPS Oper. Syst. Rev./,vol. 41, 2007, pp. 7-13. [5]P. Andrews, P. Kovatch, and C. Jordan, "Massive High-Performance Global File Systems for Grid computing," /Proceedings of the 2005 ACM/IEEE conference on Supercomputing/, IEEE Computer Society, 2005, p. 53. [6]A. Caminero, O. Rana, B. Caminero, and C. Carrión, "An autonomic network-aware scheduling architecture for grid computing," /Proceedings of the 5th international workshop on Middleware for grid computing: held at the ACM/IFIP/USENIX 8th International Middleware Conference/,Newport Beach, California: ACM, 2007, pp. 1-6. [7]F.D. Berman, R. Wolski, S. Figueira, J. Schopf, and G. Shao, "Application-level scheduling on distributed heterogeneous networks," /Proceedings of the 1996 ACM/IEEE conference on Supercomputing (CDROM)/,Pittsburgh, Pennsylvania, United States: IEEE Computer Society, 1996, p. 39. [8]Young Choon Lee and A. Zomaya, "Data Sharing Pattern Aware Scheduling on Grids," /2006 International Conference on Parallel Processing (ICPP'06)/,Columbus, OH, USA: , pp. 365-372. [9]C.A. Lee, J. Stepanek, R. Wolski, C. Kesselman, and I. Foster, "A network performance tool for grid environments," /Proceedings of the 1999 ACM/IEEE conference on Supercomputing (CDROM)/,Portland, Oregon, United States: ACM, 1999, p. 4. *[10]E. Kissel, M. Swany, and A. Brown, "Improving GridFTP performance using the Phoebus session layer," /Proceedings of the Conference on High Performance Computing Networking, Storage and Analysis/,Portland, Oregon: ACM, 2009, pp. 1-10. [11]Y. Yan and B. Chapman, "Scientific workflow scheduling in computational gridsPlanning, reservation, and data/network-awareness," /Proceedings of the 8th IEEE/ACM International Conference on Grid Computing/, IEEE Computer Society, 2007, pp. 18-25. *[12]S. Venugopal, R. Buyya, and K. Ramamohanarao, "A taxonomy of Data Grids for distributed data sharing, management, and processing," /ACM Comput. Surv./,vol. 38, 2006, p. 3. *[13]Y. Lin, B. Kemme, M. Patino-Martinez, and R. Jimenez-Peris, "Applying database replication to multi-player online games," /Proceedings of 5th ACM SIGCOMM workshop on Network and system support for games/,Singapore: ACM, 2006, p. 15. *[14]K.K. Ramakrishnan, P. Shenoy, and J.V.D. Merwe, "Live data center migration across WANs: a robust cooperative context aware approach," /Proceedings of the 2007 SIGCOMM workshop on Internet network management/,Kyoto, Japan: ACM, 2007, pp. 262-267. *[15]Z. Duan, Z. Zhang, and Y.T. Hou, "Service overlay networks: SLAs, QoS, and bandwidth provisioning," /IEEE/ACM Trans. Netw./,vol. 11, 2003, pp. 870-883. [16]B.S. Davie and J. Medved, "A programmable overlay router for service provider innovation," /Proceedings of the 2nd ACM SIGCOMM workshop on Programmable routers for extensible services of tomorrow/,Barcelona, Spain: ACM, 2009, pp. 1-6. *[17]N. Carlsson and D.L. Eager, "Server selection in large-scale video-on-demand systems," /ACM Trans. Multimedia Comput. Commun. Appl./,vol. 6, 2010, pp. 1-26. *[18]Zongming Fei, M. Ammar, and E. Zegura, "Multicast server selection: problems, complexity, and solutions," /Selected Areas in Communications, IEEE Journal on/,vol. 20, 2002, pp. 1399-1413. *[19]J. Almeida, D. Eager, M. Vernon, and S. Wright, "Minimizing Delivery Cost in Scalable Streaming Content Distribution Systems," /IEEE Transactions on Multimedia/,vol. 6, 2004, pp. 356-365. *[20]A. Bar-Noy and R.E. Ladner, "Competitive on-line stream merging algorithms for media-on-demand," /Proceedings of the twelfth annual ACM-SIAM symposium on Discrete algorithms/,Washington, D.C., United States: Society for Industrial and Applied Mathematics, 2001, pp. 364-373. [21]K.A. Hua and S. Sheu, "Skyscraper broadcasting: a new broadcasting scheme for metropolitan video-on-demand systems," /Proceedings of the ACM SIGCOMM '97 conference on Applications, technologies, architectures, and protocols for computer communication/,Cannes, France: ACM, 1997, pp. 89-100. [22]D. Eager, M. Vernon, and J. Zahorjan, "Minimizing bandwidth requirements for on-demand data delivery," /Knowledge and Data Engineering, IEEE Transactions on/,vol. 13, 2001, pp. 742-757. [23]M. Guo, M.H. Ammar, and E.F. Zegura, "Selecting among replicated batching video-on-demand servers," /Proceedings of the 12th international workshop on Network and operating systems support for digital audio and video/,Miami, Florida, USA: ACM, 2002, pp. 155-163. [24]E.W. Zegura, M.H. Ammar, Z. Fei, and S. Bhattacharjee, "Application-layer anycasting: a server selection architecture and use in a replicated Web service," /IEEE/ACM Trans. Netw./,vol. 8, 2000, pp. 455-466. [25]F. Thouin and M. Coates, "Equipment allocation in video-on-demand network deployments," /ACM Trans. Multimedia Comput. Commun. Appl./,vol. 5, 2008, pp. 1-22. *[26]Y.R. Chen, R. Jana, D. Stern, B. Wei, M. Yang, and H. Sun, "Zebroid: using IPTV data to support peer-assisted VoD content delivery," /Proceedings of the 18th international workshop on Network and operating systems support for digital audio and video/,Williamsburg, VA, USA: ACM, 2009, pp. 115-120. [27]J.M. Dyaberi, K. Kannan, and V.S. Pai, "Storage optimization for a peer-to-peer video-on-demand network," /Proceedings of the first annual ACM SIGMM conference on Multimedia systems/,Phoenix, Arizona, USA: ACM, 2010, pp. 59-70. [28]A.A. Mahimkar, Z. Ge, A. Shaikh, J. Wang, J. Yates, Y. Zhang, and Q. Zhao, "Towards automated performance diagnosis in a large IPTV network," /Proceedings of the ACM SIGCOMM 2009 conference on Data communication/,Barcelona, Spain: ACM, 2009, pp. 231-242. *[29]S. Das and J. Kangasharju, "Evaluation of network impact of content distribution mechanisms," /Proceedings of the 1st international conference on Scalable information systems/,Hong Kong: ACM, 2006, p. 35. [30]B. Krishnamurthy, C. Wills, and Y. Zhang, "On the use and performance of content distribution networks," /Proceedings of the 1st ACM SIGCOMM Workshop on Internet Measurement/,San Francisco, California, USA: ACM, 2001, pp. 169-182. *[31]P. Krishnan, D. Raz, and Y. Shavitt, "The cache location problem," /Networking, IEEE/ACM Transactions on/,vol. 8, 2000, pp. 568-582. [32]E. Cronin, S. Jamin, Cheng Jin, A. Kurc, D. Raz, and Y. Shavitt, "Constrained mirror placement on the Internet," /Selected Areas in Communications, IEEE Journal on/,vol. 20, 2002, pp. 1369-1382. **[33]S. Ratnasamy, M. Handley, R. Karp, and S. Shenker, "Topologically-aware overlay construction and server selection," /INFOCOM 2002. Twenty-First Annual Joint Conference of the IEEE Computer and Communications Societies. Proceedings. IEEE/, 2002, pp. 1190-1199 vol.3. [34]S. Gargolinski, C.S. Pierre, and M. Claypool, "Game server selection for multiple players," /Proceedings of 4th ACM SIGCOMM workshop on Network and system support for games/,Hawthorne, NY: ACM, 2005, pp. 1-6. [35]P. Quax, J. Dierckx, B. Cornelissen, G. Vansichem, and W. Lamotte, "Dynamic server allocation in a real-life deployable communications architecture for networked games," /Proceedings of the 7th ACM SIGCOMM Workshop on Network and System Support for Games/,Worcester, Massachusetts: ACM, 2008, pp. 66-71. [36]J. Jardine and D. Zappala, "A hybrid architecture for massively multiplayer online games," /Proceedings of the 7th ACM SIGCOMM Workshop on Network and System Support for Games/,Worcester, Massachusetts: ACM, 2008, pp. 60-65. [37]S.D. Webb, S. Soh, and W. Lau, "Enhanced mirrored servers for network games," /Proceedings of the 6th ACM SIGCOMM workshop on Network and system support for games/,Melbourne, Australia: ACM, 2007, pp. 117-122. [38]P.B. Beskow, K. Vik, P. Halvorsen, and C. Griwodz, "Latency reduction by dynamic core selection and partial migration of game state," /Proceedings of the 7th ACM SIGCOMM Workshop on Network and System Support for Games/,Worcester, Massachusetts: ACM, 2008, pp. 79-84. [39]K. Vik, C. Griwodz, and P. Halvorsen, "Applicability of group communication for increased scalability in MMOGs," /Proceedings of 5th ACM SIGCOMM workshop on Network and system support for games/,Singapore: ACM, 2006, p. 2. *[40]C. Chambers and W. Feng, "Patch scheduling for on-line games," /Proceedings of 4th ACM SIGCOMM workshop on Network and system support for games/,Hawthorne, NY: ACM, 2005, pp. 1-6. [41]T. Jehaes, D.D. Vleeschauwer, T. Coppens, B.V. Doorselaer, E. Deckers, W. Naudts, K. Spruyt, and R. Smets, "Access network delay in networked games," /Proceedings of the 2nd workshop on Network and system support for games/,Redwood City, California: ACM, 2003, pp. 63-71. [42]F. Lu, S. Parkin, and G. Morgan, "Load balancing for massively multiplayer online games," /Proceedings of 5th ACM SIGCOMM workshop on Network and system support for games/,Singapore: ACM, 2006, p. 1. [43]J. Färber, "Network game traffic modelling," /Proceedings of the 1st workshop on Network and system support for games/,Braunschweig, Germany: ACM, 2002, pp. 53-57. [44]M. Suznjevic, M. Matijasevic, and O. Dobrijevic, "Action specific Massive Multiplayer Online Role Playing Games traffic analysis: case study of World of Warcraft," /Proceedings of the 7th ACM SIGCOMM Workshop on Network and System Support for Games/,Worcester, Massachusetts: ACM, 2008, pp. 106-107. [45]P. Tarng, K. Chen, and P. Huang, "An analysis of WoW players' game hours," /Proceedings of the 7th ACM SIGCOMM Workshop on Network and System Support for Games/,Worcester, Massachusetts: ACM, 2008, pp. 47-52. Virtualization Related: [1]C. Clark et al., "Live migration of virtual machines," in /Proceedings of the 2nd conference on Symposium on Networked Systems Design \& Implementation - Volume 2/, pp. 273-286, 2005. [2]R. Bradford, E. Kotsovinos, A. Feldmann, and H. Schiöberg, "Live wide-area migration of virtual machines including local persistent state," in /Proceedings of the 3rd international conference on Virtual execution environments/, pp. 169-179, 2007. [3]E. Harney, S. Goasguen, J. Martin, M. Murphy, and M. Westall, "The efficacy of live virtual machine migrations over the internet," in /Proceedings of the 2nd international workshop on Virtualization technology in distributed computing/, pp. 1-7, 2007. [4]A. Kadav and M. M. Swift, "Live migration of direct-access devices," /SIGOPS Oper. Syst. Rev./, vol. 43, no. 3, pp. 95-104, 2009. [5]A. Stage and T. Setzer, "Network-aware migration control and scheduling of differentiated virtual machine workloads," in /Proceedings of the 2009 ICSE Workshop on Software Engineering Challenges of Cloud Computing/, pp. 9-14, 2009. [6]H. Liu, H. Jin, X. Liao, L. Hu, and C. Yu, "Live migration of virtual machine based on full system trace and replay," in /Proceedings of the 18th ACM international symposium on High performance distributed computing/, pp. 101-110, 2009. [7]P. Barham et al., "Xen and the art of virtualization," in /Proceedings of the nineteenth ACM symposium on Operating systems principles/, pp. 164-177, 2003. [8]D. Nurmi et al., "The Eucalyptus Open-Source Cloud-Computing System," in /Cluster Computing and the Grid, 2009. CCGRID '09. 9th IEEE/ACM International Symposium on/, pp. 124-131, 2009. [9]A. Greenberg, P. Lahiri, D. A. Maltz, P. Patel, and S. Sengupta, "Towards a next generation data center architecture: scalability and commoditization," in /Proceedings of the ACM workshop on Programmable routers for extensible services of tomorrow/, pp. 57-62, 2008. [10]T. Benson, A. Anand, A. Akella, and M. Zhang, "Understanding data center traffic characteristics," /SIGCOMM Comput. Commun. Rev./, vol. 40, no. 1, pp. 92-99, 2010. [11]N. Feamster, J. Borkenhagen, and J. Rexford, "Guidelines for interdomain traffic engineering," /SIGCOMM Comput. Commun. Rev./, vol. 33, no. 5, pp. 19-30, 2003. [12]P. Costa, T. Zahn, A. Rowstron, G. O'Shea, and S. Schubert, "Why should we integrate services, servers, and networking in a data center?," in /Proceedings of the 1st ACM workshop on Research on enterprise networking/, pp. 111-118, 2009. [13]A. Greenberg et al., "VL2: a scalable and flexible data center network," in /Proceedings of the ACM SIGCOMM 2009 conference on Data communication/, pp. 51-62, 2009. [14]A. Greenberg, J. Hamilton, D. A. Maltz, and P. Patel, "The cost of a cloud: research problems in data center networks," /SIGCOMM Comput. Commun. Rev./, vol. 39, no. 1, pp. 68-73, 2009. > > _______________________________________________ > cso mailing list > cso@ietf.org > https://www.ietf.org/mailman/listinfo/cso > -- =================================================== Dr Greg Bernstein, Grotto Networking (510) 573-2237 --------------080408050107070102000903 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Hi Mirja, lots of good questions.  See comments below. Note when some of us were (and still are) working on WSON efforts in the CCAMP working group we had very good interactions with researchers at Universities and other institutes.

Best Regards

Greg B.

On 12/3/2010 6:37 AM, Mirja Kühlewind wrote: 
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.
--> Our job in trying to develop standards is to find the "common ground" between various approaches not to constrain solutions. For example in the (Path computation entity) PCE working group various mechanisms were put in place to support problems of a particular type (e.g. concurrent optimization of paths), however no algorithms are specified as part of that effort. In GMPLS routing various types of useful information for path computation can be distributed, e.g., a shared risk link group (SRLG) indicator for a link, however a network using GMPLS may or may not distribute SRLG information via routing.
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.
--> Hmm, I know that Kathy M. responded to this point and her response made sense to me, but this brings up an interesting issue concerning the entities (or actors) involved.  I see three main sets of actors: (a) the application service provider (possibly distributed in locations around a "network"), (b) the "network" (in its most complicated an interconnected set of independently managed domains, in its simplest a LAN under a single administration), (c) users of the application service (lots of them in different places around the network).
Hence I guess I primarily see interactions between the application service provider and the "network" on behalf of the application service's users rather than a competition between all three to maximize some type of individual benefit.
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.
--> Lots of good points in here and this hits the notion of what "timescales" are we talking about optimizing over. Efficiently planning and provisioning a multi-layer network is a non-trivial task.  It usually starts with some type of information on traffic demand (traffic matrix historical information and estimates). This is done for rather long timescales, while various forms of congestion control work on shorter time scales.  I would say that we are trying to do something in between, kind of like Connection Admission Control, but taking into account application service flexibility too.
(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.
--> Kathy M. addressed this...
(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.
--> Hmm, I thought in one of our documents or discussions we discussed that we are interested in: (a) user to data center networking, (b) intra-data center networking (the data center applications making good use of the data centers local network), and (c) inter-data center networking.  In all cases we are interested in application quality and networking resources.  See the papers by A. Greenberg's group on data center networks (things are changing...).
(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).
--> See end of e-mail for references...
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.
-->  This is a bit of an application "traffic engineering" problem hence a "general" application developer probably wouldn't know what to do with it today, but they are getting more sophisticated and have been dealing with server performance issues for quite some time so I don't see this as preventing CSO being used.
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.
--> Current CDNs do a lot of these types of measurements but in a bit more sophisticated way to estimate bandwidth and delay.
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.
--> Folks at the IETF and other standards bodies are always challenged with this issue, can't escape it.
- 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.
--> Its a bit early to say.  At the IETF we try to reuse as much as possible.  First step is always getting a good handle on the problem space, from that everything seems to flow...
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).
--> Our goal isn't to address all problems or to enable some type of "global optimization" to occur. Our goal is to enable better (improved) use of network and application resources through the sharing of a limited amount of information between these two entities.  For example reference [33] shows how an application overlay network and server selection can be performed based on relatively limited information and how this is an improvement over no information sharing.
 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?
-->  Good question. We've had some discussions about where a CSO entity would be located (application layer or network layer) and hence who should be sharing what kind of information. It currently seems that application services and their internal structure are changing at a rapid pace and hence may be hard to come up with a generic abstract model. While for those of us in the networking field it seems like we've been dealing with links, nodes, bandwidth, delay, jitter models for quite some time ;-) 
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.
--> Remember that as a standards effort we are very constrained into what aspects of this area we would actually take on.  From a research & development point of view things are wide open.
Mirja


On Tuesday 09 November 2010 21:28:20 Greg Bernstein wrote:

snip
--> references

[1]    J. van der Ham, F. Dijkstra, P. Grosso, R. van der Pol, A. Toonk, and C. de Laat, “A distributed topology information system for optical networks based on the semantic web,” Optical Switching and Networking,  vol. 5, Jun. 2008, pp. 85-93.

[2]    E. Walker, “Creating private network overlays for high performance scientific computing,” Proceedings of the ACM/IFIP/USENIX 2007 International Conference on Middleware,  Newport Beach, California: Springer-Verlag New York, Inc., 2007, pp. 204-222.

[3]    Y. Birk and V. Zdornov, “Improving communication-phase completion times in HPC clusters through congestion mitigation,” Proceedings of SYSTOR 2009: The Israeli Experimental Systems Conference,  Haifa, Israel: ACM, 2009, pp. 1-11.

[4]    Y. Deng and F. Wang, “A heterogeneous storage grid enabled by grid service,” SIGOPS Oper. Syst. Rev.,  vol. 41, 2007, pp. 7-13.

[5]    P. Andrews, P. Kovatch, and C. Jordan, “Massive High-Performance Global File Systems for Grid computing,” Proceedings of the 2005 ACM/IEEE conference on Supercomputing, IEEE Computer Society, 2005, p. 53.

[6]    A. Caminero, O. Rana, B. Caminero, and C. Carrión, “An autonomic network-aware scheduling architecture for grid computing,” Proceedings of the 5th international workshop on Middleware for grid computing: held at the ACM/IFIP/USENIX 8th International Middleware Conference,  Newport Beach, California: ACM, 2007, pp. 1-6.

[7]    F.D. Berman, R. Wolski, S. Figueira, J. Schopf, and G. Shao, “Application-level scheduling on distributed heterogeneous networks,” Proceedings of the 1996 ACM/IEEE conference on Supercomputing (CDROM),  Pittsburgh, Pennsylvania, United States: IEEE Computer Society, 1996, p. 39.

[8]    Young Choon Lee and A. Zomaya, “Data Sharing Pattern Aware Scheduling on Grids,” 2006 International Conference on Parallel Processing (ICPP'06),  Columbus, OH, USA: , pp. 365-372.

[9]    C.A. Lee, J. Stepanek, R. Wolski, C. Kesselman, and I. Foster, “A network performance tool for grid environments,” Proceedings of the 1999 ACM/IEEE conference on Supercomputing (CDROM),  Portland, Oregon, United States: ACM, 1999, p. 4.

*[10]  E. Kissel, M. Swany, and A. Brown, “Improving GridFTP performance using the Phoebus session layer,” Proceedings of the Conference on High Performance Computing Networking, Storage and Analysis,  Portland, Oregon: ACM, 2009, pp. 1-10.

[11]  Y. Yan and B. Chapman, “Scientific workflow scheduling in computational grids   Planning, reservation, and data/network-awareness,” Proceedings of the 8th IEEE/ACM International Conference on Grid Computing, IEEE Computer Society, 2007, pp. 18-25.

*[12]  S. Venugopal, R. Buyya, and K. Ramamohanarao, “A taxonomy of Data Grids for distributed data sharing, management, and processing,” ACM Comput. Surv.,  vol. 38, 2006, p. 3.

*[13]  Y. Lin, B. Kemme, M. Patino-Martinez, and R. Jimenez-Peris, “Applying database replication to multi-player online games,” Proceedings of 5th ACM SIGCOMM workshop on Network and system support for games,  Singapore: ACM, 2006, p. 15.

*[14]  K.K. Ramakrishnan, P. Shenoy, and J.V.D. Merwe, “Live data center migration across WANs: a robust cooperative context aware approach,” Proceedings of the 2007 SIGCOMM workshop on Internet network management,  Kyoto, Japan: ACM, 2007, pp. 262-267.

*[15]  Z. Duan, Z. Zhang, and Y.T. Hou, “Service overlay networks: SLAs, QoS, and bandwidth provisioning,” IEEE/ACM Trans. Netw.,  vol. 11, 2003, pp. 870-883.

[16]  B.S. Davie and J. Medved, “A programmable overlay router for service provider innovation,” Proceedings of the 2nd ACM SIGCOMM workshop on Programmable routers for extensible services of tomorrow,  Barcelona, Spain: ACM, 2009, pp. 1-6.

*[17]  N. Carlsson and D.L. Eager, “Server selection in large-scale video-on-demand systems,” ACM Trans. Multimedia Comput. Commun. Appl.,  vol. 6, 2010, pp. 1-26.

*[18]  Zongming Fei, M. Ammar, and E. Zegura, “Multicast server selection: problems, complexity, and solutions,” Selected Areas in Communications, IEEE Journal on,  vol. 20, 2002, pp. 1399-1413.

*[19]  J. Almeida, D. Eager, M. Vernon, and S. Wright, “Minimizing Delivery Cost in Scalable Streaming Content Distribution Systems,” IEEE Transactions on Multimedia,  vol. 6, 2004, pp. 356-365.

*[20]  A. Bar-Noy and R.E. Ladner, “Competitive on-line stream merging algorithms for media-on-demand,” Proceedings of the twelfth annual ACM-SIAM symposium on Discrete algorithms,  Washington, D.C., United States: Society for Industrial and Applied Mathematics, 2001, pp. 364-373.

[21]  K.A. Hua and S. Sheu, “Skyscraper broadcasting: a new broadcasting scheme for metropolitan video-on-demand systems,” Proceedings of the ACM SIGCOMM '97 conference on Applications, technologies, architectures, and protocols for computer communication,  Cannes, France: ACM, 1997, pp. 89-100.

[22]  D. Eager, M. Vernon, and J. Zahorjan, “Minimizing bandwidth requirements for on-demand data delivery,” Knowledge and Data Engineering, IEEE Transactions on,  vol. 13, 2001, pp. 742-757.

[23]  M. Guo, M.H. Ammar, and E.F. Zegura, “Selecting among replicated batching video-on-demand servers,” Proceedings of the 12th international workshop on Network and operating systems support for digital audio and video,  Miami, Florida, USA: ACM, 2002, pp. 155-163.

[24]  E.W. Zegura, M.H. Ammar, Z. Fei, and S. Bhattacharjee, “Application-layer anycasting: a server selection architecture and use in a replicated Web service,” IEEE/ACM Trans. Netw.,  vol. 8, 2000, pp. 455-466.

[25]  F. Thouin and M. Coates, “Equipment allocation in video-on-demand network deployments,” ACM Trans. Multimedia Comput. Commun. Appl.,  vol. 5, 2008, pp. 1-22.

*[26]  Y.R. Chen, R. Jana, D. Stern, B. Wei, M. Yang, and H. Sun, “Zebroid: using IPTV data to support peer-assisted VoD content delivery,” Proceedings of the 18th international workshop on Network and operating systems support for digital audio and video,  Williamsburg, VA, USA: ACM, 2009, pp. 115-120.

[27]  J.M. Dyaberi, K. Kannan, and V.S. Pai, “Storage optimization for a peer-to-peer video-on-demand network,” Proceedings of the first annual ACM SIGMM conference on Multimedia systems,  Phoenix, Arizona, USA: ACM, 2010, pp. 59-70.

[28]  A.A. Mahimkar, Z. Ge, A. Shaikh, J. Wang, J. Yates, Y. Zhang, and Q. Zhao, “Towards automated performance diagnosis in a large IPTV network,” Proceedings of the ACM SIGCOMM 2009 conference on Data communication,  Barcelona, Spain: ACM, 2009, pp. 231-242.

*[29]  S. Das and J. Kangasharju, “Evaluation of network impact of content distribution mechanisms,” Proceedings of the 1st international conference on Scalable information systems,  Hong Kong: ACM, 2006, p. 35.

[30]  B. Krishnamurthy, C. Wills, and Y. Zhang, “On the use and performance of content distribution networks,” Proceedings of the 1st ACM SIGCOMM Workshop on Internet Measurement,  San Francisco, California, USA: ACM, 2001, pp. 169-182.

*[31]  P. Krishnan, D. Raz, and Y. Shavitt, “The cache location problem,” Networking, IEEE/ACM Transactions on,  vol. 8, 2000, pp. 568-582.

[32]  E. Cronin, S. Jamin, Cheng Jin, A. Kurc, D. Raz, and Y. Shavitt, “Constrained mirror placement on the Internet,” Selected Areas in Communications, IEEE Journal on,  vol. 20, 2002, pp. 1369-1382.

**[33]  S. Ratnasamy, M. Handley, R. Karp, and S. Shenker, “Topologically-aware overlay construction and server selection,” INFOCOM 2002. Twenty-First Annual Joint Conference of the IEEE Computer and Communications Societies. Proceedings. IEEE, 2002, pp. 1190-1199 vol.3.

[34]  S. Gargolinski, C.S. Pierre, and M. Claypool, “Game server selection for multiple players,” Proceedings of 4th ACM SIGCOMM workshop on Network and system support for games,  Hawthorne, NY: ACM, 2005, pp. 1-6.

[35]  P. Quax, J. Dierckx, B. Cornelissen, G. Vansichem, and W. Lamotte, “Dynamic server allocation in a real-life deployable communications architecture for networked games,” Proceedings of the 7th ACM SIGCOMM Workshop on Network and System Support for Games,  Worcester, Massachusetts: ACM, 2008, pp. 66-71.

[36]  J. Jardine and D. Zappala, “A hybrid architecture for massively multiplayer online games,” Proceedings of the 7th ACM SIGCOMM Workshop on Network and System Support for Games,  Worcester, Massachusetts: ACM, 2008, pp. 60-65.

[37]  S.D. Webb, S. Soh, and W. Lau, “Enhanced mirrored servers for network games,” Proceedings of the 6th ACM SIGCOMM workshop on Network and system support for games,  Melbourne, Australia: ACM, 2007, pp. 117-122.

[38]  P.B. Beskow, K. Vik, P. Halvorsen, and C. Griwodz, “Latency reduction by dynamic core selection and partial migration of game state,” Proceedings of the 7th ACM SIGCOMM Workshop on Network and System Support for Games,  Worcester, Massachusetts: ACM, 2008, pp. 79-84.

[39]  K. Vik, C. Griwodz, and P. Halvorsen, “Applicability of group communication for increased scalability in MMOGs,” Proceedings of 5th ACM SIGCOMM workshop on Network and system support for games,  Singapore: ACM, 2006, p. 2.

*[40]  C. Chambers and W. Feng, “Patch scheduling for on-line games,” Proceedings of 4th ACM SIGCOMM workshop on Network and system support for games,  Hawthorne, NY: ACM, 2005, pp. 1-6.

[41]  T. Jehaes, D.D. Vleeschauwer, T. Coppens, B.V. Doorselaer, E. Deckers, W. Naudts, K. Spruyt, and R. Smets, “Access network delay in networked games,” Proceedings of the 2nd workshop on Network and system support for games,  Redwood City, California: ACM, 2003, pp. 63-71.

[42]  F. Lu, S. Parkin, and G. Morgan, “Load balancing for massively multiplayer online games,” Proceedings of 5th ACM SIGCOMM workshop on Network and system support for games,  Singapore: ACM, 2006, p. 1.

[43]  J. Färber, “Network game traffic modelling,” Proceedings of the 1st workshop on Network and system support for games,  Braunschweig, Germany: ACM, 2002, pp. 53-57.

[44]  M. Suznjevic, M. Matijasevic, and O. Dobrijevic, “Action specific Massive Multiplayer Online Role Playing Games traffic analysis: case study of World of Warcraft,” Proceedings of the 7th ACM SIGCOMM Workshop on Network and System Support for Games,  Worcester, Massachusetts: ACM, 2008, pp. 106-107.

[45]  P. Tarng, K. Chen, and P. Huang, “An analysis of WoW players' game hours,” Proceedings of the 7th ACM SIGCOMM Workshop on Network and System Support for Games,  Worcester, Massachusetts: ACM, 2008, pp. 47-52.

Virtualization Related:

[1]    C. Clark et al., “Live migration of virtual machines,” in Proceedings of the 2nd conference on Symposium on Networked Systems Design \& Implementation - Volume 2, pp. 273-286, 2005.

[2]    R. Bradford, E. Kotsovinos, A. Feldmann, and H. Schiöberg, “Live wide-area migration of virtual machines including local persistent state,” in Proceedings of the 3rd international conference on Virtual execution environments, pp. 169-179, 2007.

[3]    E. Harney, S. Goasguen, J. Martin, M. Murphy, and M. Westall, “The efficacy of live virtual machine migrations over the internet,” in Proceedings of the 2nd international workshop on Virtualization technology in distributed computing, pp. 1-7, 2007.

[4]   A. Kadav and M. M. Swift, “Live migration of direct-access devices,” SIGOPS Oper. Syst. Rev., vol. 43, no. 3, pp. 95-104, 2009.

[5]    A. Stage and T. Setzer, “Network-aware migration control and scheduling of differentiated virtual machine workloads,” in Proceedings of the 2009 ICSE Workshop on Software Engineering Challenges of Cloud Computing, pp. 9-14, 2009.

[6]    H. Liu, H. Jin, X. Liao, L. Hu, and C. Yu, “Live migration of virtual machine based on full system trace and replay,” in Proceedings of the 18th ACM international symposium on High performance distributed computing, pp. 101-110, 2009.

[7]    P. Barham et al., “Xen and the art of virtualization,” in Proceedings of the nineteenth ACM symposium on Operating systems principles, pp. 164-177, 2003.

[8]    D. Nurmi et al., “The Eucalyptus Open-Source Cloud-Computing System,” in Cluster Computing and the Grid, 2009. CCGRID '09. 9th IEEE/ACM International Symposium on, pp. 124-131, 2009.

[9]    A. Greenberg, P. Lahiri, D. A. Maltz, P. Patel, and S. Sengupta, “Towards a next generation data center architecture: scalability and commoditization,” in Proceedings of the ACM workshop on Programmable routers for extensible services of tomorrow, pp. 57-62, 2008.

[10]  T. Benson, A. Anand, A. Akella, and M. Zhang, “Understanding data center traffic characteristics,” SIGCOMM Comput. Commun. Rev., vol. 40, no. 1, pp. 92-99, 2010.

[11]  N. Feamster, J. Borkenhagen, and J. Rexford, “Guidelines for interdomain traffic engineering,” SIGCOMM Comput. Commun. Rev., vol. 33, no. 5, pp. 19-30, 2003.

[12]  P. Costa, T. Zahn, A. Rowstron, G. O'Shea, and S. Schubert, “Why should we integrate services, servers, and networking in a data center?,” in Proceedings of the 1st ACM workshop on Research on enterprise networking, pp. 111-118, 2009.

[13]  A. Greenberg et al., “VL2: a scalable and flexible data center network,” in Proceedings of the ACM SIGCOMM 2009 conference on Data communication, pp. 51-62, 2009.

[14]  A. Greenberg, J. Hamilton, D. A. Maltz, and P. Patel, “The cost of a cloud: research problems in data center networks,” SIGCOMM Comput. Commun. Rev., vol. 39, no. 1, pp. 68-73, 2009.

 



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




-- 
===================================================
Dr Greg Bernstein, Grotto Networking (510) 573-2237
--------------080408050107070102000903-- From ylee@huawei.com Mon Dec 6 14:23:21 2010 Return-Path: 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 ; 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 ; 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 ; 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 In-reply-to: <201012031537.16993.mkuehle@ikr.uni-stuttgart.de> To: =?iso-8859-1?Q?'Mirja_K=FChlewind'?= , 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-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)=20 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.=20 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.=20 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.=20 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=FChlewind 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=20 Optimization is still a lot of space to do thing better but I don't = believe=20 in a generic approach.=20 I would like to response to the points below and also give some feedback = to=20 the charter. First the points below: (a) If you would have the global system view which has all the = information=20 about the application and the network state, I'm sure its possible to=20 optimize the system such that all players will benefit. But we are = talking=20 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=20 give for every player the right incentives to actually make a decision = that=20 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=20 which make decisions based on the same information, you have to be very=20 careful that those decisions will not be counterproductive. E.g. an=20 application changes the coding to lower bitrate and the network reserves more=20 capacity at the same time. It's basically impossible to show the = stability of=20 such a complex system. It's already hard to make any stability investigations=20 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.=20 YOUNG>> However, what you are saying here regarding the stability = concern between application and network is a valid point in the reservation = system.=20 (b) I still don't get your point here. As you say 'best effort' means = that you=20 always try to get the maximum but you never know what the maximum = is/what you=20 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=20 information. YOUNG>> I think Greg answered well on this point already.=20 (c) You say: '... definition of a "data center" as something like "a location=20 within the network where application resources maybe aggregated". What?=20 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=20 completely separated network were one entity has the control over all = the=20 physical devices within this network. That makes it easier to solve = certain=20 problems in a data center than in the Internet. But I don't see how it = help=20 to define the problem of CSO any better. (d) Can you provide the pointers to all this material? But for me this=20 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=20 original idea was to do something about cross-layer optimization. But as = we=20 couldn't define the problem clearly, we thought it might make more sense = to=20 look at specific problems (one certain application in one network = scenario)=20 and find a solution for those problems in such a that it is generic = enough to=20 be used by other applications as well. (I have to say I'm working on=20 transport protocols, so we were mainly focusing on solutions in the transport=20 layer with application layer information/for one specific application = type). YOUNG>> Greg did a great job for this.=20 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=20 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=20 useless for the application. You could maybe use these information aggregated=20 over a certain time. This could give you an impression about the link = state=20 but still doesn't give you any guaranteed information for the future as = the=20 link state changes permanently. It's a really complicated task to define an interface in such a that not only=20 the right information can be exchanged but they are also represented in = the=20 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.=20 - 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=20 you don't need a protocol but an inferface. I don't believe that you can find=20 a generic interface here that will address all problems (and will be=20 implemented by all kind of applications). I would assume that you have = to=20 change/extend the interface for every problem separately. If you want a protocol to expose certain information within the same = layer,=20 this is completely different problem. This also goes in the direction of = measuring and monitoring network state. There are tons of proposal for=20 measuring all different kind of thing. And again I would say the = solution=20 differ a lot depending on what information you are aiming for.=20 - One more general comment: Whenever you talk about CSO I have the = feeling=20 that you basically want to provide more information for the application. = Why not providing more information for the lower layers about the traffic=20 characteristics, requirements and maybe even user preferences of the=20 application? Should the information actually go in both directions or = will=20 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.=20 Just my thoughts. I would like to start this discussion on the list, as = I=20 think this is an intresting topic but your proposal it not concrete = enough=20 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