[alto] Fwd: ALTO at IETF-108: Finishing the current milestones and discussion on re-chartering the WG

[Danny Alex Lachos Perez <[e-mail]>]

Dear all,

Following the suggestion of the AD (Martin Duke) and the WG chairs (Jan and
VIjay) [0], many of us started excellent discussions on ALTO recharter.
In particular, this thread discusses the multi-domain aspects of ALTO
(please, take a look below).
We are moving the thread to the WG mailing list for more open discussions.

Any thoughts/comments/suggestions are greatly appreciated,

Thank you so much!

Best regards,

Danny Lachos

[0] https://mailarchive.ietf.org/arch/msg/alto/bPUxI6xmbms7i6_eoPiOy9Bpxro/

---------- Forwarded message ---------
From: Ingmar Poese <[e-mail]>
Date: Tue, Jul 14, 2020 at 8:33 AM
Subject: Re: [alto] ALTO at IETF-108: Finishing the current milestones and
discussion on re-chartering the WG
To: Sebastian Kiesel <[e-mail]>, Danny Alex Lachos Perez <
[e-mail]>
Cc: Y. Richard Yang <[e-mail]>


Hi all,

please see inline.

Ingmar

Am 14.07.20 um 11:56 schrieb Sebastian Kiesel:
> Hi Danny, all,
>
> On Mon, Jun 29, 2020 at 08:18:04AM -0300, Danny Alex Lachos Perez wrote:
>> Hello Sebastian,
>>
>> Thanks a lot for your comments
>> Please, see inline:
>>
>> Even the very first ALTO use case was multi-domain in some sense:
>>> the bittorrent clients in the access networks of Comcast and Sprint,
>>> the pirate bay tracker in Sweden, that could be seen as three domains.
>>> The examples in the drafts you have listed are obviously different and
>>> more complex, but I am still struggling to tell what exactly is new and
>>> needs to be done.
>>
>> Yes, I remember your question. I will try to clarify our multi-domain
>> approach.
>>  From your P2P example, we have the next figure:
>> [image: multi-domain-ALTO.jpg]
>> An ALTO server in each domain will provide only local information to ALTO
>> clients. In the example, the tracker (ALTO client) receives
>> topology-/policy-related information of a single domain (AS1 or AS2).
Let's
>> call it "single-domain information exposure".
>
> While your observation is probably true in most deployments we have seen
> so far, I do not completely agree on an architectural level.
>
> We have designed the ALTO protocol such that an ALTO client may ask one
> ALTO server *any* question, e.g., "give me network map and cost map for
> the whole Internet address space" or ECS(IP1, IP2) where IP1 and IP2
> are arbitrary IP addresses in whatever domain.
> The idea that there might be more than one ALTO server, and that one
> ALTO server might give better answers to some specific questions while
> another ALTO server might give better answers to other questions,
> was in our mind when we worked on the protocol, but it did not result
> in any specific feature of the base protocol that would deal with that
> situation.
I would actually like to go a little further on this point. At the early
stages, if i remember correctly, there was the discussion on "my view on
the Internet". I would like to point this out again and the fact that
"The Internet" looks different from different vantage points. Depending
on where you are, decisions are different. Furthermore, a client is not
capable of deciding which information to use from what ALTO server - and
it if get multiple answers, which one is "more" correct.

If the ALTO Server now only has information about the local network, or
only gives out information about the local network, matching this to
interAS client (or even clients in the same confederation) almost
impossible - and this gets worse if not all Networks offer an ALTO service.
I think an ALTO server should always give an indication on the entire
Internet from it's point of view, even if much of it is aggregated. This
reduces the problems to "what ALTO server to ask" for the client and can
be much easier deployed and maintained on a large scale.

>
> This is different for the discovery mechansims: there we had the idea
> that an ALTO server that is "near" to the endpoint of the data
> transmissions to be optimized, typically announced by the operator of
> the access network, will probably give good answers.
> If the "peer selection" (or any other routing decision in the overlay)
> is done in the endpoint of the data transmission itself, use RFC 7286;
> if it is done at a remote entity such as a tracker, use RFC 8686 to find
> ALTO server that is nearby the actual endpoint.
>
>
>> On the other hand, if we want an ALTO client to receive merged
information
>> from multiple domains, ALTO servers need to be able to exchange
>> information. In the example, the tracker will receive AS1’s and AS2’s
>> merged information. Let's call it "multi-domain information exposure".
>> As we identified [0], different use cases could benefit from multi-domain
>> information exposure using ALTO. However, it also places requirements
that
>> the current ALTO design do not satisfy [1].
>
> There is definitively room for extensions. We have so many architectural
> options (side note: what is now just the "ALTO protocol" has been called
> in RFC 5693 and 6708 the "ALTO client protocol", in anticipation that
> there might be an ALTO server-to-server protocol in the future).
>
>
> First area of questions: Data model.  If every ALTO server defines the
> network map on its own and uses the default smaller-value-is-better
> routingcost metric, which does not have a well-defined base unit, it
> will be hard to impossible to merge information from different servers.
> Deprecate them?  Replace with what? Or go for an architectural option
> (see below) that does not require information merging on the ALTO
> protocol side.
This is an interesting problem that i would like to go into further. But
then, i have a very narrow Agenda on our use case, so maybe i am
overshooting here.

>
> Second area of questions: placement of entities and protocols between
> them. This is also not completely new, see Sec. 2.2.3 of RFC 7971
>
> Ideas:
>
> 1. Define a new server discovery mechanism.  An ALTO client would
> discover several ALTO servers from different domains, ask each of them,
> and then aggregate the information on the client-side.
>
> 2. Mesh-style ALTO server-to-server communication.  Do we need a new
> s2s protocol?  Is a small extension to the ALTO protocol sufficient?
>
> 3. Hierarchical structure with backend information sources and frontend
> servers towards the ALTO clients. Aggregation of the information from
> different backends takes place in the frontends. How to ensure
> consistency? Do we need a new protocol for backend to frontend
> communication? Is a small extension to the ALTO protocol sufficient?
>
>
>  From an academic perspective, I'd love to investigate and specify each
> of these options and many more.  But from an IETF perspective: who is
> willing to deploy anything on a scale that requires and justifies the
> effort for standardization?  If there is one: what is their preference
> which way to go?  Is your group planning a deployment?
We (BENOCS) have had that on our ToDo list for about a year now, but we
have not come around to implementing it so far. The deployment would
encase about 100 million subscribers towards a few Hypergiants across
Europe.

I have a fairly good plan on how to do it - although we were not going
to use ALTO for cross domain ALTO (we call it cascading internally), but
rather implement something ourselves that fits our use case of
Hypergiant<->end-user mapping (we do not do P2P).

I would be open to discussing this in a broader sense to standardize the
approach.

---------- Forwarded message ---------
From: Sebastian Kiesel <[e-mail]>
Date: Tue, Jul 14, 2020 at 6:56 AM
Subject: Re: [alto] ALTO at IETF-108: Finishing the current milestones and
discussion on re-chartering the WG
To: Danny Alex Lachos Perez <[e-mail]>
Cc: Ingmar Poese <[e-mail]>, Y. Richard Yang <[e-mail]>


Hi Danny, all,

On Mon, Jun 29, 2020 at 08:18:04AM -0300, Danny Alex Lachos Perez wrote:
> Hello Sebastian,
>
> Thanks a lot for your comments
> Please, see inline:
>
> Even the very first ALTO use case was multi-domain in some sense:
> > the bittorrent clients in the access networks of Comcast and Sprint,
> > the pirate bay tracker in Sweden, that could be seen as three domains.
> > The examples in the drafts you have listed are obviously different and
> > more complex, but I am still struggling to tell what exactly is new and
> > needs to be done.
>
> Yes, I remember your question. I will try to clarify our multi-domain
> approach.
> From your P2P example, we have the next figure:
> [image: multi-domain-ALTO.jpg]
> An ALTO server in each domain will provide only local information to ALTO
> clients. In the example, the tracker (ALTO client) receives
> topology-/policy-related information of a single domain (AS1 or AS2).
Let's
> call it "single-domain information exposure".

While your observation is probably true in most deployments we have seen
so far, I do not completely agree on an architectural level.

We have designed the ALTO protocol such that an ALTO client may ask one
ALTO server *any* question, e.g., "give me network map and cost map for
the whole Internet address space" or ECS(IP1, IP2) where IP1 and IP2
are arbitrary IP addresses in whatever domain.
The idea that there might be more than one ALTO server, and that one
ALTO server might give better answers to some specific questions while
another ALTO server might give better answers to other questions,
was in our mind when we worked on the protocol, but it did not result
in any specific feature of the base protocol that would deal with that
situation.

This is different for the discovery mechansims: there we had the idea
that an ALTO server that is "near" to the endpoint of the data
transmissions to be optimized, typically announced by the operator of
the access network, will probably give good answers.
If the "peer selection" (or any other routing decision in the overlay)
is done in the endpoint of the data transmission itself, use RFC 7286;
if it is done at a remote entity such as a tracker, use RFC 8686 to find
ALTO server that is nearby the actual endpoint.


> On the other hand, if we want an ALTO client to receive merged information
> from multiple domains, ALTO servers need to be able to exchange
> information. In the example, the tracker will receive AS1’s and AS2’s
> merged information. Let's call it "multi-domain information exposure".
> As we identified [0], different use cases could benefit from multi-domain
> information exposure using ALTO. However, it also places requirements that
> the current ALTO design do not satisfy [1].

There is definitively room for extensions. We have so many architectural
options (side note: what is now just the "ALTO protocol" has been called
in RFC 5693 and 6708 the "ALTO client protocol", in anticipation that
there might be an ALTO server-to-server protocol in the future).


First area of questions: Data model.  If every ALTO server defines the
network map on its own and uses the default smaller-value-is-better
routingcost metric, which does not have a well-defined base unit, it
will be hard to impossible to merge information from different servers.
Deprecate them?  Replace with what? Or go for an architectural option
(see below) that does not require information merging on the ALTO
protocol side.


Second area of questions: placement of entities and protocols between
them. This is also not completely new, see Sec. 2.2.3 of RFC 7971

Ideas:

1. Define a new server discovery mechanism.  An ALTO client would
discover several ALTO servers from different domains, ask each of them,
and then aggregate the information on the client-side.

2. Mesh-style ALTO server-to-server communication.  Do we need a new
s2s protocol?  Is a small extension to the ALTO protocol sufficient?

3. Hierarchical structure with backend information sources and frontend
servers towards the ALTO clients. Aggregation of the information from
different backends takes place in the frontends. How to ensure
consistency? Do we need a new protocol for backend to frontend
communication? Is a small extension to the ALTO protocol sufficient?


>From an academic perspective, I'd love to investigate and specify each
of these options and many more.  But from an IETF perspective: who is
willing to deploy anything on a scale that requires and justifies the
effort for standardization?  If there is one: what is their preference
which way to go?  Is your group planning a deployment?

---------- Forwarded message ---------
From: Danny Alex Lachos Perez <[e-mail]>
Date: Mon, Jun 29, 2020 at 8:18 AM
Subject: Re: [alto] ALTO at IETF-108: Finishing the current milestones and
discussion on re-chartering the WG
To: Sebastian Kiesel <[e-mail]>
Cc: Ingmar Poese <[e-mail]>, Y. Richard Yang <[e-mail]>


Hello Sebastian,

Thanks a lot for your comments
Please, see inline:

Even the very first ALTO use case was multi-domain in some sense:
> the bittorrent clients in the access networks of Comcast and Sprint,
> the pirate bay tracker in Sweden, that could be seen as three domains.
> The examples in the drafts you have listed are obviously different and
> more complex, but I am still struggling to tell what exactly is new and
> needs to be done.

Yes, I remember your question. I will try to clarify our multi-domain
approach.
>From your P2P example, we have the next figure:
https://drive.google.com/file/d/1GjoxeliHJjw7rp9eXpGxHB5m98EXl2Vc/view

An ALTO server in each domain will provide only local information to ALTO
clients. In the example, the tracker (ALTO client) receives
topology-/policy-related information of a single domain (AS1 or AS2). Let's
call it "single-domain information exposure".
On the other hand, if we want an ALTO client to receive merged information
from multiple domains, ALTO servers need to be able to exchange
information. In the example, the tracker will receive AS1’s and AS2’s
merged information. Let's call it "multi-domain information exposure".
As we identified [0], different use cases could benefit from multi-domain
information exposure using ALTO. However, it also places requirements that
the current ALTO design do not satisfy [1].

A second thought of mine is: how much extensions (and added complexity)
> do we need in the ALTO protocol?

We have identified an initial set of requirements/extensions such as (i)
conceptual query interfaces and data representation (e.g., unified resource
representation, resource query language), (ii) communication mechanisms
(e.g., ALTO servers communication, multi-domain connectivity discovery,
multi-domain ALTO server discovery), (iii) and computation model (e.g.,
computation complexity optimization, security & privacy) [1].

Would it make sense to start
> standardizing the "provisioning protocol" (see RFC 5693, Fig. 1) for
> multi-domain scenarios and put some (or all) of the additional
> complexity there?

Very interesting your point on the provision protocol for multi-domain
scenarios. RFC7285 also mentions an external interface for populating the
ALTO server and the possibility to exchange information with other ALTO
servers. This would make sense with the multi-ALTO server communication
requirement to allow exchanging network information from multiple
domains either using a hierarchical or mesh architectural design.

Best regards,

Danny Lachos

[0] ANRW19: https://dl.acm.org/doi/10.1145/3340301.3341126 (slides:
https://irtf.org/anrw/2019/slides-anrw19-final28.pdf)
[1] slides:
https://datatracker.ietf.org/meeting/interim-2020-alto-01/materials/slides-interim-2020-alto-01-sessa-supporting-multi-domain-use-cases-with-alto


---------- Forwarded message ---------
From: Sebastian Kiesel <[e-mail]>
Date: Fri, Jun 26, 2020 at 1:59 PM
Subject: Re: [alto] ALTO at IETF-108: Finishing the current milestones and
discussion on re-chartering the WG
To: Danny Alex Lachos Perez <[e-mail]>
Cc: Ingmar Poese <[e-mail]>, Y. Richard Yang <[e-mail]>


Hi Danny,

Thank you for the heads up!

My first question would be: what are the domains in multi-domain?

Even the very first ALTO use case was multi-domain in some sense:
the bittorrent clients in the access networks of Comcast and Sprint,
the pirate bay tracker in Sweden, that could be seen as three domains.
The examples in the drafts you have listed are obviously different and
more complex, but I am still struggling to tell what exactly is new and
needs to be done.


A second thought of mine is: how much extensions (and added complexity)
do we need in the ALTO protocol?  Would it make sense to start
standardizing the "provisioning protocol" (see RFC 5693, Fig. 1) for
multi-domain scenarios and put some (or all) of the additional
complexity there?


Thanks
Sebastian


---------- Forwarded message ---------
From: Danny Alex Lachos Perez <[e-mail]>
Date: Fri, Jun 26, 2020 at 12:17 PM
Subject: Re: [alto] ALTO at IETF-108: Finishing the current milestones and
discussion on re-chartering the WG
To: Ingmar Poese <[e-mail]>, Sebastian Kiesel <[e-mail]
>
Cc: Y. Richard Yang <[e-mail]>


Dear Ingmar and Sebastian,

In the last ALTO virtual meeting (Apr, 21), we had a very brief discussion
about our on-going work on multi-domain.
Since multi-domain is to be considered as a major re-charter item, I am
using this thread to resume the discussion and engage key experts like you
two.

Here are some points to start our discussion:

   - Potential initial drafts to consider could be those that show how the
   use cases in multi-domain need a solution that currently is not enough in
   the ALTO design. The main idea in those documents should be to provide
   study cases and design requirements that are more in the scope of
   informational drafts (Use cases/Problem statement/Design requirements).
   - For a long time, we have had different personal
   drafts/papers/presentations associated with multi-domain [0-6]. Therefore,
   one action point could be to collect such pieces and write an initial draft
   regarding multi-domain use cases and ALTO design issues.
   - On the other hand, while we also have an initial scope on some
   potential solutions, I think, such solutions need more interactions and
   probably we should consider them as proposed standard drafts.

Please, any feedback/comment/suggestion on the above points are really
welcome.

I hope to start a fruitful discussion,
Thanks in advance and extend this thread to others if you think it could be
convenient

@Richard: Please, feel free to complement my initial thoughts

Best regards,

Danny Lachos
[0] ANRW19: https://dl.acm.org/doi/10.1145/3340301.3341126 (slides:
https://irtf.org/anrw/2019/slides-anrw19-final28.pdf)
[1] slides:
https://datatracker.ietf.org/meeting/interim-2020-alto-01/materials/slides-interim-2020-alto-01-sessa-supporting-multi-domain-use-cases-with-alto

[2]
https://datatracker.ietf.org/doc/draft-lachos-alto-multi-domain-use-cases/
[3]
https://datatracker.ietf.org/doc/draft-xiang-alto-unified-representation/
[4] https://datatracker.ietf.org/doc/draft-xiang-alto-multidomain-analytics/
[5] https://datatracker.ietf.org/doc/draft-lachosrothenberg-alto-md-e2e-ns/
[6] https://datatracker.ietf.org/doc/draft-lachosrothenberg-alto-brokermdo/