Hi Guangqing, On 7 August 2014 at 2:27:37, Guangqing Deng ([email protected]) wrote:
> So long the paper is and really excellent work it is. From this paper, it > seems that the > performance of TCP-based DNS is acceptable compared with UDP-based DNS. But > DNS operators > may still worry the performance of anycast which is used in root and many TLD > domains if > UDP is widely replaced by TCP. Do you have any plans on measuring the > performance of anycast > in TCP scenario? The general concern with non-stateless exchanges between a unicast host and an anycast host is that the routing system between the two may exhibit oscillations that cause different anycast hosts to receive different packets associated with the same transaction. This is more of a concern the longer the transaction, and the more turbulent the routing between the hosts concerned. (In general, I have yet to see a significant problem with half-open connections on anycast DNS servers with short-held TCP sessions.) In RFC 4786 we said: When a service is anycast between two or more nodes, the routing system makes the node selection decision on behalf of a client. Since it is usually a requirement that a single client-server interaction is carried out between a client and the same server node for the duration of the transaction, it follows that the routing system's node selection decision ought to be stable for substantially longer than the expected transaction time, if the service is to be provided reliably. Some services have very short transaction times, and may even be carried out using a single packet request and a single packet reply (e.g., DNS transactions over UDP transport). Other services involve far longer-lived transactions (e.g., bulk file downloads and audio- visual media streaming). Services may be anycast within very predictable routing systems, which can remain stable for long periods of time (e.g., anycast within a well-managed and topologically-simple IGP, where node selection changes only occur as a response to node failures). Other deployments have far less predictable characteristics (see Section 4.4.7). The stability of the routing system, together with the transaction time of the service, should be carefully compared when deciding whether a service is suitable for distribution using anycast. In some cases, for new protocols, it may be practical to split large transactions into an initialisation phase that is handled by anycast servers, and a sustained phase that is provided by non-anycast servers, perhaps chosen during the initialisation phase. One thing we proposed in draft-wouters-edns-tcp-keepalive was: Changes in network topology between clients and anycast servers may cause disruption to TCP sessions making use of edns-tcp-keepalive more often than with TCP sessions that omit it, since the TCP sessions are expected to be longer-lived. Anycast servers MAY make use of TCP multipath [RFC6824] to anchor the server side of the TCP connection to an unambiguously-unicast address in order to avoid disruption due to topology changes. This was a bit of a throwaway comment and deserves greater thought, but it's an example of how we could shoe-horn an initialisation phase into a long-lived (TCP) DNS transaction. Joe _______________________________________________ dns-privacy mailing list [email protected] https://www.ietf.org/mailman/listinfo/dns-privacy
