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

[Songhaibin <[e-mail]>]

Hi Jan,

> 
> > 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"?

Interesting. For the cross layer communication, it is supposed to use infrastructure information to provide guidance for applications. So for each scenario, it is interesting to know (1) what kind of infrastructure information is provided (2) how does it benefit applications/infrastructure (3) if it is necessary to provide that information to an ALTO sever, or other mean is preferred.  I guess the above issue is something about content management in a CDN network. 

Thanks,
-Haibin

> 
> 
> > -----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
> _______________________________________________
> alto mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/alto