Re: Fwd: New Version Notification for draft-wouters-edns-tcp-keepalive-00.txt (fwd)

On 2013-10-18, at 06:40, Tony Finch <[email protected]> wrote:

> Joe Abley <[email protected]> wrote:
>> On 2013-10-17, at 13:16, Tony Finch <[email protected]> wrote:
>> 
>>> I am worried that this will make edns-tcp-keepalive clients perform
>>> unnecessarily badly when talking to RFC 5966 servers,
>> 
>> could you explain how?
> 
> An RFC 5966 server supports persistent TCP but does not advertise this
> fact.

I think we all agree on this.

> An edns-tcp-keepalive client interprets this lack of advertisement
> as lack of support, so it will send only one query per TCP connection.

What we're trying to optimise is

(a) the ability for a server to manage a finite resource (a TCP connection pool) in a way that is most likely to result in those sockets being well-used;

(b) the ability for a client who desires multiple exchanges over the same TCP socket to know what the timeout on the server is, so that it knows when to fall back to UDP.

In the case of a busy resolver (Google, OpenDNS, Comcast, whatever) sending regular and frequent queries to a busy server (one of the CO.UK servers, say) perhaps the "few seconds" timeout on the server is not an issue. But if the server has the resources to keep a TCP socket open to receive 0.3 queries per second from a particular resolver, the ability to use this signalling to extend the timeout on the server side allows multiple exchanges where normal behaviour (absent signalling) would not.

In the case of a mobile device sending less frequent queries to a resolver, the default TCP timeout on the server might well be a problem. A busy resolver might not be able to spare the resources to keep the socket open for such a client today, but the idea here is to think ahead to a world where TCP is not the exception to the rule and perhaps some of the scaling techniques used by web servers that can support orders of magnitude more concurrent TCP connections than most DNS servers do today.

Keeping the socket open on the server for a relatively low query rate from a resolver avoids the overhead of closing and reopening a TCP socket, and provides source address validation of the client, protecting it from collateral damage that might result from (e.g.) RRL.

I think the potential advantages are non-imaginary.

> This increases latency and means it can't make concurrent queries over TCP
> without multiple TCP connections, and for high query volumes it risks port
> exhaustion from all the FIN-WAIT-2 states. If you run the client in RFC
> 5966 mode then it will try persistent TCP regardless of what the server
> says and avoid these problems.

So the key observation here, if I'm reading it correctly, is that clients might reasonably try to re-use an open socket even if the edns-tcp-keepalive option is not present, anticipating a short (but not impossible) timeout on the server side.


Joe
_______________________________________________
dnsext mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/dnsext