Re: [alto] draft-marocco-alto-next-00

[Songhaibin <[e-mail]>]

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: [e-mail] [mailto:[e-mail]] On Behalf Of
> Martin Stiemerling
> Sent: Thursday, March 01, 2012 6:22 PM
> To: David Harrington; [e-mail]; [e-mail]
> Subject: Re: [altoext] draft-marocco-alto-next-00
> 
> Hi Dave,
> 
> >From: [e-mail] [mailto:[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