Hi Haibin, > 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. True, if ALTOext would provide details about all content-IDs etc. But what if ALTOext would only provide information about which TYPES/CLASS of content is stored at a given endpoint/server, e.g. "videos larger than 1MB for content provider xyz.com" or "videos encoded as x from content provider z"?
- Jan > -----Original Message----- > From: [email protected] [mailto:[email protected]] On > Behalf Of Songhaibin > Sent: Friday, March 02, 2012 8:54 AM > To: Martin Stiemerling; David Harrington; [email protected]; [email protected] > Subject: Re: [altoext] draft-marocco-alto-next-00 > > 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 > _______________________________________________ > altoext mailing list > [email protected] > https://www.ietf.org/mailman/listinfo/altoext _______________________________________________ alto mailing list [email protected] https://www.ietf.org/mailman/listinfo/alto
