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. The text in 6.1. DSO Session Initiation seems rough to me, for a couple of > reasons. > > The client may perform as many DNS operations as it wishes using the > newly created DSO Session. Operations SHOULD be pipelined (i.e., the > > I don't understand why this would be a SHOULD. At least from the client's > perspective, it's not needed for interoperation. > > client doesn't need wait for a response before sending the next > message). The server MUST act on messages in the order they are > transmitted, but responses to those messages SHOULD be sent out of > order when appropriate. > > Is it correct to say that "responses to those messages SHOULD be sent when > they > become available, even if the responses are sent out of order"? If not, I'm > probably missing what "when appropriate" means. > > > Good points. I've made the following change: > > The client may perform as many DNS operations as it wishes using the > -newly created DSO Session. Operations SHOULD be pipelined (i.e., the > -client doesn't need wait for a response before sending the next message).. > +newly created DSO Session. When the > +client has multiple messages to send, it SHOULD NOT wait for each > response before sending the next message. > +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 > -responses to those messages SHOULD be sent out of order when appropriate.. > +when responses to those messages become available out of order, the server > +SHOULD NOT delay sending available responses in order to respond in order. > > "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. I'll clear now. Spencer
_______________________________________________ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
