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

Enrico and Dave,

Good discussions. Here is my $.01 input on data centers/controlled 
environments.
Two examples came to mind:

- A datacenter may consist of multiple frameworks to schedule 
applications. A
popular example is the Map-Reduce (Hadoop) framework. Preliminary network
aware capabilities exist; for example, see Rack Awareness
(http://hadoop.apache.org/common/docs/current/hdfs_user_guide.html#Rack+Awareness).
The document 
(https://issues.apache.org/jira/secure/attachment/12345251/Rack_aware_HDFS_proposal.pdf) 

discusses distances among nodes in simple settings as well.

- In 
(http://static.usenix.org/events/hotice11/tech/full_papers/Wang_Ye.pdf),
motivated by the need of MS Lync, the framework aggregates information 
beyond
network-centric but also app level information to provide an enterprise 
information
portal.

For both settings, I feel that more abstract and more aggregated 
presentation of
information, say using ALTO, can be valuable/preferred.

Richard

On 2/27/12 4:05 AM, Enrico Marocco wrote:
> Thanks Dave,
>
> this is indeed the kind of feedback the draft was intended to trigger.
>
> Proposals that have been presented in the past few years for extending
> the ALTO protocol on different axis, to make it suitable for carrying
> different types of information and for doing that on a more dynamic
> timescale, seem to indicate that there is some sort of gap in the
> provisioning of network information to applications that tools currently
> available have failed to fill. If that is the case, the discussion we
> want to have needs to deepen in the whys and hows those tools do not
> satisfy requirements of such applications -- I'm certainly not the most
> expert in the area and will leave the question to the proponents of the
> extensions, but I guess the answer may be related to the intrinsic
> complexity of dealing with low-level information at an application level
> -- and why a more abstract presentation of such information (through
> ALTO or via other means) may have better chance.
>
> You make a good point that for CDN and datacenter applications running
> in controlled environment SNMP monitoring and BGP sniffing can provide
> all the information such applications may possibly need. If the
> incentive they provide is enough to motivate their implementation is a
> key topic of discussion we want to have to identify the way forward for
> ALTO.
>
> Enrico
>
> On 2/23/12 5:09 PM, David Harrington wrote:
>> 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.
>>
>> 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.
>>
>> 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). 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 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 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 think you might have a hard time convincing the IESG to approve ALTO
>> extensions for data centers and CDNs that could already be handled by
>> other protocols in a managed environment.
>>
>> My $.02
>> --
>> David Harrington
>>
>
>
>
> _______________________________________________
> alto mailing list
> alto@ietf.org
> https://www.ietf.org/mailman/listinfo/alto