Re: [alto] ALTO at IETF-108: Finishing the current milestones and discussion on re-chartering the WG
Hi Jensen, On Fri, Jul 17, 2020 at 07:08:13PM -0400, Jensen Zhang wrote: > Hi Sebastian, Ingmar, Danny, all, > > First, thanks for all your discussions. I also have several comments. > Please see inline. > > On Tue, Jul 14, 2020 at 2:39 PM Sebastian Kiesel wrote: > > > > Hi Ingmar, all, > > > > On Tue, Jul 14, 2020 at 01:33:37PM +0200, Ingmar Poese wrote: > > > Am 14.07.20 um 11:56 schrieb Sebastian Kiesel: > > > > On Mon, Jun 29, 2020 at 08:18:04AM -0300, Danny Alex Lachos Perez wrote: > > > > > > 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". > > > > You remember correctly. > > > > And if I remember correctly, we also had the idea that (at least for the > > P2P use case), the ALTO information generally should flow in the > > opposite direction of the money: If, for example, I am a paying > > customer of a specific ISP, I should listen to my ISP's guidance > > (disseminated through my ISP's ALTO server), in order to reduce the > > ressource consumption in their network and their costs for their > > peerings or upstream, so they won't have to increase my monthly bill > > and/or enforce volume caps or bandwidth throttling. > > > > As long as the assumption "bigger pipes = lower cost per byte = less > > congestion = higher per-flow throughput" holds true, this strategy will > > also give better application performance to me, the famous win-win > > situation (or assumption). But there are also counter-examples: If I am > > a mobile subscriber, my mobile network operator might be tempted to say > > (for the P2P use case): any destination peer outside of my network is > > better than pushing the same data twice through my radio access network, > > to a another customer in my network running the P2P application. If > > the ALTO server gives such simplistic guidance (low preference for local > > network prefixes, uniformly higher preference for all other prefixes), > > I might end up contacting a mobile user in a different part of the > > world, thus going through 2 wireless links plus a transcontinental link. > > > > So, multi-domain optimization might be challenging. And I am still not > > so sure what are the domains in the multi-domain draft ... > > I agree. The term "domain" is not defined clearly. There have been > multiple (active/expired) multi-domain related drafts in WG. They may > talk about different use cases but all claim they are "multi-domain". > But in general, I think a "domain" means a partial network that > provides an ALTO server. Those domains can be ASes of the same ISP, > IXPs, the backbone networks of different ISPs, different access > networks, or even mobile edge clouds. Each domain may only have a > partial view (routing and performance) of the user-intended traffic > (not the complete view of partial traffic). So they need some > server-to-server information exchange to get a more accurate view of > traffic for their end-users. But for different kinds of "domains", > there may be different requirements. e.g., the
Re: [alto] ALTO at IETF-108: Finishing the current milestones and discussion on re-chartering the WG(Internet mail)
Hello all, The discussions are so interesting. I provide my view on ALTO as below. Normally, for the routing procedure, there are two types of routing protocols/procedures, one is interior-domain routing and another is inter-domain routing. For the interior-domain routing, the routers in the path selects the next router based on the internal calculated lowest "cost". For the inter-domain routing, the routers in the path selects the next router based on the local domain configured "policies" or "rules". The current ALTO server provides the similar function of the "router" in the interior domain: router is select next destination "router" based on the lowest cost, while the ALTO server provides the best destination "resource provider" based on lowest cost. So for the ALTO to support inter-domain, the similar routing technologies can be used, e.g. the BGP-like technologies can be reused. i.e. the ALTO servers from different domains need to talk each to exchange the " resource provider and related cost" information, but the " resource provider and related cost" information are provided in the ALTO server as BGP as policies and rules configured by the domain manager. For the ALTO client, it must not access directly to the inter-domain ALTO server, it can access its interior-domain ALTO server, this interior-domain ALTO server will talk with its domain border ALTO server and provides the final destination to the ALTO client. So there are type communications :1) interior ALTO server to domain border ALTO server; 2) inter domain ALTO server Here is my basic understanding on the inter-domain ALTO, it is just my personal view. I find that SDN-based WAN is proposed in some paper, the SDN controller selects a routing path based on the global view on the WAN. Maybe the SDN-based WAN technologies can be investigated to identify whether the SDN controller helps to select a best destination based on the global view of the WAN. In such case, the interior ALTO server needs to communicate with the SDN controller. The communication between two SDN controller is outside of ALTO. With this method, it will simplify the standard work in ALTO, but we need to cooperate with SD-WAN work (it is still unclear in which organization). It is just a draft idea, I need more time to study this possibility, but I hope people also to notice this direction. BRs, Chunshan Xiong -Original Message- From: alto On Behalf Of Jensen Zhang Sent: Saturday, July 18, 2020 7:08 AM To: Sebastian Kiesel Cc: Ingmar Poese ; IETF ALTO Subject: Re: [alto] ALTO at IETF-108: Finishing the current milestones and discussion on re-chartering the WG(Internet mail) Hi Sebastian, Ingmar, Danny, all, First, thanks for all your discussions. I also have several comments. Please see inline. On Tue, Jul 14, 2020 at 2:39 PM Sebastian Kiesel wrote: > > Hi Ingmar, all, > > On Tue, Jul 14, 2020 at 01:33:37PM +0200, Ingmar Poese wrote: > > Am 14.07.20 um 11:56 schrieb Sebastian Kiesel: > > > On Mon, Jun 29, 2020 at 08:18:04AM -0300, Danny Alex Lachos Perez wrote: > > > > > 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
Re: [alto] ALTO at IETF-108: Finishing the current milestones and discussion on re-chartering the WG
Hi Sebastian, Ingmar, Danny, all, First, thanks for all your discussions. I also have several comments. Please see inline. On Tue, Jul 14, 2020 at 2:39 PM Sebastian Kiesel wrote: > > Hi Ingmar, all, > > On Tue, Jul 14, 2020 at 01:33:37PM +0200, Ingmar Poese wrote: > > Am 14.07.20 um 11:56 schrieb Sebastian Kiesel: > > > On Mon, Jun 29, 2020 at 08:18:04AM -0300, Danny Alex Lachos Perez wrote: > > > > > 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". > > You remember correctly. > > And if I remember correctly, we also had the idea that (at least for the > P2P use case), the ALTO information generally should flow in the > opposite direction of the money: If, for example, I am a paying > customer of a specific ISP, I should listen to my ISP's guidance > (disseminated through my ISP's ALTO server), in order to reduce the > ressource consumption in their network and their costs for their > peerings or upstream, so they won't have to increase my monthly bill > and/or enforce volume caps or bandwidth throttling. > > As long as the assumption "bigger pipes = lower cost per byte = less > congestion = higher per-flow throughput" holds true, this strategy will > also give better application performance to me, the famous win-win > situation (or assumption). But there are also counter-examples: If I am > a mobile subscriber, my mobile network operator might be tempted to say > (for the P2P use case): any destination peer outside of my network is > better than pushing the same data twice through my radio access network, > to a another customer in my network running the P2P application. If > the ALTO server gives such simplistic guidance (low preference for local > network prefixes, uniformly higher preference for all other prefixes), > I might end up contacting a mobile user in a different part of the > world, thus going through 2 wireless links plus a transcontinental link. > > So, multi-domain optimization might be challenging. And I am still not > so sure what are the domains in the multi-domain draft ... I agree. The term "domain" is not defined clearly. There have been multiple (active/expired) multi-domain related drafts in WG. They may talk about different use cases but all claim they are "multi-domain". But in general, I think a "domain" means a partial network that provides an ALTO server. Those domains can be ASes of the same ISP, IXPs, the backbone networks of different ISPs, different access networks, or even mobile edge clouds. Each domain may only have a partial view (routing and performance) of the user-intended traffic (not the complete view of partial traffic). So they need some server-to-server information exchange to get a more accurate view of traffic for their end-users. But for different kinds of "domains", there may be different requirements. e.g., the internal routing information can be shared among domains of the same ISP, but may not for different ISPs. > > 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
Re: [alto] ALTO at IETF-108: Finishing the current milestones and discussion on re-chartering the WG
Hi Ingmar, all, On Tue, Jul 14, 2020 at 01:33:37PM +0200, Ingmar Poese wrote: > Am 14.07.20 um 11:56 schrieb Sebastian Kiesel: > > On Mon, Jun 29, 2020 at 08:18:04AM -0300, Danny Alex Lachos Perez wrote: > > > > 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". You remember correctly. And if I remember correctly, we also had the idea that (at least for the P2P use case), the ALTO information generally should flow in the opposite direction of the money: If, for example, I am a paying customer of a specific ISP, I should listen to my ISP's guidance (disseminated through my ISP's ALTO server), in order to reduce the ressource consumption in their network and their costs for their peerings or upstream, so they won't have to increase my monthly bill and/or enforce volume caps or bandwidth throttling. As long as the assumption "bigger pipes = lower cost per byte = less congestion = higher per-flow throughput" holds true, this strategy will also give better application performance to me, the famous win-win situation (or assumption). But there are also counter-examples: If I am a mobile subscriber, my mobile network operator might be tempted to say (for the P2P use case): any destination peer outside of my network is better than pushing the same data twice through my radio access network, to a another customer in my network running the P2P application. If the ALTO server gives such simplistic guidance (low preference for local network prefixes, uniformly higher preference for all other prefixes), I might end up contacting a mobile user in a different part of the world, thus going through 2 wireless links plus a transcontinental link. So, multi-domain optimization might be challenging. And I am still not so sure what are the domains in the multi-domain draft ... > 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. The notion of "more correct" is difficult as this indeed highly depends on the point of view. > 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. I agree. > > 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
Re: [alto] ALTO at IETF-108: Finishing the current milestones and discussion on re-chartering the WG
Hi Jan, Vijay, Martin, Thanks a lot for the guidance. It is extremely helpful. Please see below. On Sun, Jun 14, 2020 at 10:55 AM Jan Seedorf wrote: > Dear all, > > Martin (our new AD), Vijay and myself had some discussions on how to > generally move forward with the WG and how to plan the IETF-108 ALTO > session accordingly. We believe we should finalize the remaining > milestones (see https://tools.ietf.org/wg/alto/charters) by or at the > latest during the IETF-108 ALTO session. Our understanding is that > during the weekly meetings the remaining docs are making good progress > towards such finalization, so this goal should be realistic. > > I second that the authors finish all the outstanding drafts soon. > After IETF-108, we can either (gradually) close the WG or re-charter. In > both cases, there should be no need for an ALTO session at IETF meetings > to discuss progress on the currently chartered milestones. If still > needed, such progress can happen on the mailing list. > > ... > > b) 60 minutes for presentations and discussions on potentially > re-chartering the WG (as opposed to closing down the WG). > > We are soliciting presentations on re-charter proposals and thoughts. > There will be no time allocated for presentations on drafts that are not > currently a WG item. > > Needless to say, any thoughts on re-chartering are welcome on the > mailing list at any time. We hope for a fruitful discussion at the > online/virtual ALTO session at IETF-108 that will hopefully end up in > some form of consensus on how to move forward with the WG. > > Here is an initial list of items that I feel may help us to get discussions started. 1. HTTP/2(3) based subscription and updates The current incremental updates are based SSE, and now we have HTTP/2(3) to be used. Incremental updates are important and the idea of building on top of HTTP/2(3) was raised during IESG review. 2. Network query/flow algebra One lesson which I learned from an early discussion is that the system can be more flexible if it is based on a language. Recently, a framework called Flow Algebra is emerging and can serve as a generic framework to query and abstract generic network information. 3. Multi-resources abstraction for application-layer traffic optimization There is an early work from SZ, Tsinghua and CMCC on their design and initial deployment of functional networking, whose essence is to include other resources beyond networking resources to applications. CDNi can be considered as such an example as well. The emergence of edge computing further motivates the need. 4. Multi-domain information aggregation, proxy, broker, and transformation A common setting is that the traffic from a client to a server traverses multiple networks, and hence there are many use cases. Multiple early drafts proposed ideas to handle multi-domains. I believe that multi-domain is also a key next step from Ingmar's award slides. 5. Cellular network information exposure Tencent and CMCC have a draft on this topic. Sabine has a draft on this subject as well. One highly related effort is NEF in 5G. Mobile clients are becoming more common, and hence systematically integrating cellular network information exposure has many good use cases. Let me intentionally keep the list short to get the conversation started. We have about slightly more than one month to chat more. Richard - Vijay & Jan > > > ___ > 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] ALTO at IETF-108: Finishing the current milestones and discussion on re-chartering the WG
Dear all, Martin (our new AD), Vijay and myself had some discussions on how to generally move forward with the WG and how to plan the IETF-108 ALTO session accordingly. We believe we should finalize the remaining milestones (see https://tools.ietf.org/wg/alto/charters) by or at the latest during the IETF-108 ALTO session. Our understanding is that during the weekly meetings the remaining docs are making good progress towards such finalization, so this goal should be realistic. After IETF-108, we can either (gradually) close the WG or re-charter. In both cases, there should be no need for an ALTO session at IETF meetings to discuss progress on the currently chartered milestones. If still needed, such progress can happen on the mailing list. Accordingly, we plan the 100 minute online/virtual ALTO session at IETF-108 as follows: a) 40 minutes for presentations on the drafts that address the remaining milestones, after which we hopefully can move all of them to WGLC (if not already done before, e.g. as with the ALTO-CDNI draft which is past WGLC) b) 60 minutes for presentations and discussions on potentially re-chartering the WG (as opposed to closing down the WG). We are soliciting presentations on re-charter proposals and thoughts. There will be no time allocated for presentations on drafts that are not currently a WG item. Needless to say, any thoughts on re-chartering are welcome on the mailing list at any time. We hope for a fruitful discussion at the online/virtual ALTO session at IETF-108 that will hopefully end up in some form of consensus on how to move forward with the WG. - Vijay & Jan ___ alto mailing list alto@ietf.org https://www.ietf.org/mailman/listinfo/alto
