On Thu, Aug 2, 2018 at 9:39 AM, Spencer Dawkins at IETF < spencerdawkins.i...@gmail.com> wrote:
> Hi, Ted, > > Chopping down to clearing my Discuss, and one wording suggestion for new > text ... > > On Tue, Jul 31, 2018 at 1:41 PM Ted Lemon <mel...@fugue.com> wrote: > >> On Jul 27, 2018, at 12:33 AM, Spencer Dawkins < >> spencerdawkins.i...@gmail.com> wrote: >> >> I really like this document, and think it's headed the right direction. Of >> course I have four pages of comments, because reasons, but the only part >> I'm >> really confused about is this one ... >> >> I would have thought that if you end up with a different endpoint because >> your >> anycast address now resolves differently, the new endpoint would have to >> have >> shared a lot of state with the previous endpoint, for this to work: >> >> When an anycast service is configured on a particular IP address and >> port, it must be the case that although there is more than one >> physical server responding on that IP address, each such server can >> be treated as equivalent. If a change in network topology causes >> packets in a particular TCP connection to be sent to an anycast >> server instance that does not know about the connection, the normal >> keepalive and TCP connection timeout process will allow for recovery. >> >> What I would have expected to happen, is that the new endpoint sees a >> packet >> arrive that's not on a synchronized TCP connection, and immediately >> responds >> with a RST (reset), rather than the normal keepalive and TCP connection >> timeout >> process happening. That's also the way I'm reading >> https://tools.ietf.org/html/rfc7828#section-3.6. Is that not the way it's >> working for anycast these days? >> >> >> I believe this is correct—thanks for pointing it out. I think the fix >> is straightforward: >> >> When an anycast service is configured on a particular IP address and >> port, it must be the case that although there is more than one >> physical server responding on that IP address, each such server can >> be treated as equivalent. If a change in network topology causes >> packets in a particular TCP connection to be sent to an anycast >> server instance that does not know about the connection, the new >> server will automatically terminate the connection with a TCP reset, >> since it will have no record of the connection, and then the client can >> reconnect or stop using the connection, as appropriate. >> >> Does that sound good? >> > > I'll clear based on this text, but you might want to consider being a bit > more precise about what you're thinking of, when you say "each such server > can be treated as equivalent", which, IIRC, was what started my journey > into the weeds on this paragraph. > > ISTM that there are two ways people could be using anycast > (overgeneralizing wildly) - > > - I have nine servers that are geographically close enough to maintain > TCP state across the set of servers and I'm using anycast for > loadbalancing, or > - I have nine servers that are geographically diverse, and I'm using > anycast to provide more robust service, and they're not close enough to > maintain TCP state across the set of servers. > > I think your point is that the first case is fine (a change in network > topology means that the server now being used either knows or can figure > out quickly that to do with the incoming packet), and the second case is > not (a change in network topology means that the server being used has no > idea what to do with the incoming packet, and has no way to figure that > out). > > If I got that right (at a 50,000 foot level), you might think about how to > say it more correctly, but I'm clearing now, so do the right thing. > When an anycast service is configured on a particular IP address and port, it must be the case that although there is more than one physical server responding on that IP address, each such server can be treated as equivalent. +What we mean by "equivalent" here is that both servers can provide the +same service and, where appropriate, the same authentication information, +such as PKI certificates, when establishing connections. + +In principle, anycast servers could maintain sufficient state that they can both handle packets +in the same TCP connection. In order for this to work with DSO, they would need to also share +DSO state. It is unlikely that this can be done successfully, however, so we recommend that +each anycast server instance maintain its own session state. + If a change in network topology causes packets in a particular TCP connection to be sent to an anycast server instance that does not know about the connection, the new > > "in order to respond in order" is kind of clunky. Perhaps "SHOULD NOT > delay sending responses so that they can be returned in the order the > corresponding requests were received"? > > But do the right thing, of course. > How's this: This prevents TCP's delayed acknowledgement algorithm from forcing the client into a slow lock-step. The server MUST act on messages in the order they are transmitted, but -when responses to those messages become available out of order, the server -SHOULD NOT delay sending available responses to respond in order. +SHOULD NOT delay sending responses to those messages as they become available in +order to return them in the order the requests were received. {{?RFC7766}} section 3.3 specifies this in more detail. > I'll clear now. > Thanks, and thanks for the thoughtful review!
_______________________________________________ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
