Hi Martin and Dave, I like the discussion. And beyond that, I agree with most of the items in the draft except section 3.2.3 about content availability on hosts. If ALTO provides the information about what contents/apps are available on which endpoints/servers, that will make the ALTO server look like a huge resource directory, which is hard to manage and should be provided by the application themselves.
BR, -Haibin > -----Original Message----- > From: [email protected] [mailto:[email protected]] On Behalf Of > Martin Stiemerling > Sent: Thursday, March 01, 2012 6:22 PM > To: David Harrington; [email protected]; [email protected] > Subject: Re: [altoext] draft-marocco-alto-next-00 > > Hi Dave, > > >From: [email protected] [mailto:[email protected]] On Behalf > >Of David Harrington > >Sent: Thursday, February 23, 2012 5:10 PM > >To: [email protected]; [email protected] > >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 > > [email protected] > > 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 > [email protected] > https://www.ietf.org/mailman/listinfo/altoext _______________________________________________ alto mailing list [email protected] https://www.ietf.org/mailman/listinfo/alto
