Re: [altoext] draft-marocco-alto-next-00 -- High bandwidth cases

[Jan Seedorf <[e-mail]>]

Hi Greg,

Thanks for explaining your background. I guess my view / use-cases I am interesting in currently are (a) and (b), and potentially (d). But now I am aware of (c) and that people are interested in that as well. From an ALTO perspective, such allocation requests would be quite a new thing, but I have not thought about it too much yet and I am not per se against it. Let's see what others think what i2aex should be about and how the BoF will go anyway :)

See you in Paris, where we can maybe also discuss more on (c).

 - Jan

> -----Original Message-----
> From: [e-mail] [mailto:[e-mail]] On
> Behalf Of Greg Bernstein
> Sent: Thursday, March 08, 2012 8:09 PM
> To: Jan Seedorf
> Cc: [e-mail]
> Subject: Re: [altoext] draft-marocco-alto-next-00 -- High bandwidth cases
> 
> Hi Jan, I think we are starting to several general directions in "alto
> extensions":
> (a) More types of info from the network: available bandwidth, other
> types of costs
> (b) Updates or alerts from the network, e.g., publish-subscribe scenario
> (examples include updates to costs or availability)
> (c) application/cloud to network requests (our example is bandwidth
> allocation, e.g. tunnel establishment...)
> (d) application to application interactions related to network
> usage/availability (some of the CDN stuff?).
> 
> I would say (b)-(d) may be what the BOF will discuss the most, and
> hopefully why our area director changed the name of the BOF from
> "altoext" to "Infrastructure-to-application information exposure
> (i2aex)".  Hopefully this will include discussions of (c) and (d) in the
> BOF.  As myself and co-author are long time optical pipe (GMPLS) folks,
> we are eager to see more effective use made of our plumbing control ;-) .
> We will be posting our updated high bandwidth draft by Monday.
> 
> Cheers
> Greg B.
> 
> On 3/8/2012 8:44 AM, Jan Seedorf wrote:
> > Greg,
> >
> >> 2.    A Network Resource Reservation Interface - Where the "application"
> can
> >> make explicit requests for bandwidth between client regions and data
> >> centers.  This is  something kind of new conceptually for ALTO, but not
> from a
> >> protocol perspective, i.e. would use PID concepts and a RESTful service
> >> interface.
> > Is this not quite beyond ALTO in the sense that ALTO (so far, even with the
> proposed extensions) is supposed to be passive, i.e. the ALTO client gets
> information from an ALTO server (even if the server can notify the client that
> there is new information, this is the case). I wonder if we are targeting the
> kind of active requests you are describing, where the ALTO client can
> "request" something from the server other than information.
> >
> >   - Jan
> >
> >> -----Original Message-----
> >> From: [e-mail] [mailto:[e-mail]] On
> >> Behalf Of Greg Bernstein
> >> Sent: Thursday, March 01, 2012 5:32 PM
> >> To: [e-mail]
> >> Subject: Re: [altoext] draft-marocco-alto-next-00 -- High bandwidth cases
> >>
> >> Hi folks, very good conversation. We'll be updating our draft " Use Cases
> for
> >> High Bandwidth Query and Control of Core Networks"
> >>
> >> which has expired (http://datatracker.ietf.org/doc/draft-bernstein-alto-
> >> large-bandwidth-cases/). I think the notion of "controlled" or "managed"
> >> environment that is being kicked around is particularly appropriate for the
> >> high bandwidth scenarios (GMPLS, optical, etc...) that we have discussed.
> >> In our document we reviewed current protocols used to control "large
> >> bandwidth" (e.g., GMPLS, PCE) and why they are not appropriate for
> >> application use, though they are an enabler for this functionality.  In our
> >> update we'll elucidate on the "extensions" that we think are needed for
> this
> >> particular application but a short summary is:
> >> 1.    A Network Query Interface - Where the "application" can inquire as to
> >> the bandwidth availability between "client regions" and data centers.
> Note
> >> that this "bandwidth" may not be visible at the IP layer but available from
> >> SDH, OTN or WDM layers via GMPLS/PCE. This is similar to "Bandwidth
> >> Availability" in Enrico and Vijay's alto-next draft
> >> <http://tools.ietf.org/html/draft-marocco-alto-next-00>  , but a more
> >> elaborate.
> >> 2.    A Network Resource Reservation Interface - Where the "application"
> can
> >> make explicit requests for bandwidth between client regions and data
> >> centers.  This is  something kind of new conceptually for ALTO, but not
> from a
> >> protocol perspective, i.e. would use PID concepts and a RESTful service
> >> interface.
> >> 3.    A Fault Recovery Interface - For the"application" to make requests for
> >> expedited bulk rerouting of client traffic from one data center to another,
> or
> >> for the network to ask for assistance from the "application" to deal with
> >> network faults.  The later case seems similar to Enriro and Vijay's "server
> >> initiated notification"
> >>
> >> Best Regards
> >> Greg B.
> >>
> >>
> >> On 3/1/2012 2:21 AM, Martin Stiemerling wrote:
> >>
> >> 	Hi Dave,
> >>
> >>
> >> 		From: [e-mail] [mailto:altoext-
> >> [e-mail]] On Behalf
> >> 		Of David Harrington
> >> 		Sent: Thursday, February 23, 2012 5:10 PM
> >> 		To: [e-mail]; [e-mail]
> >> 		Subject: [altoext] draft-marocco-alto-next-00
> >>
> >> 		Hi,
> >>
> >> 		AD-hat-off ...
> >>
> >> 		I am not very convinced this is a set of problems that need
> >> ALTO solutions.
> >>
> >> 		When dealing with P2P scenarios, ALTO is important because
> >> endpoints for a
> >> 		large amount of P2P are "unmanaged" - they are typically
> >> home users sharing
> >> 		files with other home users. Home users typically do not
> >> use/monitor
> >> 		protocols such as BGP, ISIS, SNMP, Conex, ECN. Frequently
> >> consumer equipment
> >> 		doesn't make these protocols available/accessible to end-
> >> users.
> >>
> >>
> >> 	One additional thing to that:
> >> 	Home users or application developers also potentially do not
> >> understand the information provided by BGP, ISIS, SNMP, etc.
> >>
> >>
> >>
> >> 		The information about the network, like server load, link
> >> status, bandwidth
> >> 		availability, is not something the network providers
> >> necessarily want to
> >> 		share. Network operators should be concerned about
> >> sharing with anonymous
> >> 		users, who might well be interested in maliciously attacking
> >> the network
> >> 		environment.
> >>
> >>
> >> 	This is understood in the ALTO WG and documented in Section 12 of
> >> draft-ietf-alto-protocol-10. ALTO was seen as a good way of providing
> >> information to applications, but still not telling everything about the
> network
> >> infrastructure.
> >>
> >>
> >>
> >> 		Data centers and CDNs typically are "managed"
> >> environments, and the
> >> 		file-sharing/load-balancing/congestion control protocols are
> >> for use within
> >> 		the administrative domain by the operators of the data
> >> centers or CDNs (or
> >> 		between "peered" environments, where there is a certain
> >> level of trust).
> >>
> >>
> >> 	I disagree that CDNs are mainly operating in managed environments.
> >> The CDN system with its components, e.g., DNS server, caches, etc, is
> indeed
> >> operating in a managed environment. However, all communication
> between
> >> the CDN caches and the hosts using the services provided by the CDN are
> not
> >> in a managed environment, i.e., they are operating over the Internet.
> >>
> >> 	Peered environments give a certain level of business relationship,
> >> but I'm not sure that there is a lot of trust between the traditional CDN
> >> operators and the local network operators.
> >>
> >>
> >> 		These environments typically have access to protocols such
> >> as SNMP and BGP,
> >> 		and how the network is "tweaked" to accommodate dynamic
> >> traffics patterns is
> >> 		the business of the network provider, using specialty
> >> applications to adapt
> >> 		the network at the lower layers. Operators and their OAM
> >> protocols monitor
> >>
> >>
> >> 	CDNs do have access to BGP, but a global CDN does definitely not
> >> have access to the local networks' SNMP data. Even for operator hosted
> >> CDNs, it may not the case that the CDN operator is allowed to access
> SNMP
> >> on the network elements, as this can two completely different
> departments
> >> (i.e., for regulatory reasons or business reasons).
> >>
> >> 	I know operators who want to have a better "linkage" between them
> >> and the CDNs around them, e.g., potentially going beyond what BGP is
> >> offering (to be explored). One of doing this could be based on ALTO.
> >>
> >>
> >> 		traffic load and can set policies to balance the load/adjust the
> >> forwarding
> >> 		rules as needed to compensate for congestion, and so on.
> >> Applications
> >> 		running on end-hosts do not have enough knowledge of the
> >> complete network
> >> 		traffic, and are in a bad position to make policy decisions
> >> about load
> >> 		balancing across servers based on bandwidth availability or
> >> server load or
> >> 		memory usage.
> >>
> >> 		I understand that there is a need for communications
> >> between layer 7
> >> 		applications and the underlying layer 4,3,and 2
> >> functionality.There are
> >> 		already protocols available that allow applications to inform
> >> the lower
> >> 		layers of the network what type of traffic they plan to
> >> introduce to the
> >> 		network, and the qualities of the service they prefer for their
> >> traffic.
> >> 		Applications can already make use of some of the existing
> >> standards for this
> >> 		purpose. Users probably do not have authorization to affect
> >> the policy; they
> >> 		can request QoS within the policies configured by the
> >> network operators.  I
> >> 		do not see why, with few exceptions, the layer 7 application
> >> is better
> >> 		positioned to be the policy decision point, especially for real-
> >> time
> >> 		adjustments, than the OAM functionality already built into
> >> those lower
> >> 		layers, and the network provider policy configurations. I also
> >> think that
> >> 		real-time adjustments by ALTO don't seem called for, so a
> >> push model for
> >> 		fast dynamic updates really isn't needed. If needed, existing
> >> push protocols
> >> 		such as SNMP notifications, driven by an ALTO-SERVER-MIB,
> >> could serve this
> >> 		purpose just fine.
> >>
> >>
> >> 	I'm, not sure if SNMP is the right tool here, as ALTO is not so much
> >> OAM, but more how to provide apps with better guidance about the
> >> network state. I know network state is a bit blurry, but bear with me at
> this
> >> stage :)
> >>
> >> 	However, I'm open for any suggestion.
> >>
> >>
> >>
> >> 		I have a concern about server-to-server sharing of
> >> information. I think the
> >> 		network provider can decide which servers to share
> >> information with. If
> >> 		server-to-server sharing eliminates the network provider
> >> from the decision
> >> 		of whom to share data with, I consider that a problem. You,
> >> of course, do
> >> 		not discuss how sharing would be done in this document, so
> >> maybe that issue
> >> 		could be addressed.
> >>
> >>
> >>
> >>
> >>
> >>
> >> 		Some of these ideas, such as server-to-server
> >> communications, might be
> >> 		covered by a re-charter for the WG. However, developing a
> >> brand-new protocol
> >> 		just for this purpose seems dubious when there are so many
> >> existing
> >> 		protocols that can carry data between applications (which is
> >> what an alto
> >> 		server is). I would expect that a better approach might be to
> >> have a server
> >> 		and client co-resident, and using a (server-as-client)-to-
> >> server
> >> 		communications.
> >>
> >>
> >> 	I also seem some of them more on re-chartering but many of them
> >> are (e.g., the time scale on which the information provided is being
> updated)
> >> going beyond the current scope of ALTO.m
> >>
> >> 	  Martin
> >>
> >> 	[e-mail]
> >>
> >> 	NEC Laboratories Europe - Network Research Division NEC Europe
> >> Limited | Registered Office: NEC House, 1 Victoria Road, London W3 6BL |
> >> Registered in England 2832014
> >>
> >> 	_______________________________________________
> >> 	altoext mailing list
> >> 	[e-mail]
> >> 	https://www.ietf.org/mailman/listinfo/altoext
> >>
> >>
> >>
> >>
> >>
> >> --
> >> ===================================================
> >> Dr Greg Bernstein, Grotto Networking [phone]
> >
> 
> 
> --
> ===================================================
> Dr Greg Bernstein, Grotto Networking [phone]
> 
> 
> _______________________________________________
> altoext mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/altoext