Subject: [alto] Inter-ALTO

From: Piotr Wydrych <[email-masked]>
Date: Sun, 22 Mar 2015 22:02:20 -0500

Hi All,

As some of you may remember, few years ago, long time before the 
protocol has been standardized, an idea of inter-ALTO communication has 
been proposed. As the protocol is now ready and extensions are beeing 
developed, I'd like to raise your attention to this communication scheme 
again :-)

Since it's not possible to discuss the proposal within 5', I'll raise 
some issues on the list.

1. The rationale
Some (maybe out-of-date) rationale can be found in 
draft-dulinski-alto-inter-problem-statement-01 from July 2011. For me, 
the two most important use-cases in which operators significantly may 
benefit from map exchange are (a) route assymmetry and (b) remote isp's 
preference.
Regarding (a), the core ALTO protocol focuses on comparing traffic 
destination endpoints (thanks to, e.g., data from BGP tables). If an 
ALTO server is aware of routes towards the AS it belongs to, it may 
compare traffic sources between each other. In (b), I assume that 
information form remote ASes may make endpoints from the same AS (e.g., 
assigned to the same PID due the same AS-PATH) distinguishable.

Since YMMV, I'd be glad to hear your voice to come out with a set of 
really important issues to be solved by inter-ALTO. I don't want to 
start an academic discussion and think of a lot of generic and specific 
use-cases.

2. General requirements
Base on the use-cases, a question may be raised: is there any set of 
information that has to be provided every time an ALTO server says it 
implements inter-ALTO? Some other requirements that have to be 
investigated include authentication, information confidentiality, 
incremental updatest etc.

3. Does any IETF RFC/draft address all the reqs?
I do not know of any.

4. Extension spec
E.g., should it be contained within one draft or split into problem 
statment / reqs / definition?

Best regards,
Piotr
-- 
Piotr 'GhosT' Wydrych .. xmpp:wydrych//agh.edu.pl .. http://wydrych.net/

A: Because it messes up the order in which people normally read text.
Q: Why is top-posting such a bad thing?

---

From: "Y. Richard Yang" <[email-masked]>
Date: Mon, 23 Mar 2015 16:58:47 -0400

Hi Piotr,

Thanks for starting a discussion on this scheme. Please see below.

On Sunday, March 22, 2015, Piotr Wydrych <[email-masked]
<javascript:_e(%7B%7D,'cvml',[email-masked]');>> wrote:

> Hi All,
>
> As some of you may remember, few years ago, long time before the protocol
> has been standardized, an idea of inter-ALTO communication has been
> proposed. As the protocol is now ready and extensions are beeing developed,
> I'd like to raise your attention to this communication scheme again :-)
>
> Since it's not possible to discuss the proposal within 5', I'll raise some
> issues on the list.
>
> 1. The rationale
> destination endpoints (thanks to, e.g., data from BGP tables). If an ALTO
> server is aware of routes towards the AS it belongs to, it may compare
> traffic sources between each other. In (b), I assume that information
> from remote ASes may make endpoints from the same AS (e.g., assigned to the
> same PID due the same AS-PATH) distinguishable.
>

> really important issues to be solved by inter-ALTO. I don't want to start
> an academic discussion and think of a lot of generic and specific use-cases.
>
>
Let me add one more use case, in the setting of inter-alto
communications. A setting that we are looking into is that a network is
partitioned (sharded), and hence there are multiple servers with each being
responsible for a given region. This can be considered a setting of
hierarchical alto. Hence, there are can be iterative and/or recursive
patterns on answering a query. I feel that this is an important issue, to
answer your question.

> implements inter-ALTO? Some other requirements that have to be investigated
> include authentication, information confidentiality, incremental updatest
> etc.

Right. The requirements will depend on the use cases.

> 3. Does any IETF RFC/draft address all the reqs?

Not I know of.

> statment / reqs / definition?
My personal preference is that a problem statement, which includes some
clear, real possible use cases can be a good starting point.

Talk to you at Dallas.

Richard

> Best regards,
> Piotr
> --
> Piotr 'GhosT' Wydrych .. xmpp:wydrych//agh.edu.pl ..
> https://urldefense.proofpoint.com/v2/url?u=http-3A__wydrych.
> net_&d=AwICAg&c=-dg2m7zWuuDZ0MUcV7Sdqw&r=4G36iiEVb2m_v-
> 0RnP2gx9KZJjYQgfvrOCE3789JGIA&m=4LLxlHCMd4UqEyyOvanuw4GrAfAT6f
> LGDAyAygWwHeo&s=aRMuAaXLNQ7_EYrl_EG_SN9EpqKEyptvEJEyhS_qdMo&e=
> _______________________________________________
> alto mailing list
> [email-masked]
> https://urldefense.proofpoint.com/v2/url?u=https-3A__www.
> ietf.org_mailman_listinfo_alto&d=AwICAg&c=-dg2m7zWuuDZ0MUcV7Sdqw&r=
> 4G36iiEVb2m_v-0RnP2gx9KZJjYQgfvrOCE3789JGIA&m=
> 4LLxlHCMd4UqEyyOvanuw4GrAfAT6fLGDAyAygWwHeo&s=
> mEoC8TS77l8YfKS4Somakf1ikOrKv40Jbfqp7FrWCA8&e=

-- 
Richard

---

From: Sebastian Kiesel <[email-masked]>
Date: Tue, 24 Mar 2015 08:39:26 +0100

Hi Piotr,
Hi Richard,
all,

first of all do you have any specific multi-domain ("partitioned") use
case in mind? Our original P2P use case certainly was, but it has become
quiet around it. For the newer use cases such as CDN or VPN optimization
or stuff related to SDN im am not so sure whether we need that.

I remember that many years ago we had detailed discussions how the
partitioned-knowledge-problem could be solved. We had several approaches:

1. all ALTO servers have the same knowledge

    1.1. ensure synchronization in the provisioning protocol (cf. 
        RFC 5693, Fig 1), which is currently not standardized

    1.2. standardize an inter-ALTO-server data replication protocol

2. different ALTO servers operated by different organizations (e.g.
    ISPs) do NOT have the same (global) knowledge

    2.1 ALTO clients can connect to any server and that first server
        will fetch the data (similar to an iterative DNS query) on behalf
        of the client, based on some kind of inter-ALTO-server
        request forwarding protocol

    2.2 ALTO clients can connect to any server and that first server
        will redirect the client to the "right" ALTO server that has the
        desired information, based on some kind of inter-ALTO-server
        authority information exchange protocol

    2.3 ALTO clients need to use some kind of "search engine" that
        indexes ALTO servers and redirects and/or gives cached results

    2.4 ALTO clients need to use an external discovery mechanism (e.g.
        based on a DHT or on DNS) to discover the ALTO server that has
        the desired information

My opinion is that for a small scenario with only a rather limited
number of federated domains, approach 1.1 should be sufficient. No
need to standardize anything here.
For a true Internet-scale scenario (e.g., the P2P use case), I do not
like the 1.? approaches, and I think that 2.4 is more realistic, for
reasons that I already outlined in this post:
http://www.ietf.org/mail-archive/web/alto/current/msg02547.html

One possible solution that follows the 2.4 approach is the xdom-disc
draft (currently expired, I'm working on a new version).

Thanks
Sebastian

---

From: Wendy Roome <[email-masked]>
Date: Tue, 24 Mar 2015 17:22:55 -0500

2.4 is fine when the client wants costs to or from the client. But it will not work well for a p2p tracker, which wants costs between arbitrary endpoints, even if they are all on the other side of the planet.

For that, you want 2.2 or 2.3. The problem with those is how do you know which alto server to use?

One possibility is to attach an "I have authoritative vista for this set of endpoints" attribute to network maps. Then (given a master list of alto servers) a tracker can select the alto server that is best for the tracker's client.

     -  Wendy  Roome

> On Mar 24, 2015, at 2:39, Sebastian Kiesel <[email-masked]> wrote:
> 
> Hi Piotr,
> Hi Richard,
> all,
> 
> https://www.ietf.org/mailman/listinfo/alto

---

From: "Y. Richard Yang" <[email-masked]>
Date: Tue, 24 Mar 2015 20:46:29 -0400

Sebastian, Wendy, all,

Regarding "newer" multi-domain ("partitioned") use cases. We are
working with partitioned use cases, in the context of  SDN, because of
scalability issues. But it is a single domain setting.

I liked the list of design choices!

1.1 is an interesting design point. Shi will present a YANG model for
updating ALTO server data. Hence, it can be a provisioning mechanism. Make
sense? An issue, is that we did not define the data store for Endpoint Cost
Service. Hence, the data driven ECS could be private data. If one wants a
unifying mechanism, it will need a YANG model.

I see the SSE design by Wendy as a push update mechanism as well (SSE to
server not client then). Objection?

The comment on tracker by Wendy is interesting. As part of our science
network, we are looking into integration with GridFTP, which allows third
party initiated transfer. This third party may or may not be a tracker. So
this is another example of multi domain.

Richard

On Tuesday, March 24, 2015, Wendy Roome <[email-masked]> wrote:

> 2.4 is fine when the client wants costs to or from the client. But it will
> not work well for a p2p tracker, which wants costs between arbitrary
> endpoints, even if they are all on the other side of the planet.
>
> One possibility is to attach an "I have authoritative vista for this set
> of endpoints" attribute to network maps. Then (given a master list of alto
> servers) a tracker can select the alto server that is best for the
> tracker's client.
>
>      -  Wendy  Roome
>
> > On Mar 24, 2015, at 2:39, Sebastian Kiesel <[email-masked]
> <javascript:;>> wrote:
> >
> > Hi Piotr,
> > Hi Richard,
> > all,
> >
> https://urldefense.proofpoint.com/v2/url?u=http-3A__www.ietf.org_mail-2Darchive_web_alto_current_msg02547.html&d=AwIFAg&c=-dg2m7zWuuDZ0MUcV7Sdqw&r=4G36iiEVb2m_v-0RnP2gx9KZJjYQgfvrOCE3789JGIA&m=UWMbwohNbQJH_AlG1dr8CmG_EzsG2Zf8cc1S8rCv_p4&s=u-mWMo6778EpK4gPG5jR-iVDm5GVJsTSKlSwsxKxeok&e=
> >
> > [email-masked] <javascript:;>
> >
> https://urldefense.proofpoint.com/v2/url?u=https-3A__www.ietf.org_mailman_listinfo_alto&d=AwIFAg&c=-dg2m7zWuuDZ0MUcV7Sdqw&r=4G36iiEVb2m_v-0RnP2gx9KZJjYQgfvrOCE3789JGIA&m=UWMbwohNbQJH_AlG1dr8CmG_EzsG2Zf8cc1S8rCv_p4&s=uyO-sR6PZ7EFCXehNfH2NxfCgW2pD0aG4kiJHSJGhHc&e=
>

-- 
Richard

---

From: Sebastian Kiesel <[email-masked]>
Date: Wed, 25 Mar 2015 12:23:13 +0100

Hi Wendy,

On Tue, Mar 24, 2015 at 05:22:55PM -0500, Wendy Roome wrote:
> 2.4 is fine when the client wants costs to or from the client. But it
> will not work well for a p2p tracker, which wants costs between
> arbitrary endpoints, even if they are all on the other side of the
> planet.

Why do you think that this will not work well?  The tracker will have
to contact a large number of ALTO servers and assemble a virtual map
based on the snippets it can get from these ALTO servers.
This is basically shifting the aggregation problem from server side
to client side.

approach 2.4 is analyzed in more detail in
https://tools.ietf.org/html/draft-kiesel-alto-xdom-disc-00

In addition to issues like overhead and caching efficiency, another
aspect might be legal liability.  Being an access network operator in
Europe, I am a bit reluctant to publish costs from, say, an access
network in Japan to an access network in the US through my ALTO server.
This is not only a question of map size and processing load on my
server. What happens if I wreck some other network operator's traffic
engineering or business model by giving wrong cost information or by
redirecting to the wrong ALTO server? That's why I would prefer
approaches 2.3 or 2.4.  (This paragraph is about an "open Internet" use
case).

> For that, you want 2.2 or 2.3. The problem with those is how do you know which alto server to use?

2.1 and 2.2 is basically the same problem.  All ALTO servers need to
know which other ALTO servers are authoritative for which parts of the
map.  They need a protocol to exchange this authority information.
Whether they fetch the data from there on behalf of the client,
or whether they tell the client "go fetch it from there on your own"
is mostly a question of caching efficiency.

2.3 is "why not just use your favorite web search engine to find the
right ALTO server?" - although I have some doubts regarding the incentives
for the operators of such search engines for indexing ALTO servers.

> One possibility is to attach an "I have authoritative vista for this
> set of endpoints" attribute to network maps. Then (given a master list
> of alto servers) a tracker can select the alto server that is best for
> the tracker's client.

This sounds similar to draft-kiesel-alto-alto4alto.
The question is: how would the operator of a network with his ALTO
server join the authority map? We would have to establish an
administration office where the can register (possibly IANA?).
In contrast, the xdom-disc draft tries to re-use DNS as an already
established rendez-vous point, so no new administration would have
to be created.

Sebastian