Re: [alto] I-D Action: draft-ietf-alto-deployments-06.txt

["Scharf, Michael (Michael)" <[e-mail]>]

Hi Martin,

I have just read this document. I think that this document requires substantial work. Please find below some initial thoughts. I can elaborate more if needed.


High-level comment:
-------------------

This document discusses about ALTO deployments for peer-to-peer traffic optimization and the CDN use case, but it uses assumptions and terminology specific to peer-to-peer networks in many places (e. g., term "peer" instead of "resouce consumer"), in particular in the general considerations in section 2 and 3. This reflects the view of the ALTO charter.

Yet, ALTO is in fact a generic topology exposure solution. In my opinion, from a deployment perspective P2P and CDN are very different (more below). And, for what it is worth, it is also unclear to me whether deployments of ALTO for P2P optimization are indeed planned by industry. I therefore suggest to rewrite sections 2 and 3 so that they are independent of any specific use case. I am perfectly fine with documenting P2P optimization considerations in Section 4, CDN in Section 5, etc. Note that more use cases for deployment may exist, even if they are ignored by the ALTO charter.


Section 2.1
-----------

  "Figure 2 shows the operational model for applications that do not use
   a tracker, such as, edonky, or in if the tracker should be the
   querying party.  This use case also holds true for CDNs."

First, Figure 2 shows the baseline scenario for ALTO topology exposure. This is independent of what application uses ALTO. I see no need to mention terms like "tracker", "edonky" here.

Second, it is entirely unclear to me why the CDN use case should have similarity to a trackerless P2P network. For instance, a CDN may have an own management system that interfaces with a single ALTO client to an ALTO server. This is probably much closer to a model where the ALTO client is in the resource directory.

   "However, Figure 3 does not denote where the ALTO elements are
   actually located, i.e., if the tracker and the ALTO server are in the
   same ISP's domain, or if the tracker and the ALTO server are managed/
   owned/located in different domains.  The latter is the typical use
   case, e.g., taking Pirate Bay as example that serves Bittorrent peers
   world-wide."

While the following sections enumerate some examples for different possibilities of placements, I think that the document has to start of with some general considerations how ALTO can be deployed, and what the implications are. Some random thoughts on high-level decisions for deployment:

  - Whether ALTO client and ALTO server are operated within the same organization/network or not. This changes a lot of constraints. The document here imho has to expand on the trust model, the level-of-detail of maps that can be exposed, etc. depending on who the involved parties actually are.

  - Whether the ALTO server offers guidance to any Internet applications or only a set of well-known ALTO clients (e. g., after authentication). In the P2P example, this would imply that only selected trackers are allowed to access the ALTO server. (This may also have some implications on third-party ALTO server discovery.)

  - Whether the ALTO server has to provide guidance for all potential Internet destinations, or only for a set of known and possibly controlled resource providers. For instance, I am not sure if for CDN optimization an ALTO server would have to care about the routing cost between residential users.

It is probably not realistic that all possible deployment issues can be discussed in a generic way, but I really think that this section should focus on the high-level design choices and issues that have to be considered when an operator thinks about deploying ALTO. Specific P2P issues should be moved to Section 4.


Section 2.4
-----------

This is an important issue when deploying ALTO. But, again, the challenge will be that the map could significantly differ depending on the use case, the network architecture, and the trust relationship between ALTO server and ALTO client, etc. It may make sense to discuss this separately per use case.


Section 3.1
-----------

   "For some large ISPs, their whole network is layered.  The upper layer
   network includes one or several backbone networks, and the lower
   layer network includes multiple access networks.  These access
   networks are connected to backbone networks, and the exchange traffic
   with others through backbone network.  In this kind of layered
   network, the bandwidth of backbone network is important and may be
   scarce.  Traffic should be limited to the access networks, so to
   decrease the usage of backbone as far as possible."

I am confused by the term "layer" in this text. I am more used to the term "layer" when refering to "physical layer", "IP layer" etc.

Also note that residential Internet access may in fact run over a protocol-layered ISP network, i. e., residential Internet access is realized as a VPN over an MPLS/IP core. The implications of deploying ALTO in that architecture are not addressed in this document at all.


Section 7.1
-----------

While dynamic address assignment to DSLAMs is indeed a challenge, this is by far not the only reason why an ALTO map could change.


Section 7.3
-----------

The design tradeoff between H1 and H2 may be different if ALTO server and client have a controlled relationship. I.e., this is not a general challenge, but a specific challenge for one ALTO use case.


Section 8.2.1
-------------

The text on topological distance is rather incomplete; it seems very BGP-centric. I also think that there has been recently some useful discussion on the mailing list on what could be put into an ALTO map.

There are various further distance-related parameters. For instance, the ALTO server could access delay measurements (and prototye implementations for that exist). 

The draft could also comment on differences between, say, topological distance and geographical distance, even within one ISP network.


Section 10.2
------------

There are relevant use cases where the access to the ALTO server has to be much more strictly controlled, i. e., where an authentication of the ALTO client to the server may be needed. Whether to expose ALTO information publicly, or not, seems a relevant deployment question for an operator of an ALTO server.

Given that draft-ietf-alto-protocol refers to this document for ALTO server access control, I think that this really needs more text here. Also, this may affect deployability of ALTO server discovery solutions.


References
----------

draft-jenkins-alto-cdn-use-cases seems relevant.


Thanks

Michael



 

> -----Original Message-----
> From: [e-mail] [mailto:[e-mail]] On 
> Behalf Of Martin Stiemerling
> Sent: Monday, February 25, 2013 10:29 AM
> To: [e-mail]
> Subject: Re: [alto] I-D Action: draft-ietf-alto-deployments-06.txt
> 
> Hi all,
> 
> This update is just a maintenance update of the draft, as it 
> did expire in the past.
> 
> However, the authors need some reviews to gather feedback 
> about the draft, especially also in the light of the ALTO 
> protocol draft using the deployment considerations as 
> reference to some operational aspects.
> 
>    Martin
> 
> On 02/25/2013 10:26 AM, [e-mail] wrote:
> >
> > A New Internet-Draft is available from the on-line 
> Internet-Drafts directories.
> >   This draft is a work item of the Application-Layer 
> Traffic Optimization Working Group of the IETF.
> >
> > 	Title           : ALTO Deployment Considerations
> > 	Author(s)       : Martin Stiemerling
> >                            Sebastian Kiesel
> >                            Stefano Previdi
> > 	Filename        : draft-ietf-alto-deployments-06.txt
> > 	Pages           : 46
> > 	Date            : 2013-02-25
> >
> > Abstract:
> >     Many Internet applications are used to access resources, such as
> >     pieces of information or server processes, which are 
> available in
> >     several equivalent replicas on different hosts.  This 
> includes, but
> >     is not limited to, peer-to-peer file sharing 
> applications.  The goal
> >     of Application-Layer Traffic Optimization (ALTO) is to provide
> >     guidance to these applications, which have to select 
> one or several
> >     hosts from a set of candidates, that are able to 
> provide a desired
> >     resource.  The protocol is under specification in the 
> ALTO working
> >     group.  This memo discusses deployment related issues 
> of ALTO for
> >     peer-to-peer and CDNs, some preliminary security 
> considerations, and
> >     also initial guidance for application designers using ALTO.
> >
> >
> > The IETF datatracker status page for this draft is:
> > https://datatracker.ietf.org/doc/draft-ietf-alto-deployments
> >
> > There's also a htmlized version available at:
> > http://tools.ietf.org/html/draft-ietf-alto-deployments-06
> >
> > A diff from the previous version is available at:
> > http://www.ietf.org/rfcdiff?url2=draft-ietf-alto-deployments-06
> >
> >
> > Internet-Drafts are also available by anonymous FTP at:
> > ftp://ftp.ietf.org/internet-drafts/
> >
> > _______________________________________________
> > alto mailing list
> > [e-mail]
> > https://www.ietf.org/mailman/listinfo/alto
> >
> 
> --
> [e-mail]
> 
> NEC Laboratories Europe
> NEC Europe Limited
> Registered Office:
> Athene, Odyssey Business Park, West End  Road, London, HA4 
> 6QE, GB Registered in England 2832014 
> _______________________________________________
> alto mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/alto
>