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

[Jan Seedorf <[e-mail]>]

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]