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

[Jan Seedorf <[e-mail]>]

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: [e-mail] [mailto:[e-mail]] On
> Behalf Of Songhaibin
> Sent: Friday, March 02, 2012 8:54 AM
> To: Martin Stiemerling; David Harrington; [e-mail]; [e-mail]
> 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: [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
> _______________________________________________
> altoext mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/altoext