Subject: [alto] Adopting draft-kiesel-alto-xdom-disc as WG item?

From: Wendy Roome <[email-masked]>
Date: Tue, 12 Jul 2016 14:55:52 -0400

My comments on draft-kiesel-alto-xdom-disc-02:

Section 1:

You might mention that yet another problem with the 1.? solutions is that
the values of ALTO cost metrics are not standardized. For example, there
is no standard definition of what "routingcost 10" means. Hence cost
metric values are not comparable between ALTO servers.

This is also a problem for 2.1, because the client cannot tell if the
returned costs are from the server it contacted directly, or from some
other server. 

Section 3.2:

If a client wants the cost from X => Y, why just do cross-domain discovery
on address X? Why not do it for Y instead? Or do it for both X & Y?

Section 3.3:

This also has the problem that cost metric values are not standardized,
which will make it very difficult to merge costs from multiple ALTO
servers into a single cost map.

Also, I think you mean "NxN cost map" rather than "NxN network map".

Section 4.2.1:

"or redirect the client to another ALTO server using mechanisms of the
ALTO protocol (see Sect. 9 of [RFC7285])."

Does that refer to a root IRD referencing a secondary IRD, as described in
Section 9.2.4? If so, I don't think of a secondary IRD as representing a
different ALTO server. Rather, I regard secondary IRDs as distributing the
resources of one ALTO server over several physical processors. I assumed
that the set of resources from the root IRD and secondary IRDs were
managed by the same entity, and used the same cost metric definitions, so
that cost metric values obtained from any of those resources could be
safely compared with each other.

	- Wendy Roome

---

From: Sebastian Kiesel <[email-masked]>
Date: Tue, 12 Jul 2016 23:09:13 +0200

Hi Wendy,

thanks for your review. please see below:

> returned costs are from the server it contacted directly, or from some

Indeed, this is a problem with all approaches. Please see also 
the discussion of 3.3. below.

> on address X? Why not do it for Y instead? Or do it for both X & Y?

This is again to cope with the not so well-defined "routingcost" metric.

Our assumtion is that XDOM-DISC(X) will discover one ALTO server,
which will be able to express costs (X,Y) and costs (X,Z) using a
(locally) consistent routingcost metric, i.e., with the meaning that
a lower value indicates a higher preference.

If we used XDOM-DISC(Y) and XDOM-DISC(Z) we would probably discover
two servers, which could use completely incompatible definitions.

In other words, the example query given in sec. 11.5.1.7. of RFC 7285
should be sent to the server yielded from XDOM-DISC(192.0.2.2).

If the "srcs" list contained more than one IP address, the query
should be split up in several queries, each containing only one
IP address in "srcs" (but keep all in "dsts"), and each of these
"sub-queries" would need its own call to XDOM-DISC.

> servers into a single cost map.

you are absolutely right.  So the "TBD" in this section is maybe
not to explain how this could be done, but more like explaining why
this is impossible unless we have a well-defined cost metric.

> Also, I think you mean "NxN cost map" rather than "NxN network map".

right. (although inconsistent PID definitons among different ALTO servers
will add further headaches to the problem).

> Section 9.2.4?

Not necessarily a "secondary" IRD, though this could be an option as
well.  I was thinking more of a dynamically generated IRD,  maybe
something like: if the client is from within our own network (maybe
using RFC 7286 to discover our server), return an IRD that points to a
fine grained PID map and many different cost maps, otherwise, if it
is a "foreign" client that discovered us using XDOM-DISC, return
an IRD that has a more coarse grained PID map and fewer cost maps.

> If so, I don't think of a secondary IRD as representing a

Hm. I need to think about that.  Did we define this, or is there text
that at least suggests that behavior?

But for the discussion of this draft, this is maybe not so important.
The idea behind xdom disc is, that if we cannot have a single omniscient
ALTO server a full NxN cost matrix with a consistent metric, we could at
least do some ranking (relative ordering) using queries like the one in
sec. 11.5.1.7. of RFC 7285, if operators publish their 1xN "cost
vectors" via their ALTO servers and the DNS. However, we need to be
aware that we cannot compare results of different queries.
Still better than nothing, if the "single omniscient server" scenario
turns out to be unrealistic, isn't it?

Thanks
Sebastian

---

From: Gao Kai <[email-masked]>
Date: Fri, 15 Jul 2016 10:27:14 +0800

Hi Sebastian, Wendy and all,

Please see below:

> "sub-queries" would need its own call to XDOM-DISC.
I had the same question as Wendy because for me, sources and
destinations are somewhat symmetric so it is tempting to think there
should be something like XDOM-DISC(X, Y), which might be overcomplicated
though.

I think whether to use the source/destination or to split up queries
depends on the application.  If it is selecting a destination for a
given source, it certainly can choose XDOM-DISC(SRC).  If the selection
is about sources, probably XDOM-DISC(DST) is more reasonable.  If the
application wants to pick the best source-destination pair, maybe the
queries should never be split up.
> that at least suggests that behavior?
Personally I think not only the secondary IRD, but also the entries in
an IRD might be on another different ALTO server, where "different"
means "hosted by different authorities".  It is technically possible
that an ALTO server discovers other ALTO servers using XDOM-DISC and
puts their IRD entries in its own directory.

I mean, if we see IRD as a directory in a file system, it is natural to
think that there can be NFS directories (secondary directories pointing
to another ALTO server) and symbolic links (IRD entries pointing to ALTO
services on other ALTO servers).  As Sebastian suggests, we may make it
clear that such behaviour should be avoided.

I would say we accept this, though, since the protocol does not provide
any technical restriction on that.
> turns out to be unrealistic, isn't it?

Regards,
Kai

---

From: wang xin <[email-masked]>
Date: Fri, 15 Jul 2016 14:00:07 +0000

Dear all,

For the first part, I think a key point is the cost(X, Y) should be kept at XDOM-DISC(X) or XDOM-DSIC(Y) or both. If only at XDOM-DISC(X), then it would become much complex for an ECS request like "give me all cost values with destination Y". It should ask all ALTO servers to get the result (here I assume cost(X, Y) != cost(Y, X)). It is the same for only at XDOM-DISC(Y). Hence, I think the cost(X, Y) should be kept at both servers.

Thanks,

Xin

________________________________
From: alto <[email-masked]> on behalf of Gao Kai <[email-masked]>
Sent: Friday, July 15, 2016 10:27:14 AM
To: Sebastian Kiesel; Wendy Roome
Cc: IETF ALTO
Subject: Re: [alto] Adopting draft-kiesel-alto-xdom-disc as WG item?

Please see below:

Hi Wendy,

Section 1:

Section 3.2:

I had the same question as Wendy because for me, sources and destinations are somewhat symmetric so it is tempting to think there should be something like XDOM-DISC(X, Y), which might be overcomplicated though.

I think whether to use the source/destination or to split up queries depends on the application.  If it is selecting a destination for a given source, it certainly can choose XDOM-DISC(SRC).  If the selection is about sources, probably XDOM-DISC(DST) is more reasonable.  If the application wants to pick the best source-destination pair, maybe the queries should never be split up.

Section 3.3:

Section 4.2.1:

Personally I think not only the secondary IRD, but also the entries in an IRD might be on another different ALTO server, where "different" means "hosted by different authorities".  It is technically possible that an ALTO server discovers other ALTO servers using XDOM-DISC and puts their IRD entries in its own directory.

I mean, if we see IRD as a directory in a file system, it is natural to think that there can be NFS directories (secondary directories pointing to another ALTO server) and symbolic links (IRD entries pointing to ALTO services on other ALTO servers).  As Sebastian suggests, we may make it clear that such behaviour should be avoided.

I would say we accept this, though, since the protocol does not provide any technical restriction on that.

Thanks
Sebastian

Regards,
Kai

---

From: Sebastian Kiesel <[email-masked]>
Date: Fri, 15 Jul 2016 17:14:44 +0200

Hi Kai and all,

On Fri, Jul 15, 2016 at 10:27:14AM +0800, Gao Kai wrote:
> destinations are somewhat symmetric 

if src/dst and the costs between are really symmetric, it doesn't
make a difference.

> so it is tempting to think there

That would be too complicated indeed.

> is about sources, probably XDOM-DISC(DST) is more reasonable. 

I agree.  So the idea is, that we call XDOM-DISC(X), in oder to find an
ALTO server that can answer both ECS queries, whether

routingcost(src=X, dst=Y) > routingcost(src=X, dst=Z).

and whether

routingcost(src=Y, dst=X) > routingcost(src=Z, dst=X).

In other words, we use the common address X that appears in all the
tuples we want to compare as parameter for the XDOM-DISC.

For the Endpoint Cost Service ECS, queries may have to be split in
a way that either the "srcs" or the "dsts" list in the query contains
only one IP address - and this address is used for XDOM-DISC.
What that means for the other ALTO services we still need to define.

> If the

Not splitting the queries would be the best thing to do from an
optimization perspective.  It would be great if there were
a bunch of ALTO servers all with the same knowledge, so we could
just discvover any one of them (e.g. using RFC7286) and ask it
arbitrary questions or download a comprehensive NxN cost map.
But for various reasons I believe that this is not going to happen
on an Internet scale (and after all, we are the Internet Engineering
Task Force ;) ).  So we need to find a solution that works if knowledge
is partitioned.

Thanks
Sebastian

---

From: Sebastian Kiesel <[email-masked]>
Date: Fri, 15 Jul 2016 17:36:09 +0200

On Fri, Jul 15, 2016 at 02:00:07PM +0000, wang xin wrote:
> Dear all,
> 
> 
> For the first part, I think a key point is the cost(X, Y) should be
> kept at XDOM-DISC(X) or XDOM-DSIC(Y) or both. If only at XDOM-DISC(X),
> then it would become much complex for an ECS request like "give me all
> cost values with destination Y". It should ask all ALTO servers to get
> the result (here I assume cost(X, Y) != cost(Y, X)). It is the same
> for only at XDOM-DISC(Y). Hence, I think the cost(X, Y) should be kept
> at both servers.

Yes.  It should be kept at both servers.

However, we must be aware that if we ask for routingcost(X,Y) at the
server discovered by XDOM-DISC(X) we may get a different numerical
result than if we ask the same query at the server discovered by
XDOM-DISC(Y).  This is because of the (intentionally) vague definition
of routingcost as a relative measure without a "base unit".

Therefore, we need to figure out, which is the host that has choices
to which other hosts to talk.  The address of this host, who needs
the ALTO guidance, will be used as parameter for XDOM-DISC.

Sebastian

---

From: Gao Kai <[email-masked]>
Date: Sat, 16 Jul 2016 00:17:12 +0800

Hi Sebastian and all,

> That would be too complicated indeed.
Actually my first feeling is that may be we can use XDOM-DISC(LCP(X,Y))
where LCP stands for longest common prefix.  This can be extended to
multiple addresses, for example, use the ALTO server XDOM-DISC(LCP(X, Y,
Z)) for both scenarios described below.
> tuples we want to compare as parameter for the XDOM-DISC.
Yes.  Also, I think maybe it is better to change the tone a bit with
"SHOULD"/"MIGHT" to indicate preferences instead of "MUST"/"HAVE TO"
which make it a rule, because judging the quality of ALTO services only
by their location is not very convincing.

---

From: Wendy Roome <[email-masked]>
Date: Fri, 15 Jul 2016 14:07:23 -0400

Sebastian,

RFC 7285 does not explicitly say that. But Section 8.3.1 defines the
resource closure as all resources the client can discover by starting with
the root IRD and walking all the secondary IRDs, and Section 9.1.1 says
resource IDs should be unique over all resources in that closure.

Furthermore, Section 9.2.4 gives an example of a secondary IRD with
filtered cost maps. They use the network map resource defined in the root
IRD in Section 9.2.3, and complement the full cost maps in the root IRD.
So the filtered maps in that secondary IRD should return cost values which
are consistent with those in the full cost maps. Otherwise clients would
be very confused!

	- Wendy

---

From: Sebastian Kiesel <[email-masked]>
Date: Fri, 15 Jul 2016 23:19:09 +0200

Hi Kai,

> Z)) for both scenarios described below.

I don't think that this idea will work in practice.  LCP(X,Y) will most
often be outside of the in-addr.arpa. subtrees delegated to X's or Y's ISP.
Often, LCP(X,Y) will result in 0.0.0.0/0  - we would need some
"top-level ALTO server" or something like that?

Our proposal is much easier to implement:

If an IP address (or prefix) X belongs to an ISP or the IT department
of a company/university/etc., they should know the costs from X to all 
other destinations in the Internet and vice versa.  They can put them
in their ALTO server, i.e., that ALTO server will be able to answer whether
routingcost(src=X, dst=Y) > routingcost(src=X, dst=Z).
and whether
routingcost(src=Y, dst=X) > routingcost(src=Z, dst=X).
They can adjust their DNS so that XDOM-DISC(X) will find this ALTO
server.

Of course, other ALTO servers operated by various parties may also know
information related to X, but XDOM-DISC(X) points to one IRD URI
endorsed by the ISP/operator of X.

On the other hand, if you have a deployment scenario where
XDOM-DISC(LCP(X,Y)) makes sense, we don't need any change in
the specification of XDOM-DISC() and nobody will prevent you from
calling XDOM-DISC with the output from LCP.

> by their location is not very convincing.

First, the whole section 3 does not use RFC2119 keywords.  Its purpose
is to illustrate how this algorithm should be used.  Other ways of
using XDOM-DISC are possible; nevertheless, our description should
not become too vague.

Second, what do you mean with "judging the quality of ALTO services only
by their location is not very convincing."?
My view on this algorithm is that those people who control the reverse
DNS for a specific IP address or prefix X (i.e., usually an ISP or 
IT department) can use the DNS to announce that if you want to optimize
traffic from or to X, you should use the indicated ALTO server.

Thanks
Sebastian

---

From: Gao Kai <[email-masked]>
Date: Sat, 16 Jul 2016 10:47:39 +0800

Hi Sebastian and all,

> calling XDOM-DISC with the output from LCP.
I have no intention to change the specification of XDOM-DISC, which I
think is pretty clear.  But it does occur to me that a shorter prefix
may suggest the associated ALTO server has better knowledge on queries
for end points in a larger range.
> traffic from or to X, you should use the indicated ALTO server.
My apologies.  I once questioned ([1]) about the meaning of the IP
address used in the XDOM-DISC and how servers should register the DNS
records but it's very clear now.  I got the wrong impression because LIS
is most likely to be looking for a nearby server.

Regards,
Kai

[1] https://mailarchive.ietf.org/arch/msg/alto/SbFtzE_Xen6wULDyt8Nmn5gLo28

---

From: "Mingming Chen" <[email-masked]>
Date: Sat, 16 Jul 2016 10:57:23 +0800 (CST)

Hi all,
First, I agree with Kai :
"
>> is about sources, probably XDOM-DISC(DST) is more reasonable. 
"
Then, Xin's idea is reasonable for me. Suppose XDOM-DISC(X) just can get cost(X,*), an ALTO Client want to ask a reasonable cost(X,*) with a given X, it can achieve through XDOM-DISC(X), but when it want to ask a reasonable cost(*,Y) with a give Y, it should sent to all servers(except Y) to get the info, so I agree with Xin's here. XDOM-DISC(X) should register cost( X, *), cost(*,X), so it will save the query processor.

Besides that, I think we can reduce some extra cost information of XDOM-DISC(X) by training in a specific situation(It depends on different applications and scene). When some cost information has not been called for a long time, we can consider to remove them to simplify cost data store.

Then, a typo in 2.3, paragraph 2, line 3: and it is rooted in the in the special domain "IN-ADDR.ARPA."

At 2016-07-15 23:14:44, "Sebastian Kiesel" <[email-masked]> wrote:
>_______________________________________________
>alto mailing list
>[email-masked]
>https://www.ietf.org/mailman/listinfo/alto

---

From: "Y. Richard Yang" <[email-masked]>
Date: Mon, 18 Jul 2016 20:44:22 -0400

Hi all,

It sure is a good thread of discussions. Here is a bit more thought.

Consider traffic from X1 -> Y1 with a given routing path. In a general
setting, the path will traverse a set of network devices,
contributed/funded by a set of network service providers (NSPs). There can
be a set of properties/metrics associated with the path X1->Y1, e.g.,
routing-cost(X1->Y1), propagation-delay(X1->Y1), and we can identify two
types:

- Type 1: Some of the metrics can be "objective" or "universal" if we want
a slightly more neutral word. For example, propagation delay is one, in
that there should be a single value, although different entities may have
different estimation of the (true) value.

- Type 2: Some of the metrics can be more "subjective", and an example is
routing cost, in that it probably should be a vector, with at least one
assigned value from the aspect of each NSP contributing its resources in
the path.

For a Type 1 metric, different ALTO servers should give the same value of
m1(X1->Y1), and if two servers give two different values, something is
wrong.

For a Type 2 metric, different ALTO servers may inherently be giving their
different aspects (components of the vector), and hence it can be
reasonable that the client, who is in control, chooses whose aspect(s) it
considers. The client may choose to discover and get as many aspects, for
those on the path, as possible and make a tradeoff, or consider only a
single aspect. In other words, a key issue is to discover those who
can/want to share an aspect on such a metric. My sense is that some
systematic analysis of potential stake-holder scenarios can be helpful,
when designing the important xdom mechanism.

Richard

On Fri, Jul 15, 2016 at 10:57 PM, Mingming Chen <[email-masked]>
wrote:

> Then, Xin's idea is reasonable for me. Suppose XDOM-DISC(X) just can get
> cost(X,*), an ALTO Client want to ask a reasonable cost(X,*) with a given
> X, it can achieve through XDOM-DISC(X), but when it want to ask a
> reasonable cost(*,Y) with a give Y, it should sent to all servers(except Y)
> to get the info, so I agree with Xin's here. XDOM-DISC(X) should register
> cost( X, *), cost(*,X), so it will save the query processor.
>
> Besides that, I think we can reduce some extra cost information of XDOM-DISC(X)
> by training in a specific situation(It depends on different applications
> and scene). When some cost information has not been called for a long time,
> we can consider to remove them to simplify cost data store.
>
> Then, a typo in 2.3, paragraph 2, line 3: and it is rooted in the *in the*
> special domain "IN-ADDR.ARPA."
>
>
>
>
>
>
> https://urldefense.proofpoint.com/v2/url?u=https-3A__www.ietf.org_mailman_listinfo_alto&d=CwICAg&c=-dg2m7zWuuDZ0MUcV7Sdqw&r=4G36iiEVb2m_v-0RnP2gx9KZJjYQgfvrOCE3789JGIA&m=_oBdiZa8lfE8dhoB5OrQnvZet95uHVboRGpQLFNgYwU&s=VQN7JZNuLze-wcZOmB0fmNHbLQX88bZnjAL9qdFSakU&e=
>
>

-- 
-- 
 =====================================
| Y. Richard Yang <[email-masked]>   |
| Professor of Computer Science       |
| http://www.cs.yale.edu/~yry/        |
 =====================================

---

From: Sebastian Kiesel <[email-masked]>
Date: Tue, 19 Jul 2016 15:36:24 +0200

Hi Richard,

our proposal aims at the "routingcost" metric we have in our base
protocol spec and at all the "type 1" metics in your classification.
For the "type 2" metrics, do you have a draft or other document in
mind, against which we could check the applicability?

Thanks
Sebastian

---

From: "Y. Richard Yang" <[email-masked]>
Date: Tue, 19 Jul 2016 16:27:41 -0400

Sebastian,

> protocol spec and at all the "type 1" metics in your classification.

This is a good starting point.

> I do not, and can try to work on one soon :-)

Thanks a lot for the good work!
Richard

Thanks
> > On Fri, Jul 15, 2016 at 10:57 PM, Mingming Chen <[email-masked]
> <javascript:;>>
> > wrote:
> >
> > > Hi all,
> > > At 2016-07-15 23:14:44, "Sebastian Kiesel" <[email-masked]
> <javascript:;>> wrote:
> > > >Hi Kai and all,
> > > >
> > > >[email-masked] <javascript:;>
> > >
> > > >
> https://urldefense.proofpoint.com/v2/url?u=https-3A__www.ietf.org_mailman_listinfo_alto&d=CwIBAg&c=-dg2m7zWuuDZ0MUcV7Sdqw&r=4G36iiEVb2m_v-0RnP2gx9KZJjYQgfvrOCE3789JGIA&m=kWZaV319Ac-B7cDmzmre5DaIXwFd4sUR0alUPVIjAh0&s=wn7taG7TWwfDJIr8ua-WFZCDidS0uII4kqgZbX2MkNU&e=
> > >
> > >
> > >
> > >
> > >
> > > [email-masked] <javascript:;>
> > >
> > >
> > | Y. Richard Yang <[email-masked] <javascript:;>>   |

-- 
Richard

---

From: Sebastian Kiesel <[email-masked]>
Date: Tue, 19 Jul 2016 23:28:32 +0200

Hi Richard,

> > I do not, and can try to work on one soon :-)

Hm, that was not quite the answer I was hoping to get.
To me, XDOM-DISC is the one missing piece to "ALTO 1.0" as we envisioned
it some years ago.

What you envision with the "type 2" metrics is maybe not one, but
several steps beyond that.  Of course, if we had a rather consistent
view among WG members about these next steps (and ideally a non -00
draft for a chartered deliverable), we should take that into
consideration.  Given the current state of the "type 2" idea, I'd prefer
to quickly finalize XDOM-DISC a companion document to RFC 7285 and then
see what's next.

Sebastian