On Thu, 07 Aug 2014 09:33:03 -0400, Joe Abley wrote:
>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.
>...
> 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.
We talk about anycast in Appendix H.1 of the tech report, and observe
that anycast is used for HTTP CDNs like Edgecast (see cite [13]).
Patrick Gilmore suggested Cloudflare and Cachefly also do this.
Since HTTP connections are already long lived, I think this suggests
that potential T-DNS connections that last tens of seconds will not be
horrible.
The important thing to think about are the implications of an anycast
route change during a live connection. With TLS the connection will be
torn down, since the new server will not have the same shared secret.
Clients already must recover TCP connections that are unexpectedly torn
down, so this is just another case that requires restart.
Will restart happen so often performance is impossibly bad? I think 3
commercial HTTP CDNs would suggest not! We have some data about anycast
and the roots (see Fan et al "Evaluating Anycast in the Domain Name
System", INFOCOM 2013)---I'll look if we can reanalyze that data to
characterize anycast stability.
It's also important that when DNS-over-TCP is having trouble because of
anycast route changes, DNS-over-UDP will also be less than happy. See
Labovitz et al's "Delayed {Internet} Routing Convergence" (SIGCOMM 2000)
for loss rates during route change. UDP will be MUCH more robust than
TCP because just one request and reply has to get through, but UDP too
will suffer. Anycast route change is perhaps good time for a client to
try out that secondary nameserver :-)
-John
_______________________________________________
dns-privacy mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/dns-privacy
