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

["Kathy McEwen" <[e-mail]>]

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

 

-----Original Message-----
From: [e-mail] [mailto:[e-mail]] On Behalf Of Mirja
Kühlewind
Sent: Friday, December 03, 2010 8:37 AM
To: [e-mail]
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::  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.

 

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::  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’s interoperate with each other, acting as their own
overlay “islands” in the networks, clearly benefiting them as one single
player.  Today’s 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, …multiple network providers,
media providers and CDN providers, as well  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::  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 “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.  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).  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…

 

(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

 

 

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::  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.  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 “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 = 5.26 minutes per year).  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::   Networks, even IP/MPLS are not just “best effort” 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’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?
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 “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.  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.      

 

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

 

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

 

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

 

Mirja

 

 

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

> Hi folks interested in cross stratum optimization (CSO) a few thoughts 

> on some of the interesting points raised at the Bar BOF and to 

> possibly stimulate further discussion:

> 

> (a) Who benefits from CSO? The application provider or the carrier? It 

> seems to be viable CSO should benefit both. The network operator 

> (carrier, ISP, IT department, etc...) should benefit from more 

> effective utilization of network resources (links, switches, routers, 

> etc...) and gain more flexibility in dealing with fault conditions. 

> The application provider benefits from being able to offer either 

> higher quality services or better assurances on service quality. 

> Essentially the network operator gets to influence the placement of 

> load on the network while the application provider gets information 

> that allows them to optimize their resources along with their customers
experience.

> 

> (b) Isn't the Internet "best effort"? How can you talk of providing a 

> better "network experience" to applications?

> First CSO isn't strictly aimed at the "Internet" in general, but would 

> start with various network domains (LAN, OSPF area, AS, etc...). Also 

> "best effort" is a somewhat misleading term since it doesn't take into 

> account overall statistical quality measures that are very important 

> to user experiences. For example 2000 sessions sharing a link on a 

> first come first serve basis are considered "best effort" whether the 

> link is a T1 or an OC-192 but will generally experience greatly 

> different "average" QoS ;-) . Depending on the network context and 

> technology various service level guarantees may be explicit or implicit.

> 

> (c) What's a "data center" and do we include "hosts"? Folks interested 

> in CSO come from a number application and network areas.  The essence 

> is that guidance from the network provider to the application provider 

> concerning network state and capability provides benefits to both. In 

> one of the drafts we tried a definition of a "data center" as 

> something like "a location within the network where application 

> resources maybe aggregated".

> I'd say a "host" (or my laptop) would qualify. Other ideas?

> 

> (d) Examples? During some of the background work for the CSO drafts we 

> looked at a number of examples that we published in the original draft.

> We've also looked at "pre-CSO" type mechanisms that are being used to 

> try and optimize applications. These include "old school" and "new 

> school" CDN approaches,  load balancing within and between data 

> centers (local versus global),  various papers dealing with local and 

> wide area VM migration, and High Performance Computing applications 

> (radio astronomy being an interest of mine). Would it be useful to 

> organize these in some way? We had some of these in the original CLO 

> draft but the overall length was getting to long.  For our WSON work 

> we set up web pages to keep track not just editors copies of our 

> drafts (for all to work with) but supplemental material (some of which 

> was later published in IEEE/OSA journals).

> 

> Just some thoughts from a jet lagged Californian ;-)

> 

> Greg B.

 

 

_______________________________________________

cso mailing list

 <mailto:[e-mail]> [e-mail]

 <https://www.ietf.org/mailman/listinfo/cso>
https://www.ietf.org/mailman/listinfo/cso