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 protected]> 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.
>
> 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 protected]
> <javascript:;>> wrote:
> >
> > 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:
> >
> 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=
> >
> > 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
> >
> > _______________________________________________
> > alto mailing list
> > [email protected] <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
_______________________________________________
alto mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/alto
