[alto] draft-ietf-alto-deployments-13

[SCHARF, Michael (Michael)]

Hi all,

Based on a suggestion of the chairs I have looked into how to include parts of 
draft-seidel-alto-map-calculation in draft-ietf-alto-deployments.

In general, draft-seidel-alto-map-calculation contains a useful and 
comprehensive deployment example as well as some lessons learnt. As far as I 
can tell, the example described in draft-seidel-alto-map-calculation seems 
realistic, and the resulting recommendations for ALTO deployments could be 
backed by other solutions to calculate ALTO maps. Thus, I think it would be 
useful to add significant parts of draft-seidel-alto-map-calculation to 
draft-ietf-alto-deployments, even if that document has already passed WGLC.

The new version  draft-ietf-alto-deployments-13 has three main changes:

* There is a new Section 3.6. "Comprehensive Example for Map Calculation" taken 
from draft-seidel-alto-map-calculation with only minor editorial modifications

* Section 3.2 has been updated in various paragraphs with additional material 
from draft-seidel-alto-map-calculation, as far as applicable

* Hans Seidel has been added as co-author

Please have a look at the new version -13 and let us know any feedback on the 
changes.

I would like to ask the chairs to run a new WGLC in order to finally move this 
document forward.

Thanks

Michael



-Original Message-
From: I-D-Announce [mailto:i-d-announce-boun...@ietf.org] On Behalf Of EXT 
internet-dra...@ietf.org
Sent: Wednesday, January 20, 2016 9:00 AM
To: i-d-annou...@ietf.org
Cc: alto@ietf.org
Subject: I-D Action: draft-ietf-alto-deployments-13.txt


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
Authors : Martin Stiemerling
  Sebastian Kiesel
  Michael Scharf
  Hans Seidel
  Stefano Previdi
Filename: draft-ietf-alto-deployments-13.txt
Pages   : 75
Date: 2016-01-19

Abstract:
   Many Internet applications are used to access resources such as
   pieces of information or server processes that 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 applications that have to select one or several hosts
   from a set of candidates, which are able to provide a desired
   resource.  This memo discusses deployment related issues of ALTO.  It
   addresses different use cases of ALTO such as peer-to-peer file
   sharing and CDNs and presents corresponding examples.  The document
   also includes recommendations for network administrators and
   application designers planning to deploy ALTO, such recommendations
   how to generate ALTO map information.


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:
https://tools.ietf.org/html/draft-ietf-alto-deployments-13

A diff from the previous version is available at:
https://www.ietf.org/rfcdiff?url2=draft-ietf-alto-deployments-13


Please note that it may take a couple of minutes from the time of submission
until the htmlized version and diff are available at tools.ietf.org.

Internet-Drafts are also available by anonymous FTP at:
ftp://ftp.ietf.org/internet-drafts/

___
I-D-Announce mailing list
i-d-annou...@ietf.org
https://www.ietf.org/mailman/listinfo/i-d-announce
Internet-Draft directories: http://www.ietf.org/shadow.html
or ftp://ftp.ietf.org/ietf/1shadow-sites.txt

___
alto mailing list
alto@ietf.org
https://www.ietf.org/mailman/listinfo/alto

Re: [alto] ALTO deployment considerations and map calculation draft

[Scharf, Michael (Michael)]

Well, draft-ietf-alto-deployments is not *my* draft - I just volunteered a long 
time ago to help the WG completing it.

I could see value in including draft-seidel-alto-map-calculation, even if we 
are post WGLC. Personally, I'd also be open to add another author/editor.

But I am interested in completing draft-ietf-alto-deployments soon, i.e., not 
further delaying it by several IETF meetings.

Michael


> -Original Message-
> From: Vijay K. Gurbani [mailto:v...@bell-labs.com]
> Sent: Wednesday, October 28, 2015 4:42 PM
> To: Scharf, Michael (Michael); Hans Seidel
> Cc: IETF ALTO
> Subject: ALTO deployment considerations and map calculation draft
> 
> Michael, Hans: Pursuant to our virtual meeting yesterday, I have been
> thinking whether Hans' draft [1] has any input that can go into
> Michael's deployment draft [2]?
> 
> Can I kindly request the authors to inform the working group if there
> is any beneficial overlap from [1] that we may take into [2]?  I
> realize that [2] has been through WGLC so I am not expecting
> large-scale changes in it.  But if there is any deployment-related
> experience from [1] that can be put into [2], we should do our due
> diligence and make sure that we reflect that experience.
> 
> Thanks!
> 
> [1] http://datatracker.ietf.org/doc/draft-seidel-alto-map-calculation/
> [2] http://datatracker.ietf.org/doc/draft-ietf-alto-deployments/
> 
> - vijay
> --
> Vijay K. Gurbani, Bell Laboratories, Alcatel-Lucent
> 1960 Lucent Lane, Rm. 9C-533, Naperville, Illinois 60563 (USA)
> Email: vkg@{bell-labs.com,acm.org} / vijay.gurb...@alcatel-lucent.com
> Web: http://ect.bell-labs.com/who/vkg/  | Calendar: http://goo.gl/x3Ogq
___
alto mailing list
alto@ietf.org
https://www.ietf.org/mailman/listinfo/alto

Re: [alto] Review of draft-ietf-alto-deployments-11

[Scharf, Michael (Michael)]

Hi Wendy,

Many thanks for this very comprehensive and very useful review.

Sebastian and me have worked on a new version that should address all raised 
issues. Below is a list what has been changed (see the lines marked with "=>"). 
The list only mentions those points that were not straightforward to change; 
the other modifications have just been applied as suggested.

I've just posted the new version -12: 
https://www.ietf.org/internet-drafts/draft-ietf-alto-deployments-12.txt or 
https://tools.ietf.org/html/draft-ietf-alto-deployments-12

The complete diff can be found at: 
https://www.ietf.org/rfcdiff?url2=draft-ietf-alto-deployments-12

Please let us know if there should be any further thoughts or comments.

Best regards

Michael


***Review response ***

-
Major issues:
-

-
{2.2.2}:
I found this section to be hard to understand, and in particular I think the 
term "preferences" is EXTREMELY confusing. That sounds like a client can keep 
preference lists on the ALTO server. I don't think the ALTO RFC uses 
"preferences" at all.

First, I suggest changing "preferences" to "costs" or "information" or "data" 
(I assume that's what the authors mean by "preferences").

Second, the wording of items #1 & #2 is very confusing.  I think the point of 
this section is that a client can either get the cost data for all endpoints at 
once and lookup specific costs whenever it wants (#1), or else a client can 
request data for specific endpoints when it needs them (#2). #1 means the 
server reveals a lot to the client, and the client reveals nothing to the 
server; #2 means the client reveals a lot to the server, and the server reveals 
limited data to the client.

At least I think that's the point. I suggest rewriting this section -- the 
numbered paragraphs in particular -- to make it clearer.

=> Section 2.2.2 has been entirely rewritten. See -12 for the new wording.


-
{4.2.2}:
I am surprised you did not consider a combination approach, where the tracker 
and the peers BOTH use ALTO. In this case, the tracker would use a 
coarse-grained "global" ALTO server, while the peers would use their "local" 
ALTO server. Thus the tracker would use ALTO to find the peers in the general 
vicinity of the requesting peer.
For example, if the peer is in Japan, the tracker would return peers in Asia, 
while if the peer is in Paris, the tracker would return peers in Europe. The 
requesting peer in Paris would use its local ALTO server to determine which 
peers are in France and which are in (say) Hungary.

=> I've added at the end of section 4.2.2:  "In principle, a combined approach 
could also be possible. For instance, a tracker could use a coarse-grained  
"global" ALTO server to find the peers in the general  vicinity of the 
requesting peer, while peers could use  "local" ALTO servers for a more 
fine-grained guidance. Yet,  there is no known deployment experience for such a 
combined approach."


-
{Informative References}:
This section references a number of drafts that are more than a year old. By 
now, those have either become RFCs, been superseded by newer versions, or else 
have been moved to the cosmic bit bucket. In any case, references to expired 
drafts are not very informative, and they make this document look out-of-date. 
I suggest the authors update the document to reference the latest versions, and 
drop references to drafts that have expired.

=> Updating any out-dated references will be handled by the RFC editor. Quite a 
number of those references have been there when I started editing the document. 
Others have been added based on mailing list requests. And clearly some of the 
drafts include relevant content even if it is not clear if there will be an RFC 
(e.g., draft-lee-alto-chinatelecom-trial). I updated some of the outdated 
references, but I hesitate to remove references.


-
Minor suggestions:
-

-
{3.1.2}, Figure 5: It would help if you could make the graph planar.  Eg, have 
the "non-preferred" line go from Host 1 (not 2) to Host 4, move Host 1 up, and 
Host 4 down. Then re-route the non-preferred lines from Host 1 to ISP X to Host 
4 above ISP 1 and below ISP 2.

=> I have changed the routing of the non-preferred lines, but I have not 
completely changed the layout. I think the key point in this figure is that 
traffic for the non-preferred connection goes from ISP 1 to ISP X and then to 
ISP 2. Rerouting the non-preferred lines outside ISP 1 and ISP 2 would make it 
more difficult to see that the non-preferred connections traverse several ISPs. 
As additional explanation, I have also added the label "inter-network traffic" 
inside the figure.


-
{3.1.3}: Does this section really add anything new?  It seems like this example 
is isomorphic to {3.1.2}. Just change "ISP 1" and "ISP 2" to "Net 1" and "Net 
2", and change "ISP X" to "bottleneck inter-island connection".

=> Yes, both sections are similar. But the motivat

Re: [alto] Call for adoption for incremental updates and server-side notifications

[Scharf, Michael (Michael)]

This document looks good to me. We've been discussing this topics for years 
already...

Michael


> -Original Message-
> From: alto [mailto:alto-boun...@ietf.org] On Behalf Of Vijay K. Gurbani
> Sent: Tuesday, April 28, 2015 10:00 PM
> To: alto
> Subject: [alto] Call for adoption for incremental updates and server-
> side notifications
> 
> Folks: During the Dallas IETF, we agreed to issue a call for adopting
> incremental updates and server-side notification (version 2 [1]) as a
> WG item.
> 
> The chairs believe that there are no competing proposals for
> incremental
> updates and server side notifications besides the draft at hand [1].
> 
> This email serves as a notice to the call for adoption.  The call for
> adoption will end on Wednesday, May 13 2015.  Please reply to the
> mailing list indicating support or opposition to such an adoption.  We
> also solicit any comments on the document contents as well.
> 
> [1] https://datatracker.ietf.org/doc/draft-roome-alto-incr-update-sse/
> 
> Thank you,
> 
> - vijay
> --
> Vijay K. Gurbani, Bell Laboratories, Alcatel-Lucent
> 1960 Lucent Lane, Rm. 9C-533, Naperville, Illinois 60563 (USA)
> Email: vkg@{bell-labs.com,acm.org} / vijay.gurb...@alcatel-lucent.com
> Web: http://ect.bell-labs.com/who/vkg/  | Calendar: http://goo.gl/x3Ogq
> 
> ___
> alto mailing list
> alto@ietf.org
> https://www.ietf.org/mailman/listinfo/alto

___
alto mailing list
alto@ietf.org
https://www.ietf.org/mailman/listinfo/alto

[alto] Background on IANA registry for ALTO Endpoint Property Type?

[Scharf, Michael (Michael)]

Hi,

Does somebody with a memory better than mine recall why RFC 7285 mandates that 
endpoint properties are assigned by IETF review (other than "priv:")? This 
results in a rather high bar and possibly in a large number of RFCs as new use 
cases of ALTO emerge.
 
Why does RFC 7285 not use some simpler registration procedure, such as expert 
review?

At first sight, we could perhaps have avoided some of today's discussion if 
ALTO would not need IETF review for each endpoint type that could possibly be 
useful in some ALTO deployments.

Thanks

Michael

___
alto mailing list
alto@ietf.org
https://www.ietf.org/mailman/listinfo/alto

[alto] draft-ietf-alto-deployments-11

[Scharf, Michael (Michael)]

Dear all,

Sebastian and me have spent quite some cycles to sort out remaining open issues 
in draft-ietf-alto-deployments.

The improvements compared to -10 include amongst others:

- Alignment with RFC 7285 throughout the document

- Updated Section 2.2.1. Roles in ALTO Deployments, better explaining the main 
entities in an ALTO deployment

- Extended and improved Sections 3.2.1. Data Sources, 3.2.2. Privacy 
Requirements, 3.2.3. Partitioning and Grouping of IP Address Ranges, and 3.2.4. 
Rating Criteria and/or Cost Calculation

- New Section 3.3.3. General Limitations, describing the scope of ALTO and 
limitations compared to other approaches

- Some internal reorganization in Section 4, without significant modifications 
of the content

- New Figure 20

- New Section 6.3. Other Application-based Network Operations

- Completely rewritten Section 7. Security Considerations; the rewording keeps 
the content that is referenced in RFC 7285

- Moving Appendix A to Section 10. Acknowledgments

- Some additional references, e.g., [I-D.kiesel-alto-xdom-disc]

- Many minor editorial improvements

Please have a look and let us know any feedback. Sebastian and me believe that 
the document is now relatively mature and captures what is known as of today 
about deployment implications of ALTO.

Thanks

Michael



-Original Message-
From: I-D-Announce [mailto:i-d-announce-boun...@ietf.org] On Behalf Of 
internet-dra...@ietf.org
Sent: Monday, March 02, 2015 7:14 PM
To: i-d-annou...@ietf.org
Cc: alto@ietf.org
Subject: I-D Action: draft-ietf-alto-deployments-11.txt


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
Authors : Martin Stiemerling
  Sebastian Kiesel
  Stefano Previdi
  Michael Scharf
Filename: draft-ietf-alto-deployments-11.txt
Pages   : 62
Date: 2015-03-02

Abstract:
   Many Internet applications are used to access resources such as
   pieces of information or server processes that 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 applications that have to select one or several hosts
   from a set of candidates, which are able to provide a desired
   resource.  This memo discusses deployment related issues of ALTO.  It
   addresses different use cases of ALTO such as peer-to-peer file
   sharing and CDNs and presents corresponding examples.  The document
   also includes recommendations for network administrators and
   application designers planning to deploy 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-11

A diff from the previous version is available at:
http://www.ietf.org/rfcdiff?url2=draft-ietf-alto-deployments-11


Please note that it may take a couple of minutes from the time of submission
until the htmlized version and diff are available at tools.ietf.org.

Internet-Drafts are also available by anonymous FTP at:
ftp://ftp.ietf.org/internet-drafts/

___
I-D-Announce mailing list
i-d-annou...@ietf.org
https://www.ietf.org/mailman/listinfo/i-d-announce
Internet-Draft directories: http://www.ietf.org/shadow.html
or ftp://ftp.ietf.org/ietf/1shadow-sites.txt

___
alto mailing list
alto@ietf.org
https://www.ietf.org/mailman/listinfo/alto

Re: [alto] ALTO topology design: separation design

[Scharf, Michael (Michael)]

Richard,

I’d like to understand a simpler question first; I don’t recall whether we have 
already discussed this basic scenario so far: Assume we have PID1  and PID2 and 
the ALTO server operator wants to announce that there are two entirely disjoint 
paths between those PIDs. The path vector would probably just include ANE1 and 
ANE2 as alternatives. Is there a way to encode this simple scenario in path 
vector without using the “general flow” model?

If we go for general flow, could we make the weight parameter optional?

Michael


PS: Other naming suggestions: Provider-Defined Network Element (PAE), 
Provider-Defined Topology Entity (PTE), Provider-Defined Path Element (PPE), or 
use of “Abstract” instead of “Provider-Defined”, or combinations thereof…



From: yang.r.y...@gmail.com [mailto:yang.r.y...@gmail.com] On Behalf Of Y. 
Richard Yang
Sent: Wednesday, February 25, 2015 10:35 PM
To: Scharf, Michael (Michael)
Cc: ROOME, Wendy D (Wendy); alto@ietf.org
Subject: Re: [alto] ALTO topology design: separation design



On Wed, Feb 25, 2015 at 4:24 PM, Y. Richard Yang 
mailto:y...@cs.yale.edu>> wrote:
I also support the terminology of Abstract Network Elements (ANE). The idea of 
introducing an abstract network (graph) element that is a base for both nodes 
(vertices) and links (edges) is clean. For example, this is also the design of 
Blueprints; see 
https://github.com/tinkerpop/blueprints/wiki/Property-Graph-Model.

Here are some more details that we need to agree on. The quoted sentences are 
from Wendy's previous email:

Q1: "* A new cost metric gives the set of NEs involved in delivering packets
from the source PID to the destination PID. Note that although those NEs
are represented with a JSON array, the order is irrelevant; it really is a
set."

So this is by using cost map. All agree?

Before we go too far regarding exposing path vectors to applications. One issue 
is that there can be the issue of multi-path routing (e..g, ECMP). Hence, a 
more general design is to use a flow model (see slides 10 to 12 of 
http://www.ietf.org/proceedings/91/slides/slides-91-alto-4.pdf). I am sure some 
(Greg? :-) and some will not. We need to reach an agreement on this.

Q2: "* Like endpoints and PIDs, NEs can have properties. Eg, type, bandwidth,
delay, etc."

What is the map (or maps) for such mapping of properties? We already have 
endpoint properties. Ideally, this new mapping (and the additional PID property 
mapping) should be designed to be consistent. All agree?

Thanks!
Richard


On Wed, Feb 25, 2015 at 4:09 PM, Scharf, Michael (Michael) 
mailto:michael.sch...@alcatel-lucent.com>> 
wrote:
Regarding terminology: I like the idea of introducing an Abstract Network 
Elements (ANE). Maybe we could also use a term like Abstract Element/Entity 
(AE).

We should probably avoid the acronym NE, since this is used by the network 
management community, but in a different context (typically implying a device).

Michael

-Ursprüngliche Nachricht-
Von: alto [mailto:alto-boun...@ietf.org<mailto:alto-boun...@ietf.org>] Im 
Auftrag von Wendy Roome
Gesendet: Mittwoch, 25. Februar 2015 21:51
An: alto@ietf.org<mailto:alto@ietf.org>
Betreff: Re: [alto] ALTO topology design: separation design

I also prefer the separation strategy. I don't think we have enough legacy 
clients to worry about (*sigh*), but a PID as a collection of endpoints defined 
by a set of CIDRs is a simple, easy-to-understand concept. Most ALTO clients 
will not care about topology. So why complicate life for them?

To summarize my idea of the separation approach:

* We define a new entity, called (say) a Network Element (NE). An NE is 
something that packets must go through to get from one PID to another. An NE 
can be a link, a router, a node, or some conglomeration of all of those. If you 
want to make it crystal clear that NEs can be a conglomerate, we could call 
them Abstract Network Elements, or ANEs.

* Like PIDs, NEs have unique names. And like PID names, NE names are 
meaningless outside of the context of the ALTO server that defines them.

* A new cost metric gives the set of NEs involved in delivering packets from 
the source PID to the destination PID. Note that although those NEs are 
represented with a JSON array, the order is irrelevant; it really is a set.

* Like endpoints and PIDs, NEs can have properties. Eg, type, bandwidth, delay, 
etc.

* If the NE set from Pid1->Pid2 intersects the NE set from Pid3->Pid4, then the 
client knows those two flows are dependent: they may have a common point of 
failure, or they may limit each other, or whatever.

- Wendy Roome


>Date: Wed, 25 Feb 2015 15:29:16 +
>From: "Scharf, Michael (Michael)" 
>mailto:michael.sch...@alcatel-lucent.com>>
>Subject: Re: [alto] ALTO topology design: separation design
>
>
>I think one the key ideas of ALTO is that a PID refers to (potential)
>l

Re: [alto] ALTO topology design: separation design

[Scharf, Michael (Michael)]

Regarding terminology: I like the idea of introducing an Abstract Network 
Elements (ANE). Maybe we could also use a term like Abstract Element/Entity 
(AE).

We should probably avoid the acronym NE, since this is used by the network 
management community, but in a different context (typically implying a device).

Michael 

-Ursprüngliche Nachricht-
Von: alto [mailto:alto-boun...@ietf.org] Im Auftrag von Wendy Roome
Gesendet: Mittwoch, 25. Februar 2015 21:51
An: alto@ietf.org
Betreff: Re: [alto] ALTO topology design: separation design

I also prefer the separation strategy. I don't think we have enough legacy 
clients to worry about (*sigh*), but a PID as a collection of endpoints defined 
by a set of CIDRs is a simple, easy-to-understand concept. Most ALTO clients 
will not care about topology. So why complicate life for them?

To summarize my idea of the separation approach:

* We define a new entity, called (say) a Network Element (NE). An NE is 
something that packets must go through to get from one PID to another. An NE 
can be a link, a router, a node, or some conglomeration of all of those. If you 
want to make it crystal clear that NEs can be a conglomerate, we could call 
them Abstract Network Elements, or ANEs.

* Like PIDs, NEs have unique names. And like PID names, NE names are 
meaningless outside of the context of the ALTO server that defines them.

* A new cost metric gives the set of NEs involved in delivering packets from 
the source PID to the destination PID. Note that although those NEs are 
represented with a JSON array, the order is irrelevant; it really is a set.

* Like endpoints and PIDs, NEs can have properties. Eg, type, bandwidth, delay, 
etc.

* If the NE set from Pid1->Pid2 intersects the NE set from Pid3->Pid4, then the 
client knows those two flows are dependent: they may have a common point of 
failure, or they may limit each other, or whatever.

- Wendy Roome


>Date: Wed, 25 Feb 2015 15:29:16 +
>From: "Scharf, Michael (Michael)" 
>Subject: Re: [alto] ALTO topology design: separation design
>
>
>I think one the key ideas of ALTO is that a PID refers to (potential) 
>locations of application instances, i.e., endpoints. ALTO is a solution 
>to provide topology guidance between endpoints.
>
>With path vector encoding, we have additional entities for ?something?
>that is in the middle between endpoints, e.g., a shared bottleneck of 
>two path vectors. Conceptually, this entity representing a shared 
>bottleneck is quite different to an endpoint: First, in many cases we 
>won?t expect that an application runs instances at such a bottleneck. 
>And second, these entities may use other identifiers. For instance, a 
>switch or a router may not have any globally unique IP address, or even 
>if it has one (e.g., router system address), the network operator may 
>not necessarily be interested in exposing this in an ALTO server, e.g., 
>to P2P applications.
>
>To me, the question of whether to use unified PID comes down to:
>
>1)  Distinguish different types of PIDs, i.e., add some form of ?type
>field? for PIDs. I think we had a related discussion some time ago 
>regarding ?Transactional PIDs?.
>
>2)  Add a new entity in addition to PIDs that is used e.g. in the
>path-vector format, i.e., separation design.
>
>I think both approaches can work. IMHO, one of the constraints for 
>picking a solution would be ?legacy? ALTO clients. For instances, let?s 
>assume that an ALTO server offers path-vector style ALTO maps, but not 
>all ALTO clients support it. For instance, a P2P application may only 
>understand ?traditional? network and cost maps. In this case, it 
>probably makes sense not to expose in network maps those PIDs a ?legacy?
>application would not care about. This means that path-vector guidance 
>would probably be exposed in a new network map (e.g., different MIME 
>type). Furthermore, I?d argue that in this scenario it could make sense 
>to allow an ALTO server operator to use the same PID names both in the 
>network maps for ?legacy? and ?path-vector? users, in order to simplify 
>management. In general, I believe that separation is a slightly more 
>natural design choice under these constraints.
>
>Thoughts?
>
>Michael


___
alto mailing list
alto@ietf.org
https://www.ietf.org/mailman/listinfo/alto

___
alto mailing list
alto@ietf.org
https://www.ietf.org/mailman/listinfo/alto

Re: [alto] ALTO topology design: separation design

[Scharf, Michael (Michael)]

Hi Richard,

I think one the key ideas of ALTO is that a PID refers to (potential) locations 
of application instances, i.e., endpoints. ALTO is a solution to provide 
topology guidance between endpoints.

With path vector encoding, we have additional entities for “something” that is 
in the middle between endpoints, e.g., a shared bottleneck of two path vectors. 
Conceptually, this entity representing a shared bottleneck is quite different 
to an endpoint: First, in many cases we won’t expect that an application runs 
instances at such a bottleneck. And second, these entities may use other 
identifiers. For instance, a switch or a router may not have any globally 
unique IP address, or even if it has one (e.g., router system address), the 
network operator may not necessarily be interested in exposing this in an ALTO 
server, e.g., to P2P applications.

To me, the question of whether to use unified PID comes down to:

1)  Distinguish different types of PIDs, i.e., add some form of “type 
field” for PIDs. I think we had a related discussion some time ago regarding 
“Transactional PIDs”.

2)  Add a new entity in addition to PIDs that is used e.g. in the 
path-vector format, i.e., separation design.

I think both approaches can work. IMHO, one of the constraints for picking a 
solution would be “legacy” ALTO clients. For instances, let’s assume that an 
ALTO server offers path-vector style ALTO maps, but not all ALTO clients 
support it. For instance, a P2P application may only understand “traditional” 
network and cost maps. In this case, it probably makes sense not to expose in 
network maps those PIDs a “legacy” application would not care about. This means 
that path-vector guidance would probably be exposed in a new network map (e.g., 
different MIME type). Furthermore, I’d argue that in this scenario it could 
make sense to allow an ALTO server operator to use the same PID names both in 
the network maps for “legacy” and “path-vector” users, in order to simplify 
management. In general, I believe that separation is a slightly more natural 
design choice under these constraints.

Thoughts?

Michael


From: alto [mailto:alto-boun...@ietf.org] On Behalf Of Y. Richard Yang
Sent: Tuesday, February 24, 2015 11:40 PM
To: IETF ALTO
Subject: [alto] ALTO topology design: separation design

Dear all,

The authors of the ALTO topology draft are working to make progress on key 
design issues, in particular, the issues left open at IETF 91:
http://www.ietf.org/proceedings/91/slides/slides-91-alto-4.pdf

One key design choice is using unified PID/Network (Device) node or not; see 
slides 17-18 of the proceeding slides for discussions. At IETF 91, the favor 
was a separation design (slide 19), but no decision was made. After much 
thinking, and evaluation of related work, we propose to proceed with the 
separation design. This is similar to emerging general node-graph design such 
as that of ONOS, which uses Nodes, Link, Host, EdgeLink, Path. If you have any 
objection, please feel free to raise the issues soon.

Thanks.

Richard
___
alto mailing list
alto@ietf.org
https://www.ietf.org/mailman/listinfo/alto

Re: [alto] ALTO Cost calendars in wireless access networks

[Scharf, Michael (Michael)]

Hi Uwe, all,

Personally, I am not sure whether a single RAN cell is indeed the right 
granularity for PIDs.

But draft-ietf-alto-deployments is a WG document and in general the editors 
have been open to suggestions for further realistic deployment cases of ALTO. 
draft-ietf-alto-deployments has some text already on mobile access networks, 
albeit at a much larger granularity of PIDs.

As usual in the IETF: Propose specific text ;)

Best regards

Michael



From: alto [mailto:alto-boun...@ietf.org] On Behalf Of Rauschenbach, Uwe (NSN - 
DE/Munich)
Sent: Friday, November 14, 2014 1:06 AM
To: RANDRIAMASY, SABINE (SABINE); Xiao SHI
Cc: IETF ALTO
Subject: Re: [alto] ALTO Cost calendars in wireless access networks

Hi Sabine,

Is http://tools.ietf.org/html/draft-ietf-alto-deployments-10 the appropriate 
place to add these?

Kind regards,
Uwe

From: ext RANDRIAMASY, SABINE (SABINE) 
[mailto:sabine.randriam...@alcatel-lucent.com]
Sent: Wednesday, November 12, 2014 5:40 AM
To: Xiao SHI; Rauschenbach, Uwe (NSN - DE/Munich)
Cc: IETF ALTO
Subject: RE: [alto] ALTO Cost calendars in wireless access networks

Hi Xiao and Uwe,

The cellular or other access use case also calls I think for looking at related 
ALTO Service deployment cases.
Best,
Sabine


De : boxs...@gmail.com [mailto:boxs...@gmail.com] De 
la part de Xiao SHI
Envoyé : mercredi 12 novembre 2014 07:38
À : Rauschenbach, Uwe (NSN - DE/Munich)
Cc : RANDRIAMASY, SABINE (SABINE); IETF ALTO
Objet : Re: [alto] ALTO Cost calendars in wireless access networks

Hi Uwe,

Your document sounds like a very reasonable and useful extension. Just have two 
related thoughts:

1. Have you considered your cells extension using PID properties? The relevant 
draft is here: 
http://tools.ietf.org/html/draft-roome-alto-pid-properties-02#section-4.2 I 
believe the PID property document provides a solution to both requirements in 
your document (via Solution B).

2. Since the nodes change cells frequently, do you think this extension would 
benefit from incremental updates? The incr update document 
(http://datatracker.ietf.org/doc/draft-roome-alto-incr-update-sse/) provides 
the SSE framework, but I am not sure how convenient SSE is to mobile networks.

Best,
Xiao

On Tue, Nov 11, 2014 at 10:23 PM, Rauschenbach, Uwe (NSN - DE/Munich) 
mailto:uwe.rauschenb...@nsn.com>> wrote:
Hi Sabine,

Thanks for the pointer. Yes, I think your proposal will meet the expectations 
of the sketched use cases.
In fact, our proposal is orthogonal and tries to address the problem that in 
mobile networks, the network attachment
point can be one additional important parameter that should be addressed in 
ALTO.

So far, ALTO helps to decide “where to connect to” (where: the endpoint that 
provides the service).
The cost calendar enhances this to become “when and where to connect to”.
In mobile, the whole picture would become “via which cell/access, when and 
where to connect to”.

Kind regards,
Uwe


From: ext RANDRIAMASY, SABINE (SABINE) 
[mailto:sabine.randriam...@alcatel-lucent.com]
Sent: Tuesday, November 11, 2014 8:36 AM
To: Rauschenbach, Uwe (NSN - DE/Munich)
Cc: IETF ALTO
Subject: ALTO Cost calendars in wireless access networks

Hi Uwe,

I see that your draft 
http://tools.ietf.org/id/draft-rauschenbach-alto-wireless-access-00.txt will be 
presented in the next ALTO WG session.

Given that your draft poses the need for a calendar in its following sections 
3.2.1.  Cost calendar to extend battery life for background tasks and section 
3.2.2.  Cost calendar to optimize application sessions, you may want to look at 
http://tools.ietf.org/id/draft-randriamasy-alto-cost-calendar-02.txt, that 
proposes ALTO cost calendars and will be presented during the ALTO WG session 
as well, as it would be interesting to see how this proposal may meet your 
expectations.

Best regards,
Sabine


___
alto mailing list
alto@ietf.org
https://www.ietf.org/mailman/listinfo/alto

___
alto mailing list
alto@ietf.org
https://www.ietf.org/mailman/listinfo/alto

Re: [alto] JSON Patch vs. custom representation for incremental updates

[Scharf, Michael (Michael)]

> > > do we have any idea whether 5000 PIDs is a realistic assumption for
> > > foreseeable deployments?
> >
> > Indeed, 5000 seems like an extreme case. Yet, I think one could
> really
> > end up there, depending on how ALTO is used.
> >
> > For instance, let's assume an ALTO use case like
> > draft-scharf-alto-vpn-service for a large enterprise with many
> > branches. As argued in the draft, only could possibly use one PID for
> > each VPN endpoint.
> >
> > In that case, 5000 is not entirely unrealistic. As a random data
> > point, Bank of America is reported to have 5,377 branches in the US.
> > Other large organizations (e.g., retailers) may have a similar order
> > of magnitude of branches. A L2VPN or L3VPN could be used to
> > interconnect such branches.
> >
> > Obviously, there are certain ways to reduce the network/cost size in
> > such a scenario, e.g., by introducing a hierarchy, or by topology
> > encoding (for cost map). Also, I doubt that an application would
> > really require an accurate cost map entry for any given combination
> of
> > PIDs. Thus, 5000 looks like a kind of worst-case scenario.
> 
> In this use case, would you really have a full(!) 5000x5000 matrix?
> Or would it be more like a sparse matrix, defining cost only for
> 5000 branch offices X 100 data centers,
> while most (all?) other costs (i.e., branch office to branch office)
> are
> "default"?

Sure, the non-default-entries in such a matrix could be sparse (and topology 
encoding could help). And, indeed, as already mentioned, I'd guess that one 
would mainly be interested in a small subset of the cost map. As a result, 
5000x100 may be more realistic than 5000x5000. But we still have O(5000) PIDs.

Michael

___
alto mailing list
alto@ietf.org
https://www.ietf.org/mailman/listinfo/alto

Re: [alto] JSON Patch vs. custom representation for incremental updates

[Scharf, Michael (Michael)]

> On Wed, Jul 09, 2014 at 03:14:56PM -0400, Wendy Roome wrote:
> > As for the second point, incremental update is only necessary for
> large
> > maps. If a map only has 25 PIDs, why bother? Just download a new
> version.
> > What do I mean by "large"? A Network Map with 5,000 PIDs, 250,000
> > prefixes, and up to 25,000,000 cost points.
> 
> A full 5000x5000 cost map would be in the order of 130 MB gzipped json
> (see "The size of the cost map" thread on the ALTO list Fri, 22 Mar
> 2013).
> 
> do we have any idea whether 5000 PIDs is a realistic assumption for
> foreseeable deployments?

Indeed, 5000 seems like an extreme case. Yet, I think one could really end up 
there, depending on how ALTO is used.

For instance, let's assume an ALTO use case like draft-scharf-alto-vpn-service 
for a large enterprise with many branches. As argued in the draft, only could 
possibly use one PID for each VPN endpoint. 

In that case, 5000 is not entirely unrealistic. As a random data point, Bank of 
America is reported to have 5,377 branches in the US. Other large organizations 
(e.g., retailers) may have a similar order of magnitude of branches. A L2VPN or 
L3VPN could be used to interconnect such branches.

Obviously, there are certain ways to reduce the network/cost size in such a 
scenario, e.g., by introducing a hierarchy, or by topology encoding (for cost 
map). Also, I doubt that an application would really require an accurate cost 
map entry for any given combination of PIDs. Thus, 5000 looks like a kind of 
worst-case scenario.

Michael







___
alto mailing list
alto@ietf.org
https://www.ietf.org/mailman/listinfo/alto

[alto] draft-ietf-alto-deployments-10

[Scharf, Michael (Michael)]

Hi all,

I tried to address all obvious open issues in -09, as far as I can.

Here is a list of some of the updates:

* Adding of a section on terminology with reference to RFC 5693, in particular 
regarding the term "ALTO server", based on a discussion with Sebastian, as well 
as related updates of Section 2.2.3

* Some updated text in the section on rating criteria (Section 3.2.4), 
including a reference to draft-wu-alto-te-metrics

* Changes to the monitoring text (Section 3.4) as discussed before/during the 
last meeting; the text should now address all comments I received on that 
section

* Some consistency updates between different sections in the P2P use case 
(Section 4)

* Improvements of the security section (Section 7) with better references to 
the new security section in the protocol specification

* Many small editorial changes 

The full diff compared to -09 can be found at the link below.

Thanks

Michael



-Original Message-
From: alto [mailto:alto-boun...@ietf.org] On Behalf Of internet-dra...@ietf.org
Sent: Thursday, July 03, 2014 12:26 PM
To: i-d-annou...@ietf.org
Cc: alto@ietf.org
Subject: [alto] I-D Action: draft-ietf-alto-deployments-10.txt


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
Authors : Martin Stiemerling
  Sebastian Kiesel
  Stefano Previdi
  Michael Scharf
Filename: draft-ietf-alto-deployments-10.txt
Pages   : 55
Date: 2014-07-03

Abstract:
   Many Internet applications are used to access resources such as
   pieces of information or server processes that 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 applications that have to select one or several hosts
   from a set of candidates, which are able to provide a desired
   resource.  This memo discusses deployment related issues of ALTO.  It
   addresses different use cases of ALTO such as peer-to-peer file
   sharing and CDNs and presents corresponding examples.  The document
   also includes recommendations for network administrators and
   application designers planning to deploy 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-10

A diff from the previous version is available at:
http://www.ietf.org/rfcdiff?url2=draft-ietf-alto-deployments-10


Please note that it may take a couple of minutes from the time of submission
until the htmlized version and diff are available at tools.ietf.org.

Internet-Drafts are also available by anonymous FTP at:
ftp://ftp.ietf.org/internet-drafts/

___
alto mailing list
alto@ietf.org
https://www.ietf.org/mailman/listinfo/alto

___
alto mailing list
alto@ietf.org
https://www.ietf.org/mailman/listinfo/alto

Re: [alto] ALTO topology/graph representation (Fwd: New Version Notification for draft-yang-alto-topology-03.txt)

[Scharf, Michael (Michael)]

Hi all,

As mentioned by Richard, I happened to write some text as well. Having a second 
draft was actually not intended by me.

Anyway, I used slides 24 and 25 from the last meeting 
http://tools.ietf.org/agenda/89/slides/slides-89-alto-2.pdf as basis of a 
model, and since these slides were joint work with Richard, Young, and Greg, my 
model and wording is very similar to draft-yang-alto-topology.

You can now find my writeup in 
http://tools.ietf.org/html/draft-scharf-alto-topology-00

From a technical perspective, the model in draft-yang-alto-topology has a much 
better formal definition and it seems to me like a better starting point for 
moving forward this work in the ALTO WG.

Therefore, I suggest to focus the discussion on draft-yang-alto-topology 
instead of my specific model. I actually only post this document now given that 
it has been mentioned already. Perhaps some of the text on the scope could be 
re-used.

Thanks

Michael


From: alto [mailto:alto-boun...@ietf.org] On Behalf Of Y. Richard Yang
Sent: Wednesday, July 02, 2014 7:58 AM
To: IETF ALTO
Subject: [alto] ALTO topology/graph representation (Fwd: New Version 
Notification for draft-yang-alto-topology-03.txt)

Dear all,

We have submitted an update of the net-graph draft below. The goal of the draft 
is to study the graph representation WG item. Here is a quick summary of some 
key components of the draft and related issues:

1. A parallel draft by Michael Scharf (who is a co-author of this draft) as 
well will be posted soon. Michael's draft will emphasize more on the scope of 
the work, to avoid conflict with the Routing Area.

2. The draft uses a simple multi-flow scheduling use case to argue that we need 
an path-vector + X representation. We do not have a formal proof that 
path-vector must be used, but we do not see an alternative without using 
path-vectors to convey network policies. This is important given that ALTO 
targets applications and hence needs to convey network policy constraints. If 
you have a counter-argument (i.e., solution), or a more formal argument, we are 
eager to listen to your point of view.

3. The draft gives two possibilities for the aforementioned X to complete the 
design: (1) X is an unstructured hash from network element to element 
properties, and (2) X is a node-edge graph representation. In (1), there is 
actually no need to distinguish between nodes and edges. From the multi-flow 
use case alone, we cannot make a convincing argument that we need the more 
structured case of (2). To finish the argument for using X = node-edge graph, 
we feel that we will have to need an application-layer guided network-layer 
routing (e.g., SDN) use case. Any insightful input/comments on this aspect will 
be highly interesting and appreciated!

Richard


-- Forwarded message --
From: mailto:internet-dra...@ietf.org>>
Date: Wed, Jul 2, 2014 at 12:58 AM
Subject: New Version Notification for draft-yang-alto-topology-03.txt
To: Greg Bernstein 
mailto:gr...@grotto-networking.com>>, Michael 
Scharf 
mailto:michael.sch...@alcatel-lucent.com>>, 
"Y. Richard Yang" mailto:y...@cs.yale.edu>>, Young Lee 
mailto:leeyo...@huawei.com>>, Wendy Roome 
mailto:w.ro...@alcatel-lucent.com>>



A new version of I-D, draft-yang-alto-topology-03.txt
has been successfully submitted by Y. Richard Yang and posted to the
IETF repository.

Name:   draft-yang-alto-topology
Revision:   03
Title:  ALTO Topology Extensions
Document date:  2014-07-01
Group:  Individual Submission
Pages:  16
URL:
http://www.ietf.org/internet-drafts/draft-yang-alto-topology-03.txt
Status: https://datatracker.ietf.org/doc/draft-yang-alto-topology/
Htmlized:   http://tools.ietf.org/html/draft-yang-alto-topology-03
Diff:   http://www.ietf.org/rfcdiff?url2=draft-yang-alto-topology-03

Abstract:
   The Application-Layer Traffic Optimization (ALTO) Service has defined
   Network and Cost maps to provide basic network information.  In this
   document, we discuss an initial design to provide abstracted graph
   representations of network topology, motivated by a basic application
   use case of multi-flow scheduling.  The design is based on the ALTO
   WG discussions at IETF 89.





Please note that it may take a couple of minutes from the time of submission
until the htmlized version and diff are available at 
tools.ietf.org.

The IETF Secretariat



--
--
 =
| Y. Richard Yang mailto:y...@cs.yale.edu>>   |
| Professor of Computer Science   |
| http://www.cs.yale.edu/~yry/|
 =
___
alto mailing list
alto@ietf.org
https://www.ietf.org/mailman/listinfo/alto

Re: [alto] FW: New Version Notification for draft-deng-alto-p2p-ext-02.txt

[Scharf, Michael (Michael)]

Regarding geo-location, which is mentioned below: Yes, indeed, I’ve argued many 
times that there are a number of important concepts that ALTO extensions should 
support. Geo-location is one of them.

In general, geo-location  can either be a property of a PID 
(draft-roome-alto-pid-properties) or of an endpoint. The former is possibly 
less privacy sensitive and sufficient in some cases, but since the mechanisms 
would be similar, possibly both can be achieved in the same way (and the same 
document).

My own thinking is to try to keep standardized ALTO extensions as generic as 
possible so that they are useful for different use cases of ALTO.  I’d favor 
generic extensions instead of mechanisms that are specific to some P2P 
deployment scenarios. For instance, the metrics in draft-wu-alto-te-metrics are 
fairly generic and applicably in different scenarios – this seems to me a 
useful approach that we should aim for regarding ALTO properties as well.

Michael



From: alto [mailto:alto-boun...@ietf.org] On Behalf Of Y. Richard Yang
Sent: Saturday, June 28, 2014 9:35 AM
To: Songhaibin (A)
Cc: IETF ALTO
Subject: Re: [alto] FW: New Version Notification for 
draft-deng-alto-p2p-ext-02.txt

Hi Haibin,

Please see below.

On Saturday, June 28, 2014, Songhaibin (A) 
mailto:haibin.s...@huawei.com>> wrote:
Hi Richard,

Thank you very much for your comments, please see inline.

From: alto [mailto:alto-boun...@ietf.org] On Behalf Of Y. Richard 
Yang
Sent: Friday, June 27, 2014 11:46 PM
To: 邓灵莉/Lingli Deng
Cc: IETF ALTO
Subject: Re: [alto] FW: New Version Notification for 
draft-deng-alto-p2p-ext-02.txt

Hi Lingli, Sebastian, Haibin,

Interesting doc!  I am wondering the possibility of you adding an overview 
section to discuss the potential types of end point properties and your design 
guidelines so that we have a better understanding of the design:

- For example, I do not have a feeling that the properties that the current 
draft defined are relatively complete. What is the potential set of properties 
and why you choose the ones?

[Haibin] This is a very interesting question and should be seriously 
considered. We chose the ones in the draft due to people usually consider them 
for peer selection, and they were discussed during the early stage of ALTO 
working group.

[yry] Two comments. One, I feel that ALTO can and should go beyond only peer 
selection for P2P. Hence, it will be interesting to consider other endpoint 
properties.

One reason I ask is that I see geo-location as a quite useful property, but it 
is missing in your draft. I am traveling right now, and it is common for apps 
trying to determine my location. We discussed so e other use cases on location 
as well. It could even be virtual location, such as rack id. Using ALTO to 
provide this natural. Hence, I suggest that the WG in general and your team 
(Sebastian, Lingli, you) in particular, given that your team is leading the 
endpoint property effort, conducts the exercise, so that we get a sense of the 
general set. Then we follow the charter to prune the list. I feel that Michael 
will have opinions as well.


- One can convey the properties in multiple ways. For example, the current 
draft defines p2p_caching as a boolean. Another design possibility is to define 
a generic type with values including "p2p_cache", "super_peer", ...

[Haibin] Yes. We need to choose one representation type. If several properties 
can be classified into one class, I agree one generic type name for the class 
(and then define the values) would be better.

[yry] It depends on the setting. In other words, do you need a type or types 
(set)...

As another example we consider volume related property. The current draft 
defines a boolean. Another alternative is to use a numeric value of the exact 
cap.

[Haibin] I'm not sure on this one. A user with 1G bytes and another user with 
100M bytes mobile traffic quota might  have the same strong will to not use his 
upload traffic.
[yry] interesting point! I often set a limit on my android, when I am traveling 
and using a data plan with a cap that I may exceed quickly. This leads to the 
following question: such info comes from endpoint itself, instead of the 
provider. Hence, I see two protocol flow possibilities:

Option 1: provider provides its set of info (say ALTO on data plan cap) to app +
endpoint provides its set of info to app directly;

vs

Option 2: endpoint sends such info to provider, and ALTO sever aggregates all 
info to allow app access.

In both cases endpoint can inject policy on access control. Option 1 appears to 
allow more fine-grained access control (user approval on per app basis).

Another example is access network type. I saw the previous discussion on issues 
that technology types become obsolete and hence the change to avoid use them. 
One comment is that knowing network type can provide information about 
behaviors that an application may use -- Sebastian's comment has alluded to 
this as we

[alto] Potential privacy issue in draft-deng-alto-p2p-ext-01?

[Scharf, Michael (Michael)]

Haibin asked me to send the following comment from a private discussion also to 
the list:

Section 3.3 of draft-deng-alto-p2p-ext-01 suggest a new Endpoint Property Type 
"network_access" for P2P peer selection. As far as I recall, this type of ALTO 
guidance was discussed in the past quite a bit, and there may have been privacy 
concerns. For instance, draft-ietf-alto-deployments-09 Section 3.2.4. includes 
the following statement:

   o  Performance metrics that raise privacy concerns.  For instance, it
  has been questioned whether an ALTO service could publicly expose
  the provisioned access bandwidth, e.g. of cable / DSL customers,
  because this could enables identification of "premium" customers.

That text was already in draft-ietf-alto-deployments before I started to edit 
this document.

For P2P use cases, I wonder whether that concern might (still) apply to 
endpoint properties such as DSL vs. FTTH as currently suggested 
draft-deng-alto-p2p-ext-01.

Michael



___
alto mailing list
alto@ietf.org
https://www.ietf.org/mailman/listinfo/alto

Re: [alto] Review of draft-ietf-alto-deployments-08#appendix-A

[Scharf, Michael (Michael)]

Hi Qin,

Sure, we can change the headline of Section 3.4.4 to plural, and remove the 
example of TCP retransmissions.

Would the text below address your comment? ([...] is unchanged to my last 
e-mail).

Thanks

Michael

*

[...]

3.4.2.  Measurement of the Impact

[...]

   o  Application performance: The objective of ALTO is improve
  application performance.  ALTO can be used by very different types
  applications, with different communication characteristics and
  requirements.  For instance, if ALTO guidance achieves traffic
  localization, one would expect that applications achieve a higher
  throughput and/or smaller delays to retrieve data.  If
  application-specific performance characteristics (e.g., video or
  audio quality) can be monitored, such metrics related to user
  experience could also help to analyze the benefit of an ALTO
  deployment.  If available, selected statistics from the TCP/IP
  stack in hosts could be leveraged, too.

[...]

3.4.4.  Monitoring Infrastructures

[...]


> -Original Message-
> From: Qin Wu [mailto:bill...@huawei.com]
> Sent: Tuesday, March 11, 2014 11:28 AM
> To: Scharf, Michael (Michael)
> Cc: IETF ALTO
> Subject: RE: Review of draft-ietf-alto-deployments-08#appendix-A
> 
> Hi, Michael:
> Sorry for late reply.
> As I raised earlier in the ALTO session, it is hard to believe
> We have to use the single monitoring infrastructure or measurement tool
> to measure not only the impact of ALTO but also system performance.
> They could be two different monitoring infrastructures, one is used to
> evaluate
> How alto server affects inter domain traffic and influence the
> application performance while
> The other one is used to measure how powerful the alto server is.
> Sometimes even though the ALTO server is very powerful, however we
> misuse the alto sever, the alto server
> May not help improve traffic optimization and user experience.
> Sometimes measuring the alto sever performance may be equivalent to
> evaluate how alto server influence
> inter-domain traffic if no misusing happen.
> 
> I would suggest to change the title of section 3.4.4
> as follows:
> s/ Monitoring Infrastructure/ Monitoring Infrastructures
> 
> Also I am not sure "the number of retransmitted TCP segments" can be
> used to measure application performance.
> 
> In the 2nd bullet of section 3.4.2, it says:
> "
> For instance, if ALTO guidance achieves traffic
> localization, one would expect that applications achieve a higher
> throughput and/or smaller delays to retrieve data.  Application-
> specific performance characteristics (e.g., video or audio
> quality) can be useful as well.
> "
> It seems two sentences are disconnected. You'd better fix this as well.
> 
> 
> Regards!
> -Qin
> -Original Message-
> From: Scharf, Michael (Michael) [mailto:michael.scharf@alcatel-
> lucent.com]
> Sent: Wednesday, February 26, 2014 4:53 AM
> To: Qin Wu
> Cc: IETF ALTO
> Subject: RE: Review of draft-ietf-alto-deployments-08#appendix-A
> 
> Hi,
> 
> In order to sort out this discussion regarding terminology, I have now
> ...
> 
> 1. Reverted the main headline of the section to what it was in -08 and
> before ("Monitoring ALTO"),
> 
> 2. Aligned the wording with draft-ietf-alto-protocol-26 Section 16.1.4
> and Section 16.2.5, under the assumption that the content and wording
> therein is WG consensus
> 
> 3. Added the desired sentence on third parties and trust issues to
> Section 3.4.1
> 
> 4. Separated the discussion of "impact" and "performance" into two
> sections, as suggested in this thread
> 
> Below is a copy of the updated, pre-10 text.
> 
> Please let me know if I missed something.
> 
> Thanks
> 
> Michael
> 
> 
> *** draft-ietf-alto-deployments-010pre ***
> 
> 
> 3.4.  Monitoring ALTO
> 
> 3.4.1.  Impact and Observation on Network Operation
> 
>ALTO presents a new opportunity for managing network traffic by
>providing additional information to clients.  In particular, the
>deployment of an ALTO Server may shift network traffic patterns, and
>the potential impact to network operation can be large.  An ISP
>providing ALTO may want to assess the benefits of ALTO as part of
> the
>management and operations (cf. [I-D.ietf-alto-protocol]).  For
>instance, the ISP might be interested in understanding whether the
>provided ALTO maps are effective, and in order to decide whether an
>adjustment of the ALTO configuration would be useful.  Such insight
>can be obtained from a monitoring infrastructure.  An NSP offering
>ALTO coul

Re: [alto] re-chartering discussion slides

[Scharf, Michael (Michael)]

> On 03/06/2014 10:00 AM, Adrian Farrel wrote:
> > I am disconcerted by even the mention of RIB. Is the proposal to
> build a "P2P
> > layer RIB" or is the proposal to start to include network layer
> information in
> > ALTO?
> 
> Adrian: The intent it to include some "abstract" network layer
> information in ALTO, more than is now available through the network
> map and cost map constructs, but most certainly not raw topology or RIB
> data.

As original author of this text, I have to back what Vijay explained: I wrote 
that text to explain my understanding of how ALTO differs to other IETF work, 
e.g., I2RS or possibly PCE.

An ALTO client needs network topology information to perform an intelligent 
endpoint selection, in particular if the ALTO client is an IT software 
application that is not tightly integrated into network operation (e.g., a CDN 
mgmt system, a cloud orchestrator, ...). This probably means:

- A ALTO server operator may not be interested in exposing the full routing 
topology, including all internal IGP/BGP configuration details, to such an IT 
application. Specifically, the ALTO client may not be an application operated 
by the network operations team of an ISP, i.e., it is not an NMS plugin or 
something similar. Therefore, for privacy, robustness, and other reasons (e.g., 
corporate policies), the ALTO server would only provide an abstract, 
orchestrated view of what matters for a given client.

- In many use cases, an ALTO client is developed by IT developers without a 
full understanding of routing protocol details. Therefore, it is up to the ALTO 
server to offer a representation that IT developers can understand without 
routing protocol expertise. In my experience, the simplicity of ALTO is a key 
value proposition for such developers.

- draft-ietf-alto-deployments Section 3.2.1 explains how an ALTO server can get 
access to network information. My current understanding is that use of BGP-LS, 
I2RS or other direct interfaces into network elements would possibly require 
that the ALTO server to understands routing protocol details (there are other 
alternatives). Possibly it will have to correlate such data with other data 
sources. But it will be up to the policies in the ALTO server to extract and 
create an abstract topology representation out of this. Obviously, ALTO should 
be flexible to enable the server to express what it wants to expose.

In summary, in my view, an ALTO server exposes a filtered network topology that 
removes all internal, operational network data (including RIB details) that 
does not matter to its clients.

Michael

___
alto mailing list
alto@ietf.org
https://www.ietf.org/mailman/listinfo/alto

Re: [alto] Review of draft-ietf-alto-deployments-08#appendix-A

[Scharf, Michael (Michael)]

Hi,

In order to sort out this discussion regarding terminology, I have now ...

1. Reverted the main headline of the section to what it was in -08 and before 
("Monitoring ALTO"), 

2. Aligned the wording with draft-ietf-alto-protocol-26 Section 16.1.4 and 
Section 16.2.5, under the assumption that the content and wording therein is WG 
consensus

3. Added the desired sentence on third parties and trust issues to Section 3.4.1

4. Separated the discussion of "impact" and "performance" into two sections, as 
suggested in this thread

Below is a copy of the updated, pre-10 text.

Please let me know if I missed something.

Thanks

Michael


*** draft-ietf-alto-deployments-010pre ***


3.4.  Monitoring ALTO

3.4.1.  Impact and Observation on Network Operation

   ALTO presents a new opportunity for managing network traffic by
   providing additional information to clients.  In particular, the
   deployment of an ALTO Server may shift network traffic patterns, and
   the potential impact to network operation can be large.  An ISP
   providing ALTO may want to assess the benefits of ALTO as part of the
   management and operations (cf. [I-D.ietf-alto-protocol]).  For
   instance, the ISP might be interested in understanding whether the
   provided ALTO maps are effective, and in order to decide whether an
   adjustment of the ALTO configuration would be useful.  Such insight
   can be obtained from a monitoring infrastructure.  An NSP offering
   ALTO could consider the impact on (or integration with) traffic
   engineering and the deployment of a monitoring service to observe the
   effects of ALTO operations.  The measurement of impacts can be
   challenging because ALTO-enabled applications may not provide related
   information back to the ALTO Service Provider.

   To construct an effective monitoring infrastructure, the ALTO Service
   Provider should decide how to monitor the performance of ALTO and
   identify and deploy data sources to collect data to compute the
   performance metrics.  In certain trusted deployment environments, it
   may be possible to collect information directly from ALTO clients.
   It may also be possible to vary or selectively disable ALTO guidance
   for a portion of ALTO clients either by time, geographical region, or
   some other criteria to compare the network traffic characteristics
   with and without ALTO.  Monitoring an ALTO service could also be
   realized by third parties.  In this case, insight into ALTO data may
   require a trust relationship between the monitoring system operator
   and the network service provider offering an ALTO service.

   The required monitoring depends on the network infrastructure and the
   use of ALTO, and an exhaustive description is outside the scope of
   this document.

3.4.2.  Measurement of the Impact

   ALTO realizes an interface between the network and applications.
   This implies that an effective monitoring infrastructure may have to
   deal with both network and application performance metrics.  This
   document does not comprehensively list all performance metrics that
   could be relevant, nor does it formally specify metrics.

   The impact of ALTO can be classified regarding a number of different
   criteria:

   o  Total amount and distribution of traffic: ALTO enables ISPs to
  influence and localize traffic of applications that use the ALTO
  service.  An ISP may therefore be interested in analyzing the
  impact on the traffic, i.e., whether network traffic patterns are
  shifted.  For instance, if ALTO shall be used to reduce the inter-
  domain P2P traffic, it makes sense to evaluate the total amount of
  inter-domain traffic of an ISP.  Then, one possibility is to study
  how the introduction of ALTO reduces the total inter-domain
  traffic (inbound and/our outbound).  If the ISPs intention is to
  localize the traffic inside his network, the network-internal
  traffic distribution will be of interest.  Effectiveness of
  localization can be quantified in different ways, e.g., by the
  load on core routers and backbone links, or by considering more
  advanced effects, such as the average number of hops that traffic
  traverses inside a domain.

   o  Application performance: The objective of ALTO is improve
  application performance.  ALTO can be used by very different types
  applications, with different communication characteristics and
  requirements.  For instance, if ALTO guidance achieves traffic
  localization, one would expect that applications achieve a higher
  throughput and/or smaller delays to retrieve data.  Application-
  specific performance characteristics (e.g., video or audio
  quality) can be useful as well.  In addition, selected statistics
  from the TCP/IP stack in hosts can be useful, e.g., the number of
  retransmitted TCP segments.

   Of potential interest can also be the share of applications or

Re: [alto] Text proposal for charter update

[Scharf, Michael (Michael)]

Hi all,

In general, I support fully this. I have some minor suggestions/questions.

>  o (Standards Track) Protocol extensions to convey a richer set of
>attributes to allow applications to determine not only "where" to
>connect but also "when" to connect.  Such additional information
>will be related both to endpoints (e.g. conveying server load and
>cache geo-location information for CDN use cases) and to
>endpoint-to-endpoint costs (e.g. bandwidth calendaring to represent
>time-averaged cost values in datacenter networks).
> 
>The working group will specify such extension in coordination with
>other working groups that are also working on the related use cases
>(e.g. cdni, i2rs, lmap).

While I fully agree that the "when" to connect is a very important use case, I 
would prefer a definition that does not imply that "when" is the only novelty. 
Also, I think it would be better to start with examples that are related to 
(abstract) topology.

For instance, what about:

 o (Standards Track) Protocol extensions to convey a richer set of
   attributes to allow applications an endpoint selection not only based on 
   current network routing cost. This includes guidance not only "where" to
   connect but also "when" to connect. Such additional information
   will be related both to endpoints (e.g. conveying cache geo-location
   or server load information for CDN use cases) and to
   endpoint-to-endpoint costs (e.g. bandwidth calendaring to represent
   time-averaged cost values in datacenter networks).
 
>  o (Informational) A survey of techniques to formalize the structure
>of a network graph (that can derived from a set of related ALTO
>network and cost maps) in a format that would facilitate advanced
>graph computation.  Such survey will cover both models used in
>popular open-source software (e.g. NetworkX, Blueprints) and models
>being considered in other working groups (e.g. netmod, i2rs).

Maybe s/Blueprints/tinkerpop blueprints/ ?

"Blueprints" is not a very specific term.

But perhaps we could just remove the examples - I think we already agree that 
neither NetworkX nor tinkerpop blueprints will completely address our needs.

> After these criteria are met, the importance of the data will be
> considered for prioritizing standardization work, for example the
> number of operators and clients that are likely to be able to provide
> or use that particular data.  In any case, this WG will not propose
> standards on how congestion is signaled, remediated, or avoided, and
> will not deal with information representing instantaneous network
> state.

This sentence is already in the original charter. I am not a native speaker, 
and as a result I wonder about the semantics of "instantaneous", in particular 
regarding the up-to-dateness of the information.

Example: If the ALTO server polls the routing topology routing rather 
frequently (e.g., via BGP-LS), the ALTO maps and guidance can be entirely 
up-to-date, in particular if routing changes only sporadically in a network. To 
me, at least in such a rather static cases, the ALTO maps would then represent 
the "instantaneous" routing state, because the ALTO maps are fully up-to-date. 
Obviously, since ALTO abstracts the maps, it doesn't represent the exact 
routing data - "up-to-date" here implies that the input data used to calculate 
the map has not changed, i.e., any new update and data retrieval would result 
in the same abstracted map.

Wouldn't the phrasing "... and will not deal with information representing 
transient network state" be more appropriate? (Rapid changes are clearly a 
challenge for ALTO and out-of-scope.)

Or, for instance, "... and clients must not assume that the information 
represents instantaneous network state"? (A client cannot know whether the ALTO 
information is really up-to-date.) 

> Milestones

Do we really need separate deadlines for the WGLC? The current ALTO charter 
lists WGLCs as well, so this continues the current way of dealing with WGLC, 
but to me two milestones per planned document seem partly redundant. In TCPM we 
usually only have one milestone for a documents, unless special handling is 
needed. Just as a thought...

Thanks

Michael

___
alto mailing list
alto@ietf.org
https://www.ietf.org/mailman/listinfo/alto

Re: [alto] Review of draft-ietf-alto-deployments-08#appendix-A

[Scharf, Michael (Michael)]

Hi Qui,

inline.

> -Original Message-
> From: Qin Wu [mailto:bill...@huawei.com]
> Sent: Monday, February 17, 2014 9:13 AM
> To: Scharf, Michael (Michael)
> Cc: IETF ALTO
> Subject: RE: Review of draft-ietf-alto-deployments-08#appendix-A
> 
> Hi,Michael:
> Thanks for your clarification, please see my followup comments.
> 
> Regards!
> -Qin
> -Original Message-
> >>From: Scharf, Michael (Michael) [mailto:michael.scharf@alcatel-
> lucent.com]
> >>Sent: Sunday, February 16, 2014 3:55 AM
> >>To: Qin Wu
> >>Cc: IETF ALTO
> >>Subject: RE: Review of draft-ietf-alto-deployments-08#appendix-A
> 
> >>Hi Qin,
> 
> >>Please find some comments inline .
> 
> >>From: Qin Wu [mailto:bill...@huawei.com]
> >>Sent: Saturday, February 15, 2014 4:57 AM
> >>To: Scharf, Michael (Michael)
> >>Cc: IETF ALTO
> >>Subject: RE: Review of draft-ietf-alto-deployments-08#appendix-A
> 
> >>Hi, Michael:
> >>Thanks for re-work and updating to monitoring section.
> >>I have a few comments to section 3.4 you updated.
> >>1. The monitoring infrastructure can be third party,Or can be
> integrated into ALTO server? If it is the third party based, I think
> the trust
> >>relationship between monitoring system and alto server needs to be
> established, otherwise, security concern may be raised.
> 
> 
> >I think the most realistic case it that it is neither third party, nor
> an integrated function of the ALTO server. Instead, a network service
> provider
> >would probably monitor the benefits of its ALTO service by a
> monitoring infrastructure, which could be an extension of the general
> network monitoring
> >OAM. It could be possible that third parties (e.g., academic
> researchers) want to monitor the benefits as well; in that case, there
> is indeed a question
> >whether they would have access to network service provider data beyond
> what the ALTO service provider exposes. However, since the IETF does
> not mandate
> >how to implement an ALTO server, an implementer could obviously also
> come up with a huge all-in-one ALTO server implementation that realizes
> many other
> >functions beyond providing the ALTO service itself.
> 
> >I could add a sentence like "Monitoring the benefits of an ALTO
> service could also be realized by third parties. In this case, insight
> into ALTO data
> >may require a trust relationship between the monitoring system
> operator and the network service provider offering an ALTO service."
> Would this address
> >your comment?
> 
> 
> 
> [Qin]:Yes, thanks.

OK

> >>2.  Section 4.3 says:
> "
> >>An NSP offering ALTO could consider the impact on (or integration
> with) traffic
> >>   engineering and the deployment of a monitoring service to observe
> the
> >>   effects of ALTO operations.
> "
> 
> >>Traffic engineering is related to monitoring ALTO performance? I
> think you may gather traffic engineering information from routing
> protocol, these
> >>traffic engineering information can be used to reflect network
> performance and provide fine granularity of cost map or network map?
> However it has
> >>nothing to do with performance of ALTO?
> >>Performance of ALTO is more about how many request or response can be
> handled,
> 
> 
> >This sentence is taken from Section 16.1.4 of the ALTO protocol spec
> (http://tools.ietf.org/html/draft-ietf-alto-protocol-25#page-81).
> Actually, the
> >whole scope of Section 3.4 in draft-ietf-alto-deployment is explained
> in Section 16.1.4 of the ALTO protocol spec. Given that explanation
> there, I am
> >not sure if I understand your question and/or concern. Specifically,
> the whole section 3.4 of draft-ietf-alto-deployment deals NOT with how
> to retrieve
> >routing protocol information (including e.g. TE information from IGP)
> and how to put it into network and cost maps. This is discussed in
> Section 3.2.1.
> 
> [Qin]: The confusion comes from the title of section 3.4 of draft-ietf-
> alto-deployments-08,i.e.," Monitoring the Performance of ALTO " since
> ALTO performance is more about resource oriented objective, e.g,
> CPU,memory, request/responses to be handled, ALTO performance has
> nothing to do traffic oriented objective.

Well, as I already explained, ALTO expands as Application-layer Topology 
Optimization, which is an abstract concept, not its implementation in a server.

In my understanding the term "Performance of ALTO" is *NOT* the same like 
"Performance of an ALTO server/service", and the te

Re: [alto] Review of draft-ietf-alto-deployments-08#appendix-A

[Scharf, Michael (Michael)]

Hi Qin,

Please find some comments inline .

From: Qin Wu [mailto:bill...@huawei.com] 
Sent: Saturday, February 15, 2014 4:57 AM
To: Scharf, Michael (Michael)
Cc: IETF ALTO
Subject: RE: Review of draft-ietf-alto-deployments-08#appendix-A

Hi, Michael:
Thanks for re-work and updating to monitoring section.
I have a few comments to section 3.4 you updated.
1. The monitoring infrastructure can be third party,Or can be integrated into 
ALTO server? If it is the third party based, I think the trust relationship 
between monitoring system and alto server needs to be established, otherwise, 
security concern may be raised.


I think the most realistic case it that it is neither third party, nor an 
integrated function of the ALTO server. Instead, a network service provider 
would probably monitor the benefits of its ALTO service by a monitoring 
infrastructure, which could be an extension of the general network monitoring / 
OAM. It could be possible that third parties (e.g., academic researchers) want 
to monitor the benefits as well; in that case, there is indeed a question 
whether they would have access to network service provider data beyond what the 
ALTO service provider exposes. However, since the IETF does not mandate how to 
implement an ALTO server, an implementer could obviously also come up with a 
huge all-in-one ALTO server implementation that realizes many other functions 
beyond providing the ALTO service itself.

I could add a sentence like "Monitoring the benefits of an ALTO service could 
also be realized by third parties. In this case, insight into ALTO data may 
require a trust relationship between the monitoring system operator and the 
network service provider offering an ALTO service." Would this address your 
comment? 


2.  Section 4.3 says:
"
An NSP offering ALTO could consider the impact on (or integration with) traffic
   engineering and the deployment of a monitoring service to observe the
   effects of ALTO operations.
"

Traffic engineering is related to monitoring ALTO performance? I think you may 
gather traffic engineering information from routing protocol, these traffic 
engineering information can be used to reflect network performance and provide 
fine granularity of cost map or network map? However it has nothing to do with 
performance of ALTO?
Performance of ALTO is more about how many request or response can be handled,


This sentence is taken from Section 16.1.4 of the ALTO protocol spec 
(http://tools.ietf.org/html/draft-ietf-alto-protocol-25#page-81). Actually, the 
whole scope of Section 3.4 in draft-ietf-alto-deployment is explained in 
Section 16.1.4 of the ALTO protocol spec. Given that explanation there, I am 
not sure if I understand your question and/or concern. Specifically, the whole 
section 3.4 of draft-ietf-alto-deployment deals NOT with how to retrieve 
routing protocol information (including e.g. TE information from IGP) and how 
to put it into network and cost maps. This is discussed in Section 3.2.1.

Let me try to explain how I understand draft-ietf-alto-protocol-25: This 
sentence deals with understanding what impact the ALTO guidance has on 
applications, and whether the ALTO service operation is efficient and 
effectively improving "better-than-random" resource selections by applications. 
I understand here "traffic engineering" in a very general way. For instance, an 
NSP offering an ALTO service for P2P applications would typically expect that 
the amount of aggregated inter-domain traffic is reduced. If ALTO is effective, 
the NSP can probably slow down upgrades of Internet-peering-point capacities; 
this is traffic engineering, but that kind of information may not be carried 
in, or retrieved from routing protocols, and it may not be used to calculate 
ALTO maps. If traffic is kept local in access network domains, the capacity 
planning and traffic engineering of core network links can be adapted, because 
they may have less utilization, e.g., bandwidth allocations of core links could 
be adapt. This can be part of the typical mid-/long-term capacity planning 
processes of a network service provider.

Furthermore, please note the ALTO protocol spec has another section (Section 
16.2.5. Performance Management) that describes examples for system metrics 
characterizing the performance of an ALTO server (e.g., number of requests, 
CPU/memory utilization, etc.).

If you struggle with the term "ALTO performance" in the headline, we could 
perhaps better align the section headlines to draft-ietf-alto-protocol-25, i.e.:

OLD:
3.4. Monitoring the Performance of ALTO
3.4.1. Supervising the Benefits of ALTO
3.4.2. How to Monitor ALTO Performance

NEW:
3.4. Monitoring the Impact of ALTO
3.4.1. Supervising the Benefits of ALTO
3.4.2. How to Observe the Impact of ALTO

Would this address your question?



3. Section 3.4.2 says:
"
Total amount and distribution of traffic: ALTO enables ISPs to
influence

Re: [alto] Review of draft-ietf-alto-deployments-08#appendix-A

[Scharf, Michael (Michael)]

Hi Qin Wu,

The new version of the draft includes an entirely re-written section replacing 
the former appendix A:

http://tools.ietf.org/html/draft-ietf-alto-deployments-09#section-3.4

Please let me know if this does not address your concerns or if you have 
suggestions for improvements.

Thanks

Michael


From: alto [mailto:alto-boun...@ietf.org] On Behalf Of Scharf, Michael (Michael)
Sent: Friday, January 10, 2014 10:43 AM
To: Qin Wu; IETF ALTO
Subject: Re: [alto] Review of draft-ietf-alto-deployments-08#appendix-A

Hi Qin Wu,

Thanks for your feedback. You raise similar issues like a performance 
directorate review of the same part of the document (cf. 
http://www.ietf.org/mail-archive/web/pm-dir/current/msg00610.html).

Addressing this review is still TBD. Version -08 of the draft contains numerous 
other edits, and since I focused on those other parts of the document, I just 
moved this problematic section into appendix A. My thinking (see also the 
slides at the last meeting) is that the current text in appendix A will have to 
be almost completely removed.

I plan to publish -09 before the next meeting, and addressing the performance 
directorate review is a high-priority item. If you have suggestions for 
specific text to be contributed to -09, please let me know.

Thanks

Michael



From: alto [mailto:alto-boun...@ietf.org] On Behalf Of Qin Wu
Sent: Tuesday, December 24, 2013 10:06 AM
To: IETF ALTO
Subject: [alto] Review of draft-ietf-alto-deployments-08#appendix-A

Hi,
I have reviewed appendix A of draft-ietf-alto-deployments-08.
It appear to me this appendix A is outdated and need to be update or separated 
as another draft.
A few comments below:
1. Appendix A paragraph 1 said:
"
In addition to providing configuration, an ISP providing ALTO may
want to deploy a monitoring infrastructure to assess the benefits of
ALTO and adjust its ALTO configuration according to the results of
the monitoring.

"
It looks something is disconnected when we say "in addition to providing 
configuration", where
Configuration providing is discussed in this draft?

Also I think monitoring infrastructure is not limited to assess the benefits of 
ALTO, I think the more important
thing is performance metrics can be injected into ALTO server to provide fine 
granularity of cost map and network map,
alto server can leverage these information to decide which is the best endpoint 
to connect.

2. Appendix ,paragraph 3 said:
"
   [Editor's note: Is there a relationship to the IPPM working group at
   the IETF?]

"
Sure, for most QoS metrics like loss, delay, delay variation, etc.,
standard IPPM definitions exist.  In case such metrics are reported,
the IPPM standard definition should be used.

3. Appendix A.1

Monitoring Metrics is not limited to the list given in the Appendix A.1,
Also it doesn't make sense to enumerate all the performance metrics.

4. Appendix A.2
If you support routing protocol, you can gather peformance metrics from routing 
protocol,
In this case, you don't need to deploy any data source to collect data.

On the other hand, there are many ways in which the performance of an data folw 
can be
monitored.  These include generic MIBs, NetFlow, IP Flow Information Export
(IPFIX),syslog, and so on.

Regards!
-Qin

___
alto mailing list
alto@ietf.org
https://www.ietf.org/mailman/listinfo/alto

[alto] draft-ietf-alto-deployments-09

[Scharf, Michael (Michael)]

Hi all,

I have updated the deployment draft. Specifically, I tried to address the two 
past reviews of the content of the Appendix A ("Monitoring ALTO") and to 
improve several other sections.

Major changes compared to -08:

- New text on data sources for the ALTO server

- CDN use case description completely updated, including some text and figures 
from draft-jenkins-alto-cdn-use-cases-03

- Short new section on using ALTO in VPNs

- Removal of Appendix A (Appendix: Monitoring ALTO), which was flagged in two 
reviews. The replacement is an entirely rewritten Section 3.4.

- Removal of Appendix B (Appendix: API between ALTO Client and Application)


Minor edits:

- Some re-wording in various sections, e.g., in the P2P use case

- Removal of maths in Section 5.2.1

- (Empty) IANA consideration section added

- Additional reference to new ALTO third party discovery draft


Feedback (and text contributions) would be very welcome!

Thanks

Michael



-Original Message-
From: I-D-Announce [mailto:i-d-announce-boun...@ietf.org] On Behalf Of 
internet-dra...@ietf.org
Sent: Thursday, February 13, 2014 6:22 PM
To: i-d-annou...@ietf.org
Cc: alto@ietf.org
Subject: I-D Action: draft-ietf-alto-deployments-09.txt


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
Authors : Martin Stiemerling
  Sebastian Kiesel
  Stefano Previdi
  Michael Scharf
Filename: draft-ietf-alto-deployments-09.txt
Pages   : 52
Date: 2014-02-13

Abstract:
   Many Internet applications are used to access resources such as
   pieces of information or server processes that 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 applications that have to select one or several hosts
   from a set of candidates, which are able to provide a desired
   resource.  This memo discusses deployment related issues of ALTO.  It
   addresses different use cases of ALTO such as peer-to-peer file
   sharing and CDNs, security considerations, recommendations for
   network administrators, and also 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-09

A diff from the previous version is available at:
http://www.ietf.org/rfcdiff?url2=draft-ietf-alto-deployments-09


Please note that it may take a couple of minutes from the time of submission
until the htmlized version and diff are available at tools.ietf.org.

Internet-Drafts are also available by anonymous FTP at:
ftp://ftp.ietf.org/internet-drafts/

___
I-D-Announce mailing list
i-d-annou...@ietf.org
https://www.ietf.org/mailman/listinfo/i-d-announce
Internet-Draft directories: http://www.ietf.org/shadow.html
or ftp://ftp.ietf.org/ietf/1shadow-sites.txt

___
alto mailing list
alto@ietf.org
https://www.ietf.org/mailman/listinfo/alto

Re: [alto] Work items for re-chartering

[Scharf, Michael (Michael)]

rences.

Arbitrary properties can be added.

Paths

No

serial compound links/"ordered list of links"

Yes

No.

Layers

No, but could add a "property" for this.

This seems to be implemented by assigning ports, links, adaptation, and 
switching service all have a "encoding" parameter. Nodes and Topologies do not.


No

No. Can add via a property.

Nodes

Can contain arbitrary data including graphs.

In topology object.

Contained in a "nodes" element.

Contained in nodes list.

Ports

Yes. Contained within nodes.

Yes. have "encoding" parameter, relationship to link.

No.

No. Could add as a node and link property.

Adaptation concept

No. Could add as link property

Yes.

No.

Could add as a link property.




[MS] Good table. But GraphML, OGF NML, and SDNlib are all not JSON. And I think 
that an implicit ordering like in NetworkX JSON is inferior to explicit 
identifiers for edges/vertices.

On 1/28/2014 2:25 AM, Scharf, Michael (Michael) wrote:

Issue 7 of the proposed rechartering effort [0] deals with a suitable

format for encoding graphs in ALTO.  My impression is that there

are two distinct capabilities we are looking for: graph

representation and graph transformation.  The representation part

appears easy enough (I think).



Taking some liberties with the syntax, a coarse JSON GML encoding

can be approximated as follows:



graph [

   node [

  id 0

  label "PID-1"

  address-type "ipv4"

  hosts ""192.0.2.0/24, 198.51.100.0/24"

   ]

   node [

  id 1

  label "PID-2"

  address-type "ipv4"

  hosts ""192.0.2.0/25, 192.0.2.128/25"

   ]

   node [

  id 2

  label "PID-3"

  address-type "ipv4"

  hosts "0.0.0.0/0"

   ]

   edge [

  source 0

  target 1

  value  2

  type  "undirected"

   ]

   edge [

  source 0

  target 2

  value  3

  type  "undirected"

   ]

   edge [

  source 1

  target 2

  value  6

  type  "undirected"

   ]

]



Two questions:



1) Is the encoding above close to what we have been calling the

  "multiple-switch" model?  Is something like this encoding one

possible

  outcome of a work item related to Issue 7?



Yes, at least this is my understanding. GML is, as well as GraphML (XML), 
widely used on open source tools, but both are not JSON based.



An example for a JSON format that available in the well-known tinkerpop open 
source graph processing tool suite would be GraphSON:



https://github.com/tinkerpop/blueprints/wiki/GraphSON-Reader-and-Writer-Library



While I have no preference regarding the specific JSON syntax, I think that we 
look for a "property graph" model. According to 
https://github.com/tinkerpop/blueprints/wiki/Property-Graph-Model,

a property graph has these elements:



a set of vertices

each vertex has a unique identifier.

each vertex has a set of outgoing edges.

each vertex has a set of incoming edges.

each vertex has a collection of properties defined by a map from key to 
value.

a set of edges

each edge has a unique identifier.

each edge has an outgoing tail vertex.

each edge has an incoming head vertex.

each edge has a label that denotes the type of relationship between its 
two vertices.

each edge has a collection of properties defined by a map from key to 
value.





In your GML example, the key question is thus how to deal with the "value" 
property of the edges. Similar to the ALTO maps, I'd argue that an ALTO graph 
must support a default cost metric ("routingcost"), but extensions should be 
possible.





2) The harder part is graph transformation.  What sort of algebraic

  formulations do we expect to turn into protocol primitives that will

  allow us to transform graphs as is outlined in Section 4 of [1]?



[0] http://www.ietf.org/mail-archive/web/alto/current/msg02345.html

[1] http://tools.ietf.org/html/draft-yang-alto-topology-00



Section 4 of [1] contains some pretty advanced concepts. I am not sure if in 
the current re-chartering we should aim at that level of complexity.



In my opinion, a more low-hanging fruit - as a starting point for a discussion 
- would be the question whether ALTO would have protocol primitives to do SPF 
(and CSPF) queries on the graph. That would be an equivalent to the endpoint 
cost service. In my view, there are two alternatives:



a) Corresponding ALTO primitives are specified along with the graph format



b) As a first step, such queries would be left up to the ALTO client, i.e., the 
ALTO server only provides the maps (=graph), but it is up to the ALTO client to 
perform advanced logic using that data



I per

Re: [alto] Work items for re-chartering

[Scharf, Michael (Michael)]

> Issue 7 of the proposed rechartering effort [0] deals with a suitable
> format for encoding graphs in ALTO.  My impression is that there
> are two distinct capabilities we are looking for: graph
> representation and graph transformation.  The representation part
> appears easy enough (I think).
> 
> Taking some liberties with the syntax, a coarse JSON GML encoding
> can be approximated as follows:
> 
> graph [
>node [
>   id 0
>   label "PID-1"
>   address-type "ipv4"
>   hosts ""192.0.2.0/24, 198.51.100.0/24"
>]
>node [
>   id 1
>   label "PID-2"
>   address-type "ipv4"
>   hosts ""192.0.2.0/25, 192.0.2.128/25"
>]
>node [
>   id 2
>   label "PID-3"
>   address-type "ipv4"
>   hosts "0.0.0.0/0"
>]
>edge [
>   source 0
>   target 1
>   value  2
>   type  "undirected"
>]
>edge [
>   source 0
>   target 2
>   value  3
>   type  "undirected"
>]
>edge [
>   source 1
>   target 2
>   value  6
>   type  "undirected"
>]
> ]
> 
> Two questions:
> 
> 1) Is the encoding above close to what we have been calling the
>   "multiple-switch" model?  Is something like this encoding one
> possible
>   outcome of a work item related to Issue 7?

Yes, at least this is my understanding. GML is, as well as GraphML (XML), 
widely used on open source tools, but both are not JSON based. 

An example for a JSON format that available in the well-known tinkerpop open 
source graph processing tool suite would be GraphSON: 

https://github.com/tinkerpop/blueprints/wiki/GraphSON-Reader-and-Writer-Library

While I have no preference regarding the specific JSON syntax, I think that we 
look for a "property graph" model. According to 
https://github.com/tinkerpop/blueprints/wiki/Property-Graph-Model,
a property graph has these elements:

a set of vertices
each vertex has a unique identifier.
each vertex has a set of outgoing edges.
each vertex has a set of incoming edges.
each vertex has a collection of properties defined by a map from key to 
value.
a set of edges
each edge has a unique identifier.
each edge has an outgoing tail vertex.
each edge has an incoming head vertex.
each edge has a label that denotes the type of relationship between its 
two vertices.
each edge has a collection of properties defined by a map from key to 
value.


In your GML example, the key question is thus how to deal with the "value" 
property of the edges. Similar to the ALTO maps, I'd argue that an ALTO graph 
must support a default cost metric ("routingcost"), but extensions should be 
possible.


> 2) The harder part is graph transformation.  What sort of algebraic
>   formulations do we expect to turn into protocol primitives that will
>   allow us to transform graphs as is outlined in Section 4 of [1]?
>
> [0] http://www.ietf.org/mail-archive/web/alto/current/msg02345.html
> [1] http://tools.ietf.org/html/draft-yang-alto-topology-00

Section 4 of [1] contains some pretty advanced concepts. I am not sure if in 
the current re-chartering we should aim at that level of complexity.

In my opinion, a more low-hanging fruit - as a starting point for a discussion 
- would be the question whether ALTO would have protocol primitives to do SPF 
(and CSPF) queries on the graph. That would be an equivalent to the endpoint 
cost service. In my view, there are two alternatives:

a) Corresponding ALTO primitives are specified along with the graph format

b) As a first step, such queries would be left up to the ALTO client, i.e., the 
ALTO server only provides the maps (=graph), but it is up to the ALTO client to 
perform advanced logic using that data

I personally think that b) might be an easier first step for the re-chartering, 
but if somebody comes up with a good ALTO API extension for a), I'd be 
interested in it as well.

Michael

___
alto mailing list
alto@ietf.org
https://www.ietf.org/mailman/listinfo/alto

Re: [alto] Work items for re-chartering

[Scharf, Michael (Michael)]

> -Original Message-
> From: alto [mailto:alto-boun...@ietf.org] On Behalf Of Sebastian Kiesel
> Sent: Monday, January 27, 2014 9:43 AM
> To: Cao,Zhen
> Cc: alto
> Subject: Re: [alto] Work items for re-chartering
> 
> Dear Cao,Zhen,
> 
> On Mon, Jan 27, 2014 at 11:05:45AM +0800, Cao,Zhen wrote:
> > Dear all,
> >
> > I support the above 7 items.
> >
> > In addition, if the group could consider some deployment guide
> > document, it would be more than welcome.
> 
> We are already working on a deployment considerations document:
> 
> http://datatracker.ietf.org/doc/draft-ietf-alto-deployments/
> 
> This document is currently being restructured.  If you think that
> something is missing or if you want to contribute text please send an
> email to the authors and/or the ALTO mailing list.

Indeed, we currently update the deployment document. As usual in the IETF, text 
contributions would be very welcome.

Michael
___
alto mailing list
alto@ietf.org
https://www.ietf.org/mailman/listinfo/alto

Re: [alto] Work items for re-chartering

[Scharf, Michael (Michael)]

I think that all 7 items are important directions for ALTO, and they therefore 
should become charter items. In the WG there are already individual drafts for 
all items. 

My understanding is that re-chartering does not imply that a document has to be 
adopted by the WG immediately in every case. In particular, the milestone dates 
can take into account that some work has already been discussed extensively in 
the WG, whereas other items were mostly covered in side meetings only. 

Michael


> -Original Message-
> From: alto [mailto:alto-boun...@ietf.org] On Behalf Of Vijay K. Gurbani
> Sent: Thursday, January 23, 2014 8:11 PM
> To: alto
> Subject: [alto] Work items for re-chartering
> 
> Folks: Over the last few IETFs, Enrico and I have solicited feedback
> during face-to-face meetings, WG sessions, hallway conversations, ALTO
> mailing list and private conversations on how to move ahead with
> respect
> to adopting new work items.
> 
> As we begin the charter discussions, we have identified seven
> work items to propose as additions to the charter.  The first four of
> these work items are fairly uncontroversial.  The last three are work
> items that have a monumental mind share in the ALTO working group and
> have been found to be extremely useful in controlled networks (e.g.,
> VPNs).  However, we have to take some care in defining these such that
> we do not duplicate the functionality available elsewhere (e.g.,
> general
> routing) in ALTO, nor do we take on an aspect that the working group
> does not fully understand.
> 
> Here are the seven items up for discussion:
> 
> 1. Anycast-based server discovery
> (Presented by Reinaldo Penno in IETF 86 and appears to have
> some support for adoption.)
> 
> 2. Third-party server discovery
> (Sebastian Kiesel et al. have been driving this work and it
> also appears to have support.)
> 
> 3. Incremental ALTO map updates
> (Side meeting held during IETF 86; two proposals have been
> studied.  One way forward is to use an ALTO-specific incremental
> update that may be more efficient, and the second approach is to
> simply use JSON patch.)
> 
> 4. Server-initiated update notifications
> (Jan Seedorf and Enrico Marocco have suggested the use of
> Websockets; HTTP/2.0 may provide some mitigation as well.)
> 
> 5. Extensions to annotate PIDs with properties (e.g., geographical
> locations).
> (Useful as an extension in controlled environments, e.g., VPNs
> where IP addresses are not the only form of identification.
> Some drafts, including draft-roome-alto-pid-properties
> has already started work in this direction.)
> 
> 6. Extensions for cost metrics.
> (Some drafts, including draft-wu-alto-json-te, have started work
> in this direction.)
> 
> 7. An ALTO format for encoding graphs.
> (draft-ietf-alto-protocol already recognizes the need to provide
> topology details that are useful in controlled environments.
> Richard Yang, Greg Bernstein and others have been working on the
> need and use cases for such an encoding.  draft-yang-alto-topology
> is a good start.  Projects like OpenDayLight and NetworkX (Python)
> have JSON models for graph representation.  Some concrete examples
> of how we envision encoding graphs will be useful during list
> discussion.)
> 
> We will like to understand whether the working group believe such
> additional deliverables, if included in an updated charter proposal,
> would allow people to do the extension work that has been repeatedly
> proposed. (Clarification: we are explicitly asking whether people could
> find such an update acceptable. We understand that anyone will have a
> preferred flavor of the above.)
> 
> We are at a point where show of support by whoever is interested is
> essential for moving forward. If it turns out to be positive, Enrico
> and I will subsequently circulate actual text, including milestones,
> for
> a rechartering request.
> 
> Thanks.
> 
> - vijay
> --
> Vijay K. Gurbani, Bell Laboratories, Alcatel-Lucent
> 1960 Lucent Lane, Rm. 9C-533, Naperville, Illinois 60563 (USA)
> Email: vkg@{bell-labs.com,acm.org} / vijay.gurb...@alcatel-lucent.com
> Web: http://ect.bell-labs.com/who/vkg/  | Calendar: http://goo.gl/x3Ogq
> ___
> alto mailing list
> alto@ietf.org
> https://www.ietf.org/mailman/listinfo/alto
___
alto mailing list
alto@ietf.org
https://www.ietf.org/mailman/listinfo/alto

Re: [alto] Review of draft-ietf-alto-deployments-08#appendix-A

[Scharf, Michael (Michael)]

Hi Qin Wu,

Thanks for your feedback. You raise similar issues like a performance 
directorate review of the same part of the document (cf. 
http://www.ietf.org/mail-archive/web/pm-dir/current/msg00610.html).

Addressing this review is still TBD. Version -08 of the draft contains numerous 
other edits, and since I focused on those other parts of the document, I just 
moved this problematic section into appendix A. My thinking (see also the 
slides at the last meeting) is that the current text in appendix A will have to 
be almost completely removed.

I plan to publish -09 before the next meeting, and addressing the performance 
directorate review is a high-priority item. If you have suggestions for 
specific text to be contributed to -09, please let me know.

Thanks

Michael



From: alto [mailto:alto-boun...@ietf.org] On Behalf Of Qin Wu
Sent: Tuesday, December 24, 2013 10:06 AM
To: IETF ALTO
Subject: [alto] Review of draft-ietf-alto-deployments-08#appendix-A

Hi,
I have reviewed appendix A of draft-ietf-alto-deployments-08.
It appear to me this appendix A is outdated and need to be update or separated 
as another draft.
A few comments below:
1. Appendix A paragraph 1 said:
"
In addition to providing configuration, an ISP providing ALTO may
want to deploy a monitoring infrastructure to assess the benefits of
ALTO and adjust its ALTO configuration according to the results of
the monitoring.

"
It looks something is disconnected when we say "in addition to providing 
configuration", where
Configuration providing is discussed in this draft?

Also I think monitoring infrastructure is not limited to assess the benefits of 
ALTO, I think the more important
thing is performance metrics can be injected into ALTO server to provide fine 
granularity of cost map and network map,
alto server can leverage these information to decide which is the best endpoint 
to connect.

2. Appendix ,paragraph 3 said:
"
   [Editor's note: Is there a relationship to the IPPM working group at
   the IETF?]

"
Sure, for most QoS metrics like loss, delay, delay variation, etc.,
standard IPPM definitions exist.  In case such metrics are reported,
the IPPM standard definition should be used.

3. Appendix A.1

Monitoring Metrics is not limited to the list given in the Appendix A.1,
Also it doesn't make sense to enumerate all the performance metrics.

4. Appendix A.2
If you support routing protocol, you can gather peformance metrics from routing 
protocol,
In this case, you don't need to deploy any data source to collect data.

On the other hand, there are many ways in which the performance of an data folw 
can be
monitored.  These include generic MIBs, NetFlow, IP Flow Information Export
(IPFIX),syslog, and so on.

Regards!
-Qin

___
alto mailing list
alto@ietf.org
https://www.ietf.org/mailman/listinfo/alto

Re: [alto] extension questions and comments

[Scharf, Michael (Michael)]

Hi Greg,

Sorry, I was on vacation, thus a late reply marked by [MSC].

> Hi ALTO extension folks, as I'll not be making it up to Vancouver :-( , here 
> are some questions/comments.
> These comments/questions are from the perspective of creating an ALTO 
> topology service (suitable for large bandwidth and SDN applications).
> http://tools.ietf.org/html/draft-scharf-alto-vpn-service-01 
> ALTO for VPNs: Way back when we started talking about "topology" like 
> extensions. The concept of ALTO for "controlled or partially controlled" 
> environments was floated. It seems that a VPN type of service would be the 
> exemplar of such an environment and hence pave the way for "restricted 
> environment" use of ALTO.  Questions:  Are there specific additions to the 
> REST API to offer this some kind of security, i.e., to keep others from 
> gaining information about a customers VPN? Or would a general approach to 
> security of this interface be specified?

[MSC] Yes, indeed, the exposure of a VPN topology from the network service 
provider to the VPN customer is a much more controlled environment than use of 
ALTO in the public Internet.

draft-scharf-alto-vpn-service-01 basically argues in favor of running one ALTO 
server instance for each VPN customer, protected by authentication and 
authorization mechanisms (e.g. HTTPS-based). In simple use cases we currently 
believe that the existing ALTO REST interface is sufficient from a security 
perspective, e.g., as long as we use the vanilla map or ECS services for a 
simple L3VPN. But I am not a security expert.

Access control may get more complicated e.g. if the same customer runs several 
VPNs, if there is multi-homing, etc. We have not fully analyzed the security 
implications of more complex VPN use cases.

Also, there are further subtle differences between public Internet and VPNs. 
For instance, unlike in the public Internet, a VPN customer knows (or at least 
could know) some basic properties of the topology that the ALTO server would 
expose. For instance, a customer could know what VPN endpoints exists, and 
there is no need for topology abstraction regarding endpoints. As a result, 
some of the ISP privacy concerns typical for the public Internet might not 
apply to VPNs. For instance, an ISP might be more willing to expose 
fine-granular ALTO maps of a VPN. But there are also new challenges. For 
instance, if a VPN offers SLA guarantees, a customer could try to use ALTO 
guidance to audit SLA compliance of the network service provider. But in my 
current understanding this mostly affects the information that the ALTO server 
exposes, not the REST interface itself.

Finally, keep in mind that one of the key differences between public Internet 
and VPNs is the use of identifiers. An IP address may not be the only or not 
the best way to address a VPN endpoint. This certainly has implications on the 
ALTO REST interface, but not necessarily regarding security.

My 2 cents...

Michael
___
alto mailing list
alto@ietf.org
https://www.ietf.org/mailman/listinfo/alto

[alto] Section number references from draft-ietf-alto-protocol to draft-ietf-alto-deployments

[Scharf, Michael (Michael)]

Hi all,

As I already mentioned in the last IETF meeting, I suggest that 
draft-ietf-alto-protocol does not refer to specific section numbers of 
draft-ietf-alto-deployments. The numbers referenced by 
draft-ietf-alto-protocol-20 are already outdated for 
draft-ietf-alto-deployments-08, and further updates of the deployment draft are 
likely (see below for one example).

Specifically, I suggest to remove this tight coupling by the following small 
changes:

OLD:
Section 10 of [I-D.ietf-alto-deployments] also discusses information leakage 
from ALTO.

NEW:
[I-D.ietf-alto-deployments] also discusses information leakage from ALTO.


OLD:
Note that ALTO-specific monitoring and metrics are discussed in 6.3 of 
[I-D.ietf-alto-deployments] and future versions of that document.

NEW:
Note that ALTO-specific monitoring and metrics are discussed in 
[I-D.ietf-alto-deployments].


OLD:
Both ALTO Service Providers and those using ALTO Clients should be aware of the 
impact of incorrect or faked guidance (see Section 10.3 of 
[I-D.ietf-alto-deployments] and future versions of that document).

NEW:
Both ALTO Service Providers and those using ALTO Clients should be aware of the 
impact of incorrect or faked guidance (see [I-D.ietf-alto-deployments]).


OLD:
Monitoring ALTO Servers and Clients is described in Section 6.3 of 
[I-D.ietf-alto-deployments] and future versions of that document.

NEW:
Monitoring ALTO Servers and Clients is described in [I-D.ietf-alto-deployments].


(The phrase "... and future versions of that document" could also stay.)


As discussed on the list, a performance directorate review asked for 
substantial changes of Section 6.3, which is explicitly references multiple 
times. According to this review, the content of Section 6.3 will have to change 
significantly before publication. 

Note that I moved the existing text from Section 6.3 in 
draft-ietf-alto-deployments-07 into an appendix in 
draft-ietf-alto-deployments-08, because I didn't have time to rewrite this part 
of the document (-08 contains numerous other improvements). Probably, -09 will 
have a reworded, dedicated section on monitoring in the main part again, but 
the section number is TBD.

Thanks

Michael
___
alto mailing list
alto@ietf.org
https://www.ietf.org/mailman/listinfo/alto

[alto] draft-ietf-alto-deployments-08

[Scharf, Michael (Michael)]

Hi all,

I submitted a new version of draft-ietf-alto-deployments. I changed the naming 
of some sections and also shifted text inside the document to have a more 
consistent structure, and this is why the diff shows a large number of changes. 
However, I hardly removed any content from the document. Basically, the 
intention of -08 is to have a baseline for future improvements of the content.

The major changes in -08 include:

* ToC naming changes

* New text in Section 2.2.3. More Advanced Deployments

* Existing text on data sources moved from later sections to Section 3.2 
Provisioning of ALTO Maps

* Significant rewording of Section 3.4. Map Examples for Different Types of 
ISPs, including a small network and cost map example for illustration

* New section 6 for non-P2P and non-CDN use cases, currently only addressing 
draft-deng-alto-p2pcache (requested by the authors), further use cases still TBD

* Moving "Monitoring ALTO" to an Appendix. I have not managed to address the 
performance directorate review so far, but probably this section will have to 
be removed in its current form

* Numerous editorial bugfixes

It is obvious that further updates is needed and will happen - I just posted 
what I could get done before the deadline. Comments would still be very welcome.

Thanks

Michael



-Original Message-
From: i-d-announce-boun...@ietf.org [mailto:i-d-announce-boun...@ietf.org] On 
Behalf Of internet-dra...@ietf.org
Sent: Monday, October 21, 2013 7:10 PM
To: i-d-annou...@ietf.org
Cc: alto@ietf.org
Subject: I-D Action: draft-ietf-alto-deployments-08.txt


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
  Michael Scharf
Filename: draft-ietf-alto-deployments-08.txt
Pages   : 44
Date: 2013-10-21

Abstract:
   Many Internet applications are used to access resources such as
   pieces of information or server processes that 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 applications that have to select one or several hosts
   from a set of candidates, which are able to provide a desired
   resource.  This memo discusses deployment related issues of ALTO.  It
   addresses different use cases of ALTO such as peer-to-peer file
   sharing and CDNs, security considerations, recommendations for
   network administrators, and also 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-08

A diff from the previous version is available at:
http://www.ietf.org/rfcdiff?url2=draft-ietf-alto-deployments-08


Please note that it may take a couple of minutes from the time of submission
until the htmlized version and diff are available at tools.ietf.org.

Internet-Drafts are also available by anonymous FTP at:
ftp://ftp.ietf.org/internet-drafts/

___
I-D-Announce mailing list
i-d-annou...@ietf.org
https://www.ietf.org/mailman/listinfo/i-d-announce
Internet-Draft directories: http://www.ietf.org/shadow.html
or ftp://ftp.ietf.org/ietf/1shadow-sites.txt
___
alto mailing list
alto@ietf.org
https://www.ietf.org/mailman/listinfo/alto

[alto] "Running code" for draft-scharf-alto-vpn-service

[Scharf, Michael (Michael)]

Hi all,

This links refers to an EWSDN workshop presentation showing a prototype of 
draft-scharf-alto-vpn-service: 
http://www.ewsdn.eu/presentations/Presentations_2013/2013-10-10_ewsdn_Scharf.pdf

The corresponding paper will hopefully appear soon in IEEExplore. 

The prototype uses Wendy's ALTO server and currently only handles L3VPN. As 
discussed in the draft, other VPN types would need ALTO extensions.

Thanks

Michael

___
alto mailing list
alto@ietf.org
https://www.ietf.org/mailman/listinfo/alto

[alto] Duplicate entries in resource directory?

[Scharf, Michael (Michael)]

Hi all,

draft -14 states regarding multiple entries in the directory:
   
   It is possible that multiple entries in the directory match a desired
   Information Resource.  For instance, in the example in Section 7.6.3,
   a full Cost Map with "numerical" Cost Mode and "routingcost" Cost
   Type could be retrieved via a GET request to
   "http://alto.example.com/costmap/num/routingcost";, or via a POST
   request to "http://custom.alto.example.com/costmap/filtered";.

Is my understanding correct that a directory response with duplicate entries 
for the exactly same service (including the same cost mode etc.) is allowed as 
well?

Example for network map:

   HTTP/1.1 200 OK
   Content-Length: 1472
   Content-Type: application/alto-directory+json

   {
 "resources" : [
   {
 "uri" : "http://alto.example.com/networkmap";,
 "media-types" : [ "application/alto-networkmap+json" ]
   },
   {
 "uri" : "http://alto2.example.com/alternative/networkmap,
 "media-types" : [ "application/alto-networkmap+json" ]
   }
 ]
   }

We just wonder what an ALTO client should do if it gets such a response - 
probably it would pick a random URI. This could actually achieve some simple 
load balancing.

Thanks

Michael
___
alto mailing list
alto@ietf.org
https://www.ietf.org/mailman/listinfo/alto

Re: [alto] The size of the cost map

[Scharf, Michael (Michael)]

> > Unfortunately, if the matrix ISN'T sparse, that technique 
> is horribly 
> > inefficient. If the matrix is full, the client should convert pid 
> > names to index numbers (sort the PID names, use binary 
> search to get 
> > the index), and then store the costs in a conventional 
> float[N][N] array.
> 
> Could this be done on the fly while reading the JSON data 
> structures from the network? ...

Is there an existing JSON parser libary that supports such "on-the-fly" parsing 
(stream-like)?

The libraries I have looked at so far typically parse a buffer with the whole 
JSON data. 
 
> > And, of course, that technique is wasteful for a sparse cost matrix.
> > 
> > So the client has to guess how "sparse" the cost matrix really is.
> 
> ... or do I have to read all the JSON stuff into a temporary 
> buffer, then decide whether to go for a hash or an array. If 
> the array, do pid name -> index mapping, identify the highest 
> index, allocate array and eventually fill it? That would be 3 
> passes or more?

Out of my head, I'd think that multiple passes will be needed when using 
standard JSON libraries. Obviously, an ALTO implementation can implement own 
JSON parsing logic, but we'd better not assume this.

Michael
___
alto mailing list
alto@ietf.org
https://www.ietf.org/mailman/listinfo/alto

Re: [alto] Error codes in ALTO

[Scharf, Michael (Michael)]

Coming back to this, after some research...

> -Original Message-
>   I also would like not to replicate and, for the sake of 
> discussion, say, return (-1) or bytes read to the ALTO layer.
> 
>   But the current status is more complicated. We already 
> have a mixed bag of things crossing layers. 
> 
>   We already replicate ALTO error codes into HTTP 
> (ALTO->HTTP direction)
>   
>   "   The HTTP status codes corresponding to each ALTO 
> Error Code are
>  defined to provide correct behavior with HTTP 
> intermediaries and
>  clients.  When an ALTO Server returns a particular 
> ALTO Error Code,
>  it MUST indicate one of the corresponding HTTP 
> status codes in 
>   Table 1 in the HTTP response. "
> 
> Right.  So one other way would be to not specify this, and 
> leave it up to servers to pick an HTTP status that seems 
> reasonable.  The general idea here was "make sure we still 
> get reasonable behavior when we talk through intermediaries", 
> but if there are better ways to handle this than that would be great.

A reasonable design of an ALTO (client) implementation separates HTTP 
processing from the ALTO protocol engine. The former is mostly a generic HTTP 
instance (e.g., interfacing the well-known curl library), while the latter 
realized the ALTO message parsing etc. In normal operation, both "layers" are 
mostly independent.

However, the RESTful design requires that ALTO error messages have to be 
handled both in the HTTP layer as well as in the ALTO layer. Specifically, the 
HTTP layer will have to decide based on the HTTP error code whether to pass a 
response to the ALTO layer for further ALTO error message processing, whether 
to do something else, or whether to consider the query as an entire failure. 
That distinction is much simpler if the implementor knows the HTTP error codes 
that require further processing not only by the HTTP logic, but also by the 
ALTO logic.

Thus, for interoperability it seems indeed useful that the ALTO protocol spec 
exactly defines the HTTP error codes for any ALTO error type (i.e., error code 
400 in spec -14). I don't see a good reason to change that - it would make the 
HTTP logic in an ALTO implementation more complex and less interoperable, 
because the implementor of a client has to guess what a server might return.

=> Spec -14 seems fine regarding that detail.


>   And we ask clients to interpret HTTP status codes  
> (HTTP->ALTO direction)
>   
>   "  o  Return an HTTP 503 ("Service Unavailable") status 
> code to the ALTO
> Client.  As indicated by [RFC2616 
>  ], a the Retry-After HTTP header
> may be used to indicate when the ALTO Client 
> should retry the
> request."
> 
> Yes.  I tend to disagree with having this statement in here 
> for exactly the reasons you point out, but it was added after 
> AD feedback saying it was needed to meet the ALTO requirements.

In addition to error HTTP 400, the ALTO spec right now further requires special 
actions on HTTP 503 ("Service Unavailable") and HTTP 307 ("Temporary Redirect") 
status codes.

For HTTP 307, the ALTO spec must exactly define whether the redirection URI 
provides the same resource type, or whether it is possibly different (e. g., it 
could be the resource directory of another server with other maps). From an 
implementation perspective, both variants are very different. In the former 
case, the HTTP library can internally realize the redirect (e. g., using 
CURLOPT_FOLLOWLOCATION in the curl library); this is probably the simpler 
variant because it is totally transparent. Alternatively, the redirection has 
to be handled by the ALTO logic, which is more heavyweight. Both variants are 
possible, but an implementor must know whether to activate automatic redirect 
support in HTTP libraries such as curl, or not. 

=> The ALTO spec must specify exactly what type of URI HTTP 307 returns.

For HTTP 503, my current understanding is that an automatic "retry-after" is 
not supported by several HTTP libraries or clients, i. e., an ALTO 
implementation will possibly have to implement the retry timer etc. on its own. 
Still, it seems reasonable to me to rely on a standard HTTP error code for 
that. The motivation is as follows: If more HTTP libraries support this error 
code internally in future, this would at least simplify the design of future 
ALTO implementations.

=> Using HTTP error code 503 as in spec -14 seems reasonable to me.

Michael
___
alto mailing list
alto@ietf.org
https://www.ietf.org/mailman/listinfo/alto

Re: [alto] Security problem: DoS attacks via overload

[Scharf, Michael (Michael)]

> 13.5.2.  Protection Strategies
> 
>ALTO Provider should be cognizant of the workload at the 
> ALTO Server
>generated by certain ALTO Queries, such as certain queries 
> to the Map
>Service, the Map Filtering Service and the Endpoint Cost (Ranking)
>Service.  One way to limit Denial-of-Service attacks is to employ
>access control to the ALTO Server.  The ALTO Server can 
> also indicate
>overload and reject repeated requests that can cause availability
>problems.

One could also explicitly add the term "(request) rate limit"; I think that 
this is used e. g. to protect control plane protocols.

For instance: "One way to limit Denial-of-Service attacks is to employ access 
control or request rate limits to the ALTO Server."

There is probably no comprehensive DoS protection solution, though.

Michael
___
alto mailing list
alto@ietf.org
https://www.ietf.org/mailman/listinfo/alto

Re: [alto] minor inconsistency in draft 14

[Scharf, Michael (Michael)]

> My understanding of the decision that an ALTO Server must 
> provide "routingcost" is also related with the design of 
> allowing default. For example, CostMapCapability can be empty 
> and implies "routingcost". One analogy one might or may not 
> like is that TLS (RFC5246) defines that 
> TLS_RSA_WITH_AES_128_CBC_SHA is mandatory. But we can imagine 
> that there is no mandatory and hence allows TLS negotiation 
> to fail. But I agree with you that removing the so far MUST 
> supported cost type and endpoint property will not impact 
> interop in the sense that the protocol still works, and a 
> conforming ALTO Server may just not returning any 
> information. What do you and others think?

Another option would be to replace the term "routingcost" by something that 
does not specifically refer to a way how to determine that cost. For instance, 
"defaultcost"?

But I don't have a strong preference here.

Michael
___
alto mailing list
alto@ietf.org
https://www.ietf.org/mailman/listinfo/alto

Re: [alto] Security

[Scharf, Michael (Michael)]

One small comment below

> -Original Message-
> From: alto-boun...@ietf.org [mailto:alto-boun...@ietf.org] On 
> Behalf Of Richard Alimi
> Sent: Wednesday, March 13, 2013 6:33 AM
> To: Hannes Tschofenig
> Cc: alto@ietf.org
> Subject: Re: [alto] Security

[...]

> The draft also has this text in the Manageability 
> Considerations section:
> 
> 
> 
>Operators providing an ALTO Server should ensure that appropriate
>information is being exposed.  Privacy implications for ISPs are
>discussed in Section 13.1 
>  n-13.1> .  Both operators and ALTO Servers and those
>using ALTO Clients should be aware of the impact of incorrect or
>faked guidance (see Section 10.3 of 
> [I-D.ietf-alto-deployments 
>  D.ietf-alto-deployments> ] and
>future versions of that document).
> 
> As far as attacking the discovery mechanism, yes an attacker 
> may wish to do that.  I believe that something that should be 
> addressed in the server-discovery document (and its security 
> considerations) but not in the protocol document.

Section 6.1 http://tools.ietf.org/html/draft-ietf-alto-server-discovery-07 has 
some text on this attack. One could refer to that from the protocol draft 
security considerations.

Michael
___
alto mailing list
alto@ietf.org
https://www.ietf.org/mailman/listinfo/alto

Re: [alto] ALTO vs ssl/tls

[Scharf, Michael (Michael)]

> >> For server authentication, TLS imposes four costs.  
> >> 
> >> Three are trivial: the amount of CPU usage for key exchange,
> > 
> > Plus potential handshake delay - note that an ALTO query 
> could be part of a latency-sensitive operation, and ALTO 
> server and clients could be geographically distributed.
> 
> In that case, add 2 network RTTs on the connection setup for 
> the handshake.

In the world of signaling protocols (and, yes, ALTO can be seen as a signaling 
protocol), two RTTs can be a lot.
 
> And hold the connection open, both costs (CPU and handshake 
> latency) are only on connection establishment, so they should 
> only affect the first query, not subsequent queries.

This assumes that the ALTO client can maintaining a pool of persistent 
connections, that the HTTP server has enough resources to keep these 
connections open, etc. All this is about software engineering. I don't think 
that the ALTO base document should enforce specific ways how an ALTO client or 
server is designed internally.

> Finally, if you are so latency sensitive that you can't 
> handle the extra 2 RTTs of network latency on connection 
> establishment, do a protocol over DNS with DNSSEC validation, 
> because that can get you single RTT 
> cryptographically-authenticated query/response (if you also 
> do a parallel query for the DS and DNSKEY RRSETs so you have 
> all the cryptographic data at the same time.  You can also 
> safely fall back to "DNS with no DNSSEC" if on a broken 
> network which is blocking DNSSEC and the protocol is only 
> used for host discovery, not key exchange.).

ALTO is a protocol that provides am IT-friendly, RESTful network interface that 
can easily be integrated in whatever application. I doubt that many app 
developers would consider DNSSEC a reasonable alternative to HTTP/REST.

> >> But TLS offers a huge advantage:  Proxies abound, and HTTP proxies 
> >> even moreso.  The result is there are an amazing number of network 
> >> devices which think they are smarter than the traffic, but 
> well, they 
> >> aren't.  E.g. half of the in-path HTTP caches cache data 
> incorrectly.  
> >> Cellphone networks now experience image transcoding, etc.
> > 
> > Why would such proxies be relevant if the ALTO client and 
> the ALTO server run on two high-end servers inside the same 
> data center rack, with a dedicated and isolated 1 or 10 
> Gbit/s network link in between them?
> 
> And in that model, there is NO cost for TLS because you do 
> the connection establishment once and the cost disappears.
> 
> > ALTO is a generic protocol. It can be deployed in very 
> different ways.
> 
> 
> At the same time, without at least #2, you are in huge 
> trouble if there exists some supposedly "smart" middlebox
> 
> There are NATs that inject responses into HTTP traffic, as 
> well as ISPs.  There are transcoding proxies that convert 64 
> kB images into 4 kB blobs that would display poorly on a 
> commodore 64.  There are web proxies that contain 3 year old! 
> vulnerabilities.  If its possible for an HTTP middlebox to 
> screw up traffic in some way, there probably is a deployed 
> middlebox that does it already.
> 
> 
> ALTO is something new, and if you really want it to work 
> reliably, in as many contexts as possible, ESPECIALLY over 
> port 80, you must account for the middleboxes.  
> 
> And the way to account for the middleboxes is to require 
> support for TLS on port 443, so that the middleboxes are 
> forced to go "hands off".
> 
> And once you mandate support for TLS, what reason is there to 
> not always use it?

I think that the root cause for this discussion is that we talk here about 
*very* different deployment cases.

I agree that TLS could help if a residential user runs an the ALTO client 
behind a broken middlebox, if this is what you care about. If that helps, I am 
fine with adding some recommendation in the base protocol spec that recommends 
enabling of TLS when the ALTO server is accessed by residential users (even 
though this might much better fit into the ALTO deployment draft).

But I disagree that this is the only relevant deployment scenario for the base 
protocol. And I strongly believe that we should not mandate what an ALTO server 
operator has to write into his configuration file.

Michael
___
alto mailing list
alto@ietf.org
https://www.ietf.org/mailman/listinfo/alto

Re: [alto] ALTO vs ssl/tls

[Scharf, Michael (Michael)]

> For server authentication, TLS imposes four costs.  
> 
> Three are trivial: the amount of CPU usage for key exchange, 

Plus potential handshake delay - note that an ALTO query could be part of a 
latency-sensitive operation, and ALTO server and clients could be 
geographically distributed.

> the cost for a certificate (GoDaddy claims $6/year), and the 
> need to use a distinct IP for the hostname if you can't 
> support Server Name Identification.  
> 
> One is real: making sure you don't screw up on installing and 
> rolling the certificate.
> 
> Both #2 and #3 have the same cost.
> 
> 
> But TLS offers a huge advantage:  Proxies abound, and HTTP 
> proxies even moreso.  The result is there are an amazing 
> number of network devices which think they are smarter than 
> the traffic, but well, they aren't.  E.g. half of the in-path 
> HTTP caches cache data incorrectly.  Cellphone networks now 
> experience image transcoding, etc.

Why would such proxies be relevant if the ALTO client and the ALTO server run 
on two high-end servers inside the same data center rack, with a dedicated and 
isolated 1 or 10 Gbit/s network link in between them?

ALTO is a generic protocol. It can be deployed in very different ways.

Michael


> If you want to avoid the headaches caused by these 
> too-smart-for-their-own-good middleboxes, you have to use TLS 
> on port 443, its just about the only port and protocol thats 
> unmolested by the network.
> 
> For client authentication, TLS is a pain.  But it depends on 
> context: if its new program to server, TLS client 
> authentication is no worse than ANY other authentication 
> mechanism, as you still have the exchange/pairing problem no 
> matter what.  If its User to Server, its an utter abominable failure.
___
alto mailing list
alto@ietf.org
https://www.ietf.org/mailman/listinfo/alto

Re: [alto] ALTO vs ssl/tls

[Scharf, Michael (Michael)]

> > Having said this, I could imagine that a "MUST" for TLS for 
> the ALTO 
> > base protocol spec could avoid IESG pushback from the security area.
> > If so, I think a statement similar to IPFIX would be useful.
> 
> This isn't a topic to avoid IESG pushback, it is rather a 
> topic of having a protocol that allows secured deployments 
> across an untrusted network. And it should be up to the 
> operator of the server to decide how much security is needed.
> 
> This is currently reflected in the draft (-14).

For what it is worth, the exact phrasing in -14 confuses me: "An ALTO Server 
MUST support SSL/TLS [RFC5246] to implement server and/or client 
authentication, encryption, and/or integrity protection."  I could read this in 
a way that the ALTO server MUST announce all services on HTTPS URIs, and this 
is certainly not what we want. (And, having "and/or" in a MUST statement might 
not be perfect.)

If the consensus is the MUST, I'd at least prefer Sebastian's wording: "Any 
ALTO implementation MUST support SSL/TLS [RFC5246]".

Michael
___
alto mailing list
alto@ietf.org
https://www.ietf.org/mailman/listinfo/alto

Re: [alto] ALTO vs ssl/tls

[Scharf, Michael (Michael)]

Hi all,

> Further, there are a number of large services, e.g., to name 
> a few Google Maps, Facebook, etc, that use TLS by default and 
> the apps and the server haven't melted down.

I don't think that major web sites are a good criteria.

If so, we should have a look at the security requirements of protocols somehow 
related to ALTO. For instance a quick check results in (not all references are 
standards-track, and I am no expert for those protocols):

* RFC 4743 (NETCONF over SOAP over HTTP) states "At a miniumum, all conforming 
NETCONF over SOAP implementations MUST support TLS".

* RFC 5810 for ForCES has a "SHOULD" for TLS or IPsec

* RFC 3989 and RFC 4540 mandate either TLS or IPsec

* RFC 5101 for IPFIX has a "MUST" for TLS if TCP is the transport, but Section 
11.5 states (somehow contradicting the former):  "The use of DTLS or TLS might 
not be possible in some cases due to performance issues or other operational 
concerns. Without TLS or DTLS mutual authentication, IPFIX Exporting Processes 
and Collecting Processes can fall back on using IP source addresses to 
authenticate their peers. [...] Again, completely segregating IPFIX traffic on 
a dedicated network, where possible, can improve security even further."

The first three examples are configuration protocols that inherently have 
higher security requirements than ALTO. The last example is similar to ALTO a 
network export protocol, even though with a different use case and not running 
over HTTP.

I think that there are use cases of ALTO where "performance issues or 
operational concerns" similar to IPFIX can occur, e. g., if the ALTO client and 
the ALTO server are interconnected over a dedicated physical network to 
accommodate a potentially very high ALTO query load.

Having said this, I could imagine that a "MUST" for TLS for the ALTO base 
protocol spec could avoid IESG pushback from the security area. If so, I think 
a statement similar to IPFIX would be useful.

Michael






___
alto mailing list
alto@ietf.org
https://www.ietf.org/mailman/listinfo/alto

Re: [alto] ALTO vs ssl/tls

[Scharf, Michael (Michael)]

All,

>From a high-level perspective, I think there are three different aspects:

1) ALTO client may want to confirm that ALTO server is not spoofed.

2) ALTO servers may want to authenticate clients to ensure that only allowed 
clients get guidance.

3) ALTO servers may want that communication is encrypted, since ALTO 
information is possibly sensitive


At first sight, these three goals seem orthogonal to me. For instance:

1) This requirement may not be a significant issue of an ALTO server discovery 
method is used that is tightly coupled with the access network, because 
spoofing the discovery result is then pretty difficult. In such cases, the 
additional protection by TLS/SSL seems limited.

2) For guidance of unstructured P2P networks, this seems unrealistic with any 
credential-based method. In my opinion, it is more likely that the ALTO server 
will be protected by firewalls that only allow intra-domain access. For P2P 
tracker guidance, client authentication might be possible for a well-defined 
number of P2P systems. It also seems possible that an ALTO server could expose 
more detailed maps to well-known users than to random P2P clients. Client 
authentication is certainly very relevant for many non-P2P use cases.

3) This depends on whether client and server communicate over a possibly 
untrusted network. For instance, if ALTO client and server are in the same 
physical network, encryption is not a major issue. Also, if the ALTO maps are 
very simple and provide simple information only (e. g., inside-AS vs. 
outside-AS address ranges), encryption might not be needed even if ALTO clients 
are spread over the whole Internet.


In summary, I think there are several cases where enabling of TLS/SSL is not 
really needed. Also, I might be wrong, but if an operator only has requirement 
2), maybe HTTP authentication (RFC 2617) without using TLS/SSL encryption would 
be just sufficient.

Michael



> -Original Message-
> From: alto-boun...@ietf.org [mailto:alto-boun...@ietf.org] On 
> Behalf Of Martin Stiemerling
> Sent: Tuesday, March 05, 2013 5:14 PM
> To: Roome, W D
> Cc: alto@ietf.org
> Subject: Re: [alto] ALTO vs ssl/tls
> 
> Wendy,
> 
> would a 'MUST implement TLS/SSL' fix your concern? This does 
> say that the implementation must have it, but it does not 
> preclude to use it, e.g., if you operate the ALTO server in 
> your data center only.
> 
>Martin
> 
> On 03/05/2013 04:39 PM, Wendy Roome wrote:
> > Richard,
> >
> > Your proposal sounds fine. After all, it's a "motherhood" 
> statement. 
> > Who could argue with, "If you need security, etc, use ssl/tls."?
> >
> > However, I am surprised by the suddenly perceived need for 
> security, 
> > and I'd object to anything that implies that the default is 
> to use ssl/tls.
> > I think that will kill the protocol. I'd always thought 
> that ALTO was 
> > primarily intended to be a public service that network operators 
> > provide to all applications, not an exclusive service 
> available only 
> > to a few trusted components. A network operator would 
> provide a public 
> > ALTO service because it benefits the operator as well as 
> the client. 
> > Sure, some operators might restrict access, but most 
> wouldn't bother. 
> > A few
> > observations:
> >
> > * An ALTO server just returns a limited view of the network 
> > statistics. It's not like it gives out launch codes or 
> banking data, 
> > or allows a client to change anything. Why is it so 
> important to keep 
> > that data secret? Especially if a server can use ordinal mode to 
> > obscure the details?
> >
> > * The only use case in draft 14 is a P2P tracker. By 
> definition, P2P 
> > trackers are distributed & anarchistic, and can be run by any Tom, 
> > Dick or Sally. I don't think it's practical to authenticate 
> thousands 
> > of P2P tracker clients. Besides, most tracker operators wouldn't 
> > hesitate to post their ALTO authentication credentials on 
> the web. :-)
> >
> > * I can see why an ALTO client might want to authenticate 
> the server, 
> > to prevent spoofing. Although that begs the question of why someone 
> > would bother to spoof an ALTO server -- how would they benefit?
> >
> > - Wendy Roome
> >
> > From: "Y. Richard Yang" mailto:y...@cs.yale.edu>>
> > Date: Mon, March 4, 2013 14:35
> > To: Bill Roome  > >
> > Cc: "Reinaldo Penno (repenno)"  > >, "alto@ietf.org "
> > mailto:alto@ietf.org>>
> > Subject: Re: [alto] ALTO vs ssl/tls
> >
> > Hi Wendy,
> >
> > The context of the change is the following AD Review:
> >
> > " What security mechanism to use in what scenario. The 
> considerations 
> > elaborate on the use of SSL/TLS, but it is not clear when 
> to use it. 
> > In general, it seems to be really good, at least by today, 
> to mandate 
> > the use of HTTPS in almost any scenario where the traffic crosses a 
> > publicly available infrastructure, e.g., the general I

Re: [alto] Current status and a way forward for ALTO

[Scharf, Michael (Michael)]

Enrico, all,

I've read -14. Please find below my thoughts on the open questions.

> - get acquainted with the issues that have been discussed since the
>   previous meeting, including (in no particular order):
> o reason phrase for error messages;

I find the arguments against strings somehow convincing.

> o relative vs. absolute URIs;

I don't care; others have commented on that already a lot.

> o behavior of degenerated map filtering;

Both behaviors seem reasonable, and I am fine either way. One reason in favor 
of returning empty maps could be their size: We know that ALTO maps can be very 
large, i. e., the server could return many megabytes of data for a query that 
is not really well-specified. But this is not a strong argument, given that 
ALTO maps can be large anyway, and the client has to be prepared for that. 

> o merge of cost-mode and cost-type in a single type;

In my understanding, the difference between numerical and ordinal costs is 
minor, and the former can mostly emulate the latter. But given that this has 
been in the spec for a long time, I don't see an urgent need to change that.

> o format of endpoint properties;

Allowing generic json values seems important for potential future extensions.

> o mandatory vs. optional services;

Regarding that question, -14 looks fine to me as it is. The services of a 
server will also depend on the ALTO use case, and I don't think we should 
mandate too much in the base protocol spec.

Thanks

Michael
___
alto mailing list
alto@ietf.org
https://www.ietf.org/mailman/listinfo/alto

Re: [alto] new individual document notification

[Scharf, Michael (Michael)]

Hi Enrico, all,

I fully agree that the relationship between I2RS and ALTO requires careful 
thinking, because possibly guidance to the I2RS WG is needed. This is a timely 
topic, and I thank the authors of draft-song-alto-i2rs to bring this to the 
attention of the working group.

However, I wonder whether draft-song-alto-i2rs is a useful starting point for 
this discussion. Please find my concerns on the technical content below. I 
understand that this document is at an early stage, but in my opinion it is 
still not heading in the right direction.


Title, Abstract, Introduction, and Terminology
--

The title, abstract, and the introduction are fairly generic. While the acronym 
I2RS is never expanded in the text, and any reference is missing, I assume here 
that the new I2RS working group is implied implicitly. As far as I understand 
the planned work in I2RS, this new IETF working group discusses specific 
interactions with the Internet routing system. Apart from a short text in 
Section 4, draft-song-alto-i2rs-01 does not discuss I2RS specifically.


Section 3.1
---

The following section seems interesting, but I fail to see an actual 
contribution:

   An ALTO server needs the following information as input:

   o The network segments information.  Every access router manages one
   or more IP address pools, to be assigned to the users through DHCP or
   other ways."

What is the difference between "network segment information" and entries in 
"routing tables" (next bullet)? The IP address pools will have to used in 
routing as well. Does the document suggest an interface between I2RS and a 
RADIUS server? That would probably have to be discussed in the I2RS WG, I don't 
know if this is foreseen there.

   o The IP addresses of the interfaces of routers, and the routing
   table information(IGP or BGP).  This o information can help to
   construct the whole network topology.

Yes, but I2RS is not needed for that. See for instance 
draft-ietf-idr-ls-distribution.

Also, note that an ALTO server almost certainly does not want to expose IP 
addresses of routers or router interfaces, as explained e. g. in 
draft-scharf-alto-vpn-service-00.

   o The congestion status of the router interfaces, but this
   information could be reflected in the routing table change

I think it has always been consensus that ALTO will not expose short-term 
"congestion" status. From draft-ietf-alto-protocol-14: "Recall that while ALTO 
may convey dynamic network information, it is not intended to replace 
near-real-time congestion control protocols."

Under the assumption that congestion here implies "long-term" interface 
utilization, this text would have to distinguish whether it refers to the load 
on the interfaces to each individual residential user, on the Internet-facing 
interfaces, etc. The latter seems to be closer related to 
draft-amante-i2rs-topology-use-cases-00 than the former, but I might be wrong. 
Note that congestion status towards a residential user could depend on the 
traffic class (e. g., different congestion status for Internet access vs. IPTV) 
and many other parameters.

   o Policy information, for example, one multi-homing AS prefers to use
   which AS to transit its traffic, including the pricing information.

Agreed on the first points, this is what I2RS seems to be all about. I am 
curious how to retrieve pricing information from the routing system.


Section 3.2
---

This section is closely related to draft-lee-alto-ext-dc-resource. I don't see 
how that whole section matters to I2RS or ALTO. More specifically:

   The ALTO server needs to collect the following information so as to
   provide this kind of service.

   o All switches' network capacity information

Unless I miss something, I2RS addresses routers, not switches.

   o All physical servers' information(CPU, memory) in the data center

And this will be retrieved from the Internet routing system? How?

   o The storage space information in the data center

Same here?

   o The physical links information

Inside the data center one often has L2/Ethernet connectivity, i.e., no routing 
system. Apart from that detail, what link information specifically?

   o The virtual machines' information(CPU, memory) and its affinity

Same as above.

   o Pricing models

Again, I don't see the relation to I2RS for that.

   Based on the previous informaiton, ALTO server can provide the load
   balancing/traffic optimization informaiton to ALTO client for data
   centers, through map or ranking.

In summary, this list is to a large extend not about networking, and unrelated 
to I2RS, as far as I understand it. What do I miss?


Section 4
-

   So there could be two ways to go forward.

   (1) Defining a new protocol for all the functions(configuration and
   disclosure) required by I2RS.  This protocol covers ALTO's south
   bound information requirements on network topology, with 

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

[Scharf, Michael (Michael)]

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

Re: [alto] Discussion II: Unifying cost-mode and cost-type to a single type

[Scharf, Michael (Michael)]

> I appreciate the observations related to cost and believe 
> some discussion is warranted but some observations:
> 
> - Lower is better is mostly what you get in routers. For 
> example, OSPF has a well defined metric but you can import 
> BGP routes into OSPF (and
> vice-versa) with default or different metrics. You can add 
> static routes, changes preferences, etc.
> 
> An ALTO Server is no different. It needs to take inputs from 
> different sources and come up with a cost metric.

Yes. One can indeed use different input sources...

> If we need
> to define what cost means I suggest we take the definition 
> from routing folks (for example, ref PCE/BGP). Do they have 
> one? For example, if I dump the forwarding table of a router 
> and it shows that for a certain destination the cost is "50" 
> through a certain interface,  what can I infer from it given 
> the mash of different inputs a router can take to calculate that?

... and there may be input metrics other than BGP/OSPF/... routing cost.

> - Different ALTO Servers might be a problem if they are in 
> different domains. ALTO servers within a single domain that 
> need to exchange cost maps need to use the same algorithms.
> 
> - Different ALTO servers in different domains in another 
> issue. This was an issue we worked on:
> 
> https://tools.ietf.org/html/draft-penno-alto-cdn-03#page-17
> 
> I believe implementations just use BGP cost.

While BGP cost is certainly a very relevant input parameter, we've shown an 
implementation that can also calculate the ALTO cost e.g. from delay (Section 
IV.C): http://dx.doi.org/10.1109/ICIN.2012.6376038

How to calculate the cost value really depends on the requirements and policies 
of the ALTO server operator.

Michael
___
alto mailing list
alto@ietf.org
https://www.ietf.org/mailman/listinfo/alto

Re: [alto] Discussion II: Unifying cost-mode and cost-type to a single type

[Scharf, Michael (Michael)]

> On the other hand, there are many other cost types (or 
> "rating criteria", as the ALTO requirements document RFC 6708 
> calls them), where an exact specification how to compute and 
> how to encode them makes sense, e.g.:
> 
> - draft-scharf-alto-vpn-service-00  talks about publishing the
>   geographical location of a data center using ALTO. How excatly
>   do we encode longitude/latitude?   This might fit into two lines
>   of text directly in the IANA registry.

For what it is worth (slightly off-topic in this thread): Approximate 
geographic location is already explicitly mentioned in the ALTO charter 
("Initially the WG will consider: IP ranges to prefer and to avoid, ranked 
lists of the peers requested by the client, information about topological 
proximity and approximate geographic locations.").

IMHO, regarding geographical locations, draft-scharf-alto-vpn-service-00 just 
suggests something that the charter already mentions.

Michael

___
alto mailing list
alto@ietf.org
https://www.ietf.org/mailman/listinfo/alto

[alto] New ALTO draft: draft-scharf-alto-vpn-service-00

[Scharf, Michael (Michael)]

Hi all,

This draft discusses the use of ALTO in VPNs, such as L3VPNs and L2VPNs.

The document includes several potential use cases, a list of (new) requirements 
that seem specific to VPNs, as well as a gap analysis when using the base ALTO 
protocol. This draft does not suggest a specific solution right now. Our 
understanding is that it is important to first analyze what problems have to be 
solved when ALTO shall be used in VPN environments.

Feedback would be highly welcome!

Thanks

Michael


-Original Message-
From: i-d-announce-boun...@ietf.org [mailto:i-d-announce-boun...@ietf.org] On 
Behalf Of internet-dra...@ietf.org
Sent: Thursday, February 14, 2013 12:34 PM
To: i-d-annou...@ietf.org
Subject: I-D Action: draft-scharf-alto-vpn-service-00.txt


A New Internet-Draft is available from the on-line Internet-Drafts directories.


Title   : The Virtual Private Network (VPN) Service in ALTO: 
Use Cases, Requirements and Extensions
Author(s)   : Michael Scharf
  Vijay K. Gurbani
  Greg Soprovich
  Volker Hilt
Filename: draft-scharf-alto-vpn-service-00.txt
Pages   : 19
Date: 2013-02-14

Abstract:
   The Application-Layer Traffic Optimization (ALTO) protocol is
   designed to allow entities with knowledge about the network
   infrastructure to export such information to applications that need
   to choose one or more resources from a candidate set.  This document
   provides motivation for using ALTO in a Virtual Private Network (VPN)
   environment.  We discuss use cases, requirements, and possible
   extensions to the base ALTO protocol that will be needed to support
   VPN services.


The IETF datatracker status page for this draft is:
https://datatracker.ietf.org/doc/draft-scharf-alto-vpn-service

There's also a htmlized version available at:
http://tools.ietf.org/html/draft-scharf-alto-vpn-service-00


Internet-Drafts are also available by anonymous FTP at:
ftp://ftp.ietf.org/internet-drafts/

___
I-D-Announce mailing list
i-d-annou...@ietf.org
https://www.ietf.org/mailman/listinfo/i-d-announce
Internet-Draft directories: http://www.ietf.org/shadow.html or 
ftp://ftp.ietf.org/ietf/1shadow-sites.txt
___
alto mailing list
alto@ietf.org
https://www.ietf.org/mailman/listinfo/alto

Re: [alto] S-NAPTR? (Was: [internet-dra...@ietf.org: I-D Action: draft-ietf-alto-server-discovery-07.txt]

[Scharf, Michael (Michael)]

Stephane,

Earlier versions explicitly had a reference to RFC 3958, explaining that ALTO 
discovery requires an URI as output.

RFC 3958 states: "The expected output of this Application is the information 
necessary for a client to connect to authoritative server(s) (host, port, 
protocol) for a particular application service within a given domain."

That seems to prevent returning an URI as needed by ALTO, right?

Thanks

Michael



> -Original Message-
> From: alto-boun...@ietf.org [mailto:alto-boun...@ietf.org] On 
> Behalf Of Stephane Bortzmeyer
> Sent: Wednesday, January 23, 2013 10:43 AM
> To: Sebastian Kiesel
> Cc: alto@ietf.org
> Subject: [alto] S-NAPTR? (Was: [internet-dra...@ietf.org: I-D 
> Action: draft-ietf-alto-server-discovery-07.txt]
> 
> On Thu, Jan 17, 2013 at 11:27:42AM +0100,  Sebastian Kiesel 
>  wrote  a message of 67 lines which said:
> 
> > this new version of the ALTO server discovery draft is based on the 
> > feedback we got during WGLC.
> 
> I know it's late but I still have a question: why using 
> U-NAPTR when S-NAPTR (RFC 3958) would be sufficient?
> 
> Both examples in the draft -07 use no left-hand part in the 
> regexp (and I do not see what could be used for this part) 
> and therefore would work with S-NAPTR.
> 
> I find zero discussion on this issue in the archives of the 
> mailing list.
> ___
> alto mailing list
> alto@ietf.org
> https://www.ietf.org/mailman/listinfo/alto
> 
___
alto mailing list
alto@ietf.org
https://www.ietf.org/mailman/listinfo/alto

Re: [alto] [apps-discuss] Simple Web Discovery (SWD) Enabling Hosted Deployments

[Scharf, Michael (Michael)]

Diego, all,

I won't give further pushback, even if I don't agree to quite a number of your 
statements. Just one further example to explain why SWD won't solve all 
problems: Even if we replace U-NAPTR by HTTP(S), according to RFC 5986, the 
ALTO client still needs access to DHCP options, which is yet another 
non-HTTP(S) interface to care about.

For what it is worth, I am convinced both a DNS-based and a HTTP(S) solution 
can be engineered, each with pros and cons. Yet, the former variant is much 
better understood in the IETF, and I fail to see a fundamental benefit of SWD 
that would compensate this.

In order to move forward, if this helps to sort this issue, I think that we 
could add a non-normative section to the current draft (or, better, an 
appendix) that discusses an alternative HTTP-based discovery, in case that such 
a solution gets widely used in future. It could for instance summarize pros and 
cons according to this e-mail thread, and leave it up to a future document to 
standardize this variant (possible, after the mechanism is better worked out in 
the IETF). It is pretty clear anyway that the current ALTO discovery 
specification does not address all possible use cases of ALTO (cf. third party 
discovery).

Any thoughts on that proposal?

Michael
___
alto mailing list
alto@ietf.org
https://www.ietf.org/mailman/listinfo/alto

Re: [alto] [apps-discuss] Simple Web Discovery (SWD) Enabling Hosted Deployments

[Scharf, Michael (Michael)]

Diego, 

> Hi Michael,
> 
> On 9 Nov 2012, at 20:53 , Scharf, Michael (Michael) wrote:
> > U-NAPTR application service tags are registered with IANA, 
> and that is what the current ALTO discovery draft does.
> >
> > I wonder how and where ALTO would register its URI if it 
> were using draft-jones-simple-web-discovery for discovery. 
> Probably in new IANA registry?
> >
> > Such questions would probably have to be sorted out 
> elsewhere in the IETF before ALTO discovery could rely on 
> draft-jones-simple-web-discovery.
> 
> Hmmm, I think you have a point here. But I'll investigate 
> whether there is a URN namespace associated with DNS names, 
> so an URI built according to current registration could be 
> directly used.

My main point is that this has to be sorted out e. g. in APPAREA before we can 
rely on an RFC in that space. It is unclear to me whether 
draft-jones-simple-web-discovery will be a mature and widely used technique any 
time soon.
 
> > I don't really understand your argument regarding the 
> client. The ALTO client has to perform DNS queries anyway, i. 
> e., DNS is not a new protocol on the client side.
> 
> Indeed, but my take is that the client relies on DNS in an 
> indirect way, by requesting HTTP(S) connections that use DNS 
> to parse the URL, but not directly accessing the DNS 
> interface. Therefore, using HTTP(S) again would be the most 
> natural way to perform discovery.

Sure, a HTTP(S) discovery mechanisms has benefits in a Web world. But DNS also 
has benefits. There is an engineering tradeoff.

Thus, I disagree that HTTP(S) is the "most natural way".

> > However, my impression is that 
> draft-jones-simple-web-discovery could result in quite some 
> complexity on the server side. My understanding of the 
> proposal is that, if applied to ALTO, an access network 
> provider would have to run a Web server for each access 
> network domain names announced in the DHCP option according 
> to RFC 5986. I could imagine that this results in quite some 
> operational issues for an ISP:
> >
> > - Today, an operator might not run Web servers for domain 
> names such as "dsl.westcoast.myisp.net", i. e., this might 
> require a new server infrastructure. Compared to that, the 
> DNS infrastructure already exists and just has to be extended 
> by entries.
> 
> Deploying virtual Web servers is a rather trivial task (in a 
> typical Apache setup, we are talking about adding a few lines 
> to configuration files), and you need Web servers anyway to 
> run the ALTO base protocol

My concern is that RFC 5986 announces an access network domain name, such as 
"dsl.westcoast.myisp.net".

In my understanding, draft-jones-simple-web-discovery requires that a Web 
server is running at 
https://sl.westcoast.myisp.net/.well-known/simple-web-discovery . Furthermore, 
unless I miss something, there is no need for an DNS entry that maps 
"dsl.westcoast.myisp.net" to specific host right now.

Thus, for draft-jones-simple-web-discovery to work with RFC 5986, an ISP might 
have to add new DNS entries for each access network domain name, pointing to a 
Web server, that then figures out the closest ALTO server URI. With U-NAPTR, 
the DNS server just gives the closest ALTO server URI directly. 

In summary:

- Both variants are likely to require new DNS entries
- draft-jones-simple-web-discovery requires one more indirection, i. e., one 
more system to configure, and one more system that has to be aware of the 
network topology to figure out the closest ALTO server, etc.

Obviously, an alternative would be to specify a new DHCP option that directly 
announces the URI of the SWD Web Server. That is not very different to a DHCP 
option that just encodes the ALTO server URI. This is all doable, at least in 
principle. But the approach of encoding URIs in DHCP got pretty strong pushback 
in previous ALTO meetings, as far as I recall.

> > - There may be synchronization issues, e. g. in case of 
> domain mame renumbering, because different databases have to 
> be kept in sync. Right now, for ALTO discovery to work well, 
> an ISP may have to keep DHCP and DNS in sync, which are both 
> well-established network services. With 
> draft-jones-simple-web-discovery, a third Web infrastructure 
> has to be taken into account.
> 
> Again, this maintenance is straightforward, since it is 
> related to dealing with virtual servers in any modern Web 
> server framework. It is more a matter of which branch in an 
> organization has access to DHCP, DNS, and Web servers for 
> infratsructural matters. My point is that DNS is usually the 
> most hard to change, due to it being a critical service for 
> many others.

My point is that ALTO server discovery has

Re: [alto] [apps-discuss] Simple Web Discovery (SWD) Enabling Hosted Deployments

[Scharf, Michael (Michael)]

Diego,

> As I understand it, the proposal does not intend to keep a 
> registry of the URIs used for discovery (it is a parameter 
> for a query using HTTP GET) and, therefore, ALTO could 
> mandate its own URI, in the same way the U-NAPTR lookup 
> defines the string to be queried.
> 
> The requirements on external registrations are essentially 
> the same in both cases (none, I think).

U-NAPTR application service tags are registered with IANA, and that is what the 
current ALTO discovery draft does.

I wonder how and where ALTO would register its URI if it were using 
draft-jones-simple-web-discovery for discovery. Probably in new IANA registry?

Such questions would probably have to be sorted out elsewhere in the IETF 
before ALTO discovery could rely on draft-jones-simple-web-discovery.

> My point is that an 
> ALTO client would have to rely only in queries aligned with 
> the rest of the transport protocol, i.e.
> plain HTTP(S), and not be required to include support for 
> specific DNS queries.

I don't really understand your argument regarding the client. The ALTO client 
has to perform DNS queries anyway, i. e., DNS is not a new protocol on the 
client side.

However, my impression is that draft-jones-simple-web-discovery could result in 
quite some complexity on the server side. My understanding of the proposal is 
that, if applied to ALTO, an access network provider would have to run a Web 
server for each access network domain names announced in the DHCP option 
according to RFC 5986. I could imagine that this results in quite some 
operational issues for an ISP:

- Today, an operator might not run Web servers for domain names such as 
"dsl.westcoast.myisp.net", i. e., this might require a new server 
infrastructure. Compared to that, the DNS infrastructure already exists and 
just has to be extended by entries.

- There may be synchronization issues, e. g. in case of domain mame 
renumbering, because different databases have to be kept in sync. Right now, 
for ALTO discovery to work well, an ISP may have to keep DHCP and DNS in sync, 
which are both well-established network services. With 
draft-jones-simple-web-discovery, a third Web infrastructure has to be taken 
into account.

- I could imagine that load balancing mechanisms and strategies for DNS could 
be quite different from Web load balancing, also taking into account HTTP 
proxies etc. ALTO discovery requires that a topologically close server is 
discovered. The DNS infrastructure is a network service and thus somehow linked 
to topology, unlike a Web platform.

Right now, all the points are speculation. It might be doable to engineer an 
ALTO discovery solution based on draft-jones-simple-web-discovery, if it 
becomes an IETF standard. But, as of now, I don't really understand what the 
benefit would be for ALTO.

Michael
___
alto mailing list
alto@ietf.org
https://www.ietf.org/mailman/listinfo/alto

Re: [alto] Fwd: [apps-discuss] Simple Web Discovery (SWD) Enabling Hosted Deployments

[Scharf, Michael (Michael)]

Hi all,

After briefly scanning through draft-jones-simple-web-discovery, which seems to 
be an individual draft, I wonder how the ALTO service would be registered in 
this solution. The text states: "The definition of URIs used to identify 
principals and services are outside the scope of this specification." If such 
issues are not clear as of now, it is unclear to me whether this is indeed a 
mature technology.

At first sight, compared to that, the U-NAPTR lookup is a well-understood 
mechanism used by other IETF protocols with similar requirements like ALTO.

Michael





Von: alto-boun...@ietf.org [alto-boun...@ietf.org] im Auftrag von Diego R. 
Lopez [di...@tid.es]
Gesendet: Mittwoch, 7. November 2012 21:29
An: alto@ietf.org
Betreff: [alto] Fwd: [apps-discuss] Simple Web Discovery (SWD) Enabling Hosted 
Deployments

Hi,

This is the recent proposal being orginated inside the OpenIDConnect community 
I mentioned at the mike that
could be useful for not requiring an U-NAPTR lookup.

I think it is worth considering as an alternative way for ALTO server 
discovery, since it provides a
simple and  coherent interface (based on HTTP GET) for this purpose.

Be goode,

Begin forwarded message:

From: "Paul E. Jones" mailto:pau...@packetizer.com>>
Subject: [apps-discuss] Fwd: FW: Simple Web Discovery (SWD) Enabling Hosted 
Deployments
Date: 5 November 2012 08:44:11.000 EST
To: mailto:apps-disc...@ietf.org>>

FYI


From: Mike Jones 
mailto:michael.jo...@microsoft.com>>
Sent: Mon Nov 05 07:55:14 EST 2012
To: "Paul E. Jones" mailto:pau...@packetizer.com>>
Subject: FW: Simple Web Discovery (SWD) Enabling Hosted Deployments

Paul, could you do me a favor and forward this note to the apps-discuss list so 
people have context on why I updated SWD?  For some reason, the list doesn’t 
appear to be accepting my message.

Thanks,
-- Mike

From: Mike Jones
Sent: Sunday, November 04, 2012 9:21 PM
To: apps-disc...@ietf.org
Subject: Simple Web Discovery (SWD) Enabling Hosted Deployments

I’ve updated the Simple Web Discovery 
(SWD) 
specification to incorporate a means of performing discovery on domains for 
which it may not be possible to create a .well-known endpoint.  This can often 
be the case for hosted domains, where it is common for e-mail to be provided 
but no web server.  This solution was developed in discussions by the OpenID 
Connect working group.

This draft is being published now to facilitate discussions of the need to 
enable discovery for hosted domains and possible solutions for doing so at the 
IETF Applications Area working group meeting at IETF 85 in 
Atlanta.

The updated specification is available at:

•http://tools.ietf.org/html/draft-jones-simple-web-discovery-04

Changes made were:
•Specified that the SWD server for a domain may be located at the 
simple-web-discovery subdomain of the domain and that SWD clients must first 
try the endpoint at the domain and then the endpoint at the subdomain.
•Removed the SWD_service_redirect response, since redirection can be 
accomplished by pointing the simple-web-discovery subdomain to a different 
location than the domain's host.
•Removed mailto: from examples in favor of bare e-mail address syntax.
•Specified that SWD servers may also be run on ports other than 443, 
provided they use TLS on those ports.

An HTML formatted version is available at:

•http://self-issued.info/docs/draft-jones-simple-web-discovery-04.html

(This notice was also posted to http://self-issued.info/?p=891.)

-- Mike

___
apps-discuss mailing list
apps-disc...@ietf.org
https://www.ietf.org/mailman/listinfo/apps-discuss


--
"Esta vez no fallaremos, Doctor Infierno"

Dr Diego R. Lopez
Telefonica I+D
http://people.tid.es/diego.lopez/

e-mail: di...@tid.es
Tel:+34 913 129 041
Mobile: +34 682 051 091
-




Este mensaje se dirige exclusivamente a su destinatario. Puede consultar 
nuestra política de envío y recepción de correo electrónico en el enlace 
situado más abajo.
This message is intended exclusively for its addressee. We only send and 
receive email on the basis of the terms set out at:
http://www.tid.es/ES/PAGINAS/disclaimer.aspx
___
alto mailing list
alto@ietf.org
https://www.ietf.org/mailman/listinfo/alto

Re: [alto] ALTO discovery in roaming scenario

[Scharf, Michael (Michael)]

Haibin,

> OK. Then how about using your and Sebastian's suggested 
> general statement about using the client's communication IP 
> address, and highlight proxy based with one or two sentences?

This looks like a reasonable idea. 

> I'm not convinced that we should ignore the scenarios when 
> the above sentences cannot work. Maybe we can give guidance 
> in the document, that there could be exceptions and using the 
> text about triangle routing from my original email as an 
> example. Then we do not go to every exceptions in mobility. 
> I'm not familiar with all the mobility technologies, but some 
> will not impact ALTO discovery such as HIP which is a 3.5 
> layer technology.  Does that make sense and look like a 
> simple way to handle it in the draft?

The draft has to be updated anyway, given the feedback in the last meeting. 
Certainly, triangular routing can be mentioned as an example for a specific 
challenge.

As a side note: AFAIK, HIP decouples the application and the IP stack, i. e., 
the application may not easily know what IP address is actually used by the 
protocol stack (there may be work-arounds, of course). I guess that this could 
actually be a quite significant obstacle for ALTO if an app needs the IP 
address to get ALTO guidance. Anyway, I think that this should be out-of-scope.

Michael
___
alto mailing list
alto@ietf.org
https://www.ietf.org/mailman/listinfo/alto

Re: [alto] ALTO discovery in roaming scenario

[Scharf, Michael (Michael)]

Haibin, 

> I would answer "yes" to the first two questions you raised. 

Well, I disagree with both, but I am willing to learn from real-world data.

> It is easy to generalize the mobile and proxy based scenarios 
> I raised, or even generalize the whole document into only one 
> short paragraph such like "find the resource consumer's 
> domain name, then use the U-NAPTR method with the new defined 
> service tag...", if we do not go to the details. 

As I mentioned before, there is a quite a number of IETF protocols providing 
mobility (in a somehow loose sense):

- Proxy Mobile IP
- Mobile IPv4 (MIPv4)
- Mobile IPv6 (MIPv6)
- Hierarchical Mobile IPv6 (HMIPv6)
- NEMO
- SHIM6
- HIP
- LISP (partly)
- ...

Do you argue that we have to go into technical details for all of them? Do you 
plan to write that text?

Or do you argue that MIPv4 (which your suggested text apparently assumes) is 
the only relevant protocol that ALTO discovery has to consider in details?

Note that the current draft already has text on mobility and NAT, unlike for 
instance RFC 5986. I agree that in addition to NAT, proxies should be 
mentioned. And we should indeed highlight that
the IP address that is used for communication actually matters, in particular 
also in mobility scenarios.

But beyond that, I really wonder how you want to specify in detail how to deal 
with the wide variety of mobility and proxy solutions known in the IETF. This 
could end up in an endless story.

Michael
___
alto mailing list
alto@ietf.org
https://www.ietf.org/mailman/listinfo/alto

Re: [alto] ALTO discovery in roaming scenario

[Scharf, Michael (Michael)]

I might be wrong, but I think that this description is specific to a network 
that uses "mobile IP". It misses the differences between "mobile IPv4" and 
"mobile IPv6" (different realization of triangular routing, foreign agent, 
etc.).

I don't think that adding text specific to selected mobility mechanisms is the 
right approach for this draft. For instance, mobile networks can instead use 
"proxy mobile IP". In that case, a mobile node has no two addresses as 
described in your text. And there are many other existing proposals for 
mobility mechanisms for IP (hierarchical mobility, network mobility, etc.). We 
should not start to discuss technical details of proposed IP mobility solutions 
in an ALTO draft, imho.

I think that all those use cases can simply be summarized by:  "In general, the 
ALTO server discovery should be based on the IP address that is used to 
communicate with other peers".

Right?

Michael


> -Original Message-
> From: Songhaibin [mailto:haibin.s...@huawei.com]
> Sent: Friday, June 29, 2012 11:28 AM
> To: Scharf, Michael (Michael)
> Cc: alto@ietf.org
> Subject: RE: [alto] ALTO discovery in roaming scenario
>
> Sorry for the late reply.
>
> Here is a little text I proposed to add:
>
> " A mobile node has two addresses - a permanent home address
> and a care-of address (CoA), which is associated with the
> network the mobile node is visiting. When acting as
> transmitter, a mobile node sends packets directly to the
> other communicating node, without sending the packets through
> the home agent, using its permanent home address as the
> source address for the IP packets. This is known as
> triangular routing. In this case, the ALTO server discovered
> by the CoA would be used to get the transmission guidance.
> However, it still uses the ALTO server discovered by its home
> address or home agent address to get guidance to retrieve
> content from content sources in the network.
>
> The foreign agent could also employ reverse tunneling by
> tunneling the mobile node's packets to the home agent, which
> in turn forwards them to the communicating node. This is
> needed in networks whose gateway routers check that the
> source IP address of the mobile host belongs to their subnet
> or discard the packet otherwise. In this case, the ALTO
> server discovered by the mobile node's home address or home
> agent address would always be the right choice.
>
> If an end host uses proxy to access the network, such as in a
> company which uses VPN tunnels to connect different
> sub-divisions in different locations, the proxy IP address
> should be used for the ALTO server discovery instead of the
> end host's IP address.
>
> In general, according to the data path, the client's IP
> address/agent's IP address which directly connect and route
> the client's data to/from Internet should be used for the
> correspondence ALTO server discovery."
>
> Does this make sense?
>
> -Haibin
>
> > -Original Message-
> > From: Scharf, Michael (Michael)
> > [mailto:michael.sch...@alcatel-lucent.com]
> > Sent: Thursday, June 21, 2012 4:18 PM
> > To: Songhaibin
> > Cc: alto@ietf.org
> > Subject: RE: [alto] ALTO discovery in roaming scenario
> >
> > Haibin,
> >
> > Can you please explain how the scenario you describe is
> different to a
> > normal NAT middlebox?
> >
> > Regarding NAT, the draft right now states that there are various
> > methods to find out the right IP address:
> >
> >A client can have several candidate IP addresses that it
> may use for
> >the discovery process.  For example if it is located
> behind a NAT, a
> >private and a public IP address may be used for the discovery
> >process.  It depends on the deployment scenario which of the IP
> >addresses is the correct one.  Thus it is out-of-scope of this
> >document to specify how exactly the client finds the right IP
> >address.  However in the following we list methods that
> may be used
> >in order to determine these candidate IP addresses.
> Generally in P2P
> >environments peers already have implemented mechanisms for NAT-
> >traversal.  This includes proprietary solutions to
> determine a peer's
> >public IP address, for example by asking a neighbour
> peer about its
> >record of the own IP address.  Non-proprietary solutions that are
> >favorable include the Session Traversal Utilities for NAT (STUN)
> >[RFC5986] protocol to determine the public address.  If
> the client is
> >    behind a residential gateway another option 

Re: [alto] ALTO discovery in roaming scenario

[Scharf, Michael (Michael)]

Haibin,

Can you please explain how the scenario you describe is different to a normal 
NAT middlebox?

Regarding NAT, the draft right now states that there are various methods to 
find out the right IP address:

   A client can have several candidate IP addresses that it may use for
   the discovery process.  For example if it is located behind a NAT, a
   private and a public IP address may be used for the discovery
   process.  It depends on the deployment scenario which of the IP
   addresses is the correct one.  Thus it is out-of-scope of this
   document to specify how exactly the client finds the right IP
   address.  However in the following we list methods that may be used
   in order to determine these candidate IP addresses.  Generally in P2P
   environments peers already have implemented mechanisms for NAT-
   traversal.  This includes proprietary solutions to determine a peer's
   public IP address, for example by asking a neighbour peer about its
   record of the own IP address.  Non-proprietary solutions that are
   favorable include the Session Traversal Utilities for NAT (STUN)
   [RFC5986] protocol to determine the public address.  If the client is
   behind a residential gateway another option may be to use Universal
   Plug and Play (UPnP) [UPnP-IGD-WANIPConnection1] or the NAT Port
   Mapping Protocol (NAT-PMP) [I-D.cheshire-nat-pmp].


What text do you suggest to add to that?

Thanks,

Michael


> -Original Message-
> From: Songhaibin [mailto:haibin.s...@huawei.com] 
> Sent: Thursday, June 21, 2012 5:02 AM
> To: Scharf, Michael (Michael)
> Cc: alto@ietf.org
> Subject: RE: [alto] ALTO discovery in roaming scenario
> 
> Please imagine a gateway/proxy based network access, the ALTO 
> client is the end host, but actually the IP address for 
> gateway/proxy which connect the end host to the network 
> should be used for ALTO server discovery. The change of 
> end-host IP and gateway/proxy IP is independent somehow. I 
> hope this clarification helps.
> 
> BR,
> -Haibin
> 
> > -Original Message-
> > From: Scharf, Michael (Michael) 
> > [mailto:michael.sch...@alcatel-lucent.com]
> > Sent: Wednesday, June 20, 2012 8:07 PM
> > To: Songhaibin
> > Cc: alto@ietf.org
> > Subject: RE: [alto] ALTO discovery in roaming scenario
> > 
> > Haibin,
> > 
> > The draft already states:
> > 
> >o  A change of the IP address at an interface 
> invalidates the result
> >   of the ALTO server discovery procedure.  For 
> instance, if the IP
> >   address assigned to a mobile host changes due to host 
> mobility, it
> >   is required to run the ALTO server discovery 
> procedure for the new
> >   IP address without relying on earlier gained information.
> > 
> > Could you please explain what text is missing in the draft, 
> and what 
> > technical solution you suggest? For instance, if the mobile network 
> > uses "Proxy Mobile IP"?
> > 
> > My understanding is that in reality roaming/normadic use results in 
> > either of two
> > possibilities:
> > 
> > (1) There is a change of the IP address of the mobile host. 
> This case 
> > is already explained in the draft.
> > 
> > (2) The IP address of the mobile host does not change. 
> Then, the host 
> > remains in the same IP subnet, and thus the ALTO discovery 
> result is still valid.
> > 
> > In both cases, the current text in the discovery draft 
> seems to be just fine, right?
> > 
> > Thanks
> > 
> > Michael
> > 
> > 
> > > -Original Message-
> > > From: alto-boun...@ietf.org 
> [mailto:alto-boun...@ietf.org] On Behalf 
> > > Of Songhaibin
> > > Sent: Monday, June 18, 2012 1:22 PM
> > > To: Songhaibin; Richard Alimi
> > > Cc: alto@ietf.org
> > > Subject: Re: [alto] ALTO discovery in roaming scenario
> > >
> > > I would like to dig this from the tomb and see how the WG 
> would like 
> > > to solve the ALTO discovery in the roaming/nomadic 
> scenario. I would 
> > > also like to see it in the ALTO server discovery document.
> > >
> > > -Haibin
> > >
> > >
> > >
> > > > -Original Message-
> > > > From: alto-boun...@ietf.org [mailto:alto-boun...@ietf.org]
> > > On Behalf
> > > > Of Songhaibin
> > > > Sent: Thursday, March 29, 2012 8:34 PM
> > > > To: Richard Alimi
> > > > Cc: alto@ietf.org
> > > > Subject: Re: [alto] ALTO discovery in roaming scenario
> > > >
> > > > Hi Rich,
> > > >
> > > > I th

Re: [alto] ALTO discovery in roaming scenario

[Scharf, Michael (Michael)]

Haibin,

The draft already states:

   o  A change of the IP address at an interface invalidates the result
  of the ALTO server discovery procedure.  For instance, if the IP
  address assigned to a mobile host changes due to host mobility, it
  is required to run the ALTO server discovery procedure for the new
  IP address without relying on earlier gained information.

Could you please explain what text is missing in the draft, and what technical 
solution you suggest? For instance, if the mobile network uses "Proxy Mobile 
IP"?

My understanding is that in reality roaming/normadic use results in either of 
two possibilities:

(1) There is a change of the IP address of the mobile host. This case is 
already explained in the draft.

(2) The IP address of the mobile host does not change. Then, the host remains 
in the same IP subnet, and thus the ALTO discovery result is still valid.

In both cases, the current text in the discovery draft seems to be just fine, 
right?

Thanks

Michael


> -Original Message-
> From: alto-boun...@ietf.org [mailto:alto-boun...@ietf.org] On 
> Behalf Of Songhaibin
> Sent: Monday, June 18, 2012 1:22 PM
> To: Songhaibin; Richard Alimi
> Cc: alto@ietf.org
> Subject: Re: [alto] ALTO discovery in roaming scenario
> 
> I would like to dig this from the tomb and see how the WG 
> would like to solve the ALTO discovery in the roaming/nomadic 
> scenario. I would also like to see it in the ALTO server 
> discovery document.
> 
> -Haibin
> 
> 
> 
> > -Original Message-
> > From: alto-boun...@ietf.org [mailto:alto-boun...@ietf.org] 
> On Behalf 
> > Of Songhaibin
> > Sent: Thursday, March 29, 2012 8:34 PM
> > To: Richard Alimi
> > Cc: alto@ietf.org
> > Subject: Re: [alto] ALTO discovery in roaming scenario
> > 
> > Hi Rich,
> > 
> > I think your proposal makes sense. The wikipedia document 
> > http://en.wikipedia.org/wiki/Mobile_IP provides some links 
> to relative 
> > RFCs. We may find details in these RFCs. I will also try to 
> read them.
> > 
> > BR,
> > -Haibin
> > 
> > 
> > From: richard.al...@gmail.com [richard.al...@gmail.com] on 
> behalf of 
> > Richard Alimi [r...@velvetsea.net]
> > Sent: Thursday, March 29, 2012 8:09 PM
> > To: Songhaibin
> > Cc: alto@ietf.org
> > Subject: Re: [alto] ALTO discovery in roaming scenario
> > 
> > On Thu, Mar 29, 2012 at 12:26 AM, Songhaibin 
> 
> > wrote:
> > > Hi Rich,
> > >
> > > Thank you for the discussion. See inline.
> > >
> > > 
> > > From: richard.al...@gmail.com [richard.al...@gmail.com] 
> on behalf of 
> > > Richard
> > Alimi [r...@velvetsea.net]
> > > Sent: Wednesday, March 28, 2012 11:57 PM
> > > To: Songhaibin
> > > Cc: alto@ietf.org
> > > Subject: Re: [alto] ALTO discovery in roaming scenario
> > >
> > > On Mon, Mar 19, 2012 at 4:28 AM, Songhaibin 
> 
> > wrote:
> > >> Hi,
> > >>
> > >> The indicated by the subject, which is perhaps not fully 
> solved in 
> > >> the discovery
> > draft, I guess at least the following scenarios should be 
> considered. 
> > As I'm not an expert on roaming technology, please correct 
> me if you find I am wrong.
> > >>
> > >> (1) The ALTO client has left its home network, and its 
> IP address 
> > >> is dynamically
> > assigned by the current network provider (through DHCP or any other 
> > method), but the ALTO client still uses its home agent to 
> access the 
> > Internet. In this case, the ALTO server resided in its home network 
> > should be the right ALTO server to be discovered.
> > >>
> > >> (2) The ALTO client has left its home network, and its 
> IP address 
> > >> is dynamically
> > assigned by the current network provider, and the ALTO 
> client uses the 
> > foreign agent to access Internet or uses its IP address directly to 
> > access Internet. In this scenario, the ALTO server resided 
> in the current network should be the right one.
> > And the existing discovery mechanism works in this scenario.
> > >>
> > >> (3) If the ALTO client has a persistent IP address when roaming, 
> > >> and it uses
> > home agent to access Internet, but make large data route to the 
> > foreign agent directly (optimized routing mode). In this 
> scenario, the 
> > ALTO server resided in the current network should be the 
> right one to 
> > be discovered. However, if it does not adopt the optimized routing 
> > mode, the ALTO server in the home network should be the right one.
> > >>
> > >
> > > I'm not familiar with the technologies backing this, but 
> what entity 
> > > decides the route that a particular packet will take? Is this DPI 
> > > living in the network where the client is roaming?  Or is it some 
> > > entity on the client itself?
> > >
> > > [Haibin] No, it is not DPI based. Although I'm not an 
> expert on this 
> > > either, but I
> > think in the mobile IPv6 scenario, the decision is made through the 
> > negotiation among the mobile node, home agent, and other 
> corr