My bad about the subject lines, apologies for that and changed to continue this discussion.
The short answer to your (big) question is 'yes, I do see that applications are willing and able to provide such indications'. But let me tease this apart. On affinity, there are three questions to answer: 1. do we want/need it? 2. what is the application's role in it? 3. where shall we consider it (in the architecture)? As for item 1: If we didn't have affinity support, an anycast environment, blissfully unaware of affinity, may make packet-level decisions on steering packets to one of the possibly many choices and, more importantly, may change that choice during the affinity (it is not aware of). One could envision solutions (at app level) that dealt with putting pieces of such 'shredded' transactions together, e.g., within a single DC using some shared data layer of sort, but when thinking about multi-site deployments, I'm at loss how to deal with it. This leads me to conclude that affinity is a problem we should care about. As for item 2: this goes to your question, i.e., are application willing to provide such indication. I'd argue that they already do: they resolve a name, establish a transport connection, send data/requests, and tear it down. They may resolve again, usually being served with a cached copy or forcing a new resolution, and go again. That's an indication quite common as a pattern in applications to delimit transactions. As for item 3: as it may come across in the draft, we are arguing that it should be considered in the endpoint since it is the best point in the arch doing the indication (and is already doing it, see item 2). In addition, in our user space socket library prototype for ROSA, the app may also just 'reset' the socket instead of fully closing it, more actively signaling the affinity. Do I see this as additional complexity? Not really, to be honest, since it aligns with how the use of sockets maps onto a relation to a service endpoint, so it's more or less preserving that view at the application, only adding an efficiency shortcut in the aforementioned 'reset' socket option. One could consider doing this in the network. But firstly, you still need the application indication of sort, otherwise what information would you act on? So you start putting, e.g., transport identifiers of sort, together with client identifiers (e.g., IP address) in some tuples and manage the 'flow' representing the transaction in an edge/network element. We describe this in the gap analysis. First problem is that all packets now need to consider that state and thus need to traverse the same ingress to do so. Second problem, to me, lies in the E2E argument: I prefer little to no network state for something that the endpoint could do. ROSA is meant to show that it goes without, handling the transaction affinity in the endpoints. But the basis for all is that applications can provide such indications, which I argue they already do in many cases, without causing complexity or too much burden on them. They may do those indications more fine grained, if they desire support for more fine grained decisions, in which case I see applications as being designed for 'ROSA-like' environment - effectively just delimiting their transaction with a socket reset call. Best, Dirk -----Original Message----- From: Joel Halpern <[email protected]> Sent: 27 June 2023 20:03 To: Dirk Trossen <[email protected]>; Eric Vyncke (evyncke) <[email protected]>; RTGWG <[email protected]> Cc: [email protected] Subject: Re: [Rosa] New Version Notification for draft-mendes-rtgwg-rosa-use-cases-00.txt (It took me a minute to find this to respond, as you left the old subject line in place.) The most interesting thing I can see in the gap analysis is the expectation that applications will explicitly indicate the affinity grouping of packets. I can understand wanting such, although there is a complexity cost in doing that. But the bigger question I see is whether there is any indication that applications are willing and able to provide such indications. Yours, Joel On 6/27/2023 3:33 AM, Dirk Trossen wrote: > Dear all, > > This is to announce (to the dedicated ROSA list and the wider RTG WG list) > that we have now submitted the gap analysis and requirements as well as the > arch draft for ROSA as companion documents to the already submitted use cases > and problem statement draft. > > The gap analysis draft includes a more comprehensive analysis of other > works compared to the previous standalone draft, including the > question that Eric raised in CATS. The drafts are available at > > https://datatracker.ietf.org/doc/draft-contreras-rtgwg-rosa-gaar/ > https://datatracker.ietf.org/doc/draft-trossen-rtgwg-rosa-arch/ > > Any comments and thoughts are welcome on either mailing list; for a wider > discussion, using the ROSA list may help limiting traffic on the RTG WG list. > > Thanks, > > Dirk (on behalf on the co-authors) > > -----Original Message----- > From: Eric Vyncke (evyncke) <[email protected]> > Sent: 26 June 2023 17:43 > To: Dirk Trossen <[email protected]>; RTGWG <[email protected]> > Subject: Re: New Version Notification for > draft-mendes-rtgwg-rosa-use-cases-00.txt > > Hello Dirk, > > Obviously writing this email without any hat, I did not find any reference to > the CATS WG [1] in the ROSA draft. While CATS has already a good direction on > what to do, it seems to me that ROSA and CATS are addressing very similar > problems. > > Do you intend to work within the CATS WG ? Else, what are the big differences > ? > > Regards and thanks for educating me, > > -éric > > [1] https://datatracker.ietf.org/wg/cats/about/ > > > On 26/06/2023, 16:08, "rtgwg on behalf of Dirk Trossen" > <[email protected] <mailto:[email protected]> on behalf of > [email protected] > <mailto:[email protected]>> wrote: > > > Dear all, > > > Please find below the link to our submission of the ROSA use cases and > problem statement draft. This draft has been split out of the originally > single ROSA draft and is now revised in the use cases and includes, as the > title suggests, the suggested problem statement for ROSA, replacing thus the > longer draft originally submitted and presented to the RTG WG during IETF115 > and 116. > > > We plan on submitting the separate gap analysis and requirements as well as > the architecture drafts tomorrow. > > > We would welcome any comments from your side on this update, specifically on > the use cases, the observed pain points and derived issues as well as the > problem statement. For the discussions around ROSA and its related drafts, a > non-WG mailing list at [email protected] <mailto:[email protected]> has been > established. Please use this list for your comments so as to reduce traffic > from the wider RTG WG list. In case you have not yet subscribed to this new > list, we'd welcome you doing so! > > > Looking forward to receiving your comments! > > > Best, > > > Dirk (on behalf of the co-authors) > > > -----Original Message----- > From: [email protected] <mailto:[email protected]> > <[email protected] <mailto:[email protected]>> > Sent: 26 June 2023 15:53 > To: Luis M. Contreras <[email protected] > <mailto:[email protected]>>; Dirk Trossen > <[email protected] <mailto:[email protected]>>; Jens > Finkhaeuser <[email protected] <mailto:[email protected]>>; Luis > Contreras <[email protected] > <mailto:[email protected]>>; Paulo Mendes > <[email protected] <mailto:[email protected]>> > Subject: New Version Notification for > draft-mendes-rtgwg-rosa-use-cases-00.txt > > > > > A new version of I-D, draft-mendes-rtgwg-rosa-use-cases-00.txt > has been successfully submitted by Dirk Trossen and posted to the IETF > repository. > > > Name: draft-mendes-rtgwg-rosa-use-cases > Revision: 00 > Title: Use Cases and Problem Statement for Routing on Service > Addresses Document date: 2023-06-26 > Group: Individual Submission > Pages: 33 > URL: > https://www.ietf.org/archive/id/draft-mendes-rtgwg-rosa-use-cases-00.t > xt > <https://www.ietf.org/archive/id/draft-mendes-rtgwg-rosa-use-cases-00. > txt> > Status: > https://datatracker.ietf.org/doc/draft-mendes-rtgwg-rosa-use-cases/ > <https://datatracker.ietf.org/doc/draft-mendes-rtgwg-rosa-use-cases/> > Htmlized: > https://datatracker.ietf.org/doc/html/draft-mendes-rtgwg-rosa-use-case > s > <https://datatracker.ietf.org/doc/html/draft-mendes-rtgwg-rosa-use-cas > es> > > > > > Abstract: > The proliferation of virtualization, microservices, and serverless > architectures has made the deployment of services possible in more > than one network location, alongside long practised replication within > single network locations, such as within a CDN datacentre. > This necessitates the potential need to coordinate the steering of > (client-initiated) traffic towards different services and their > deployed instances across the network. > > > The term 'service-based routing' (SBR) captures the set of mechanisms > for said traffic steering, positioned as an anycast problem, in that > it requires the selection of one of the possibly many choices for > service execution at the very start of a service transaction, followed > by the transfer of packets to that chosen service endpoint. > > > This document provides typical scenarios for service-based routing, > particularly for which a more dynamic and efficient (in terms of both > latency and signalling overhead) selection of suitable service > execution endpoints would not exhibit the overheads and thus latency > penalties experienced with existing explicit discovery methods. > Related drafts introduce the design for an in-band service discovery > method instead, named Routing on Service Addresses (ROSA), based on > the insights from the use case and problem discussion in this draft. > > > > > > > > > The IETF Secretariat > > > > > > > _______________________________________________ > rtgwg mailing list > [email protected] <mailto:[email protected]> > https://www.ietf.org/mailman/listinfo/rtgwg > <https://www.ietf.org/mailman/listinfo/rtgwg> > > > _______________________________________________ rtgwg mailing list [email protected] https://www.ietf.org/mailman/listinfo/rtgwg
