Dear Keepalive authors, Draft-ietf-dnssd-push-06 (see below) references draft-ietf-dnsop-edns-tcp-keepalive.
However, at present, a more accurate title might be “draft-ietf-dnsop-edns-tcp-idle-timeout” instead of “draft-ietf-dnsop-edns-tcp-keepalive”, because while it tells the client how to learn what the idle timeout is, it doesn’t say anything about what the client does to actually keep a connection alive. Draft-ietf-dnssd-push-06 currently has the text included below. 1. It states what actions reset the idle timer. 2. It states that the client should send keepalive traffic before the idle timeout expires, but the server should not kill a connection until 1.5x the idle timeout, to allow for clock rate differences and propagation delays. 3. Particularly note the final paragraph, which calls for suggestions for a specified keepalive action. At both servers and clients, the generation or reception of any request, response, update, or keepalive message resets the keepalive timer for that connection. In the absence of any requests, responses, or update messages on a connection, a client MUST generate keepalive traffic before the idle timeout expires, or the server is entitled to close the connection. If a client disconnects from the network abruptly, without closing its connection, the server learns of this after failing to receive further traffic from that client. If no requests, responses, update messages or keepalive traffic occurs on a connection for 1.5 times the idle timeout, then this indicates that the client is probably no longer on the network, and the server SHOULD abort the connection with a TCP RST. [We need to discuss the nature of "the required keepalives". Are they TCP-layer keepalives? DNS-layer keepalives? There is currently no DNS-layer keepalive or 'no-op' operation defined. What would that operation be? A DNS QUERY containing zero questions? A DNS SUBSCRIBE containing zero questions? An "empty" DNS message over the TCP connection (just a pair of zero bytes, signifying a zero-length message)? One benefit of TCP-layer keepalives is that they transmit fewer bytes, and involve less software overhead for processing those bytes. Another benefit is that it is more feasible to implement these in networking offload hardware, which can allow devices to meet their TCP keepalive obligations while sleeping. This is particularly important for battery-powered devices like mobile phones and tablets. On the other hand, using TCP-layer keepalives requires an API for a client to tell the networking stack at what frequency to perform TCP- layer keepalives, and an API for a server to request the networking stack to inform it when TCP-layer keepalives are not received by the required deadline. TCP-layer keepalives also only verify liveness of the remote networking stack, whereas DNS-layer keepalives provide higher assurance of liveness of the remote server application software -- though this a limited benefit, since there is no reason to expect that DNS Push Notification server software will routinely become wedged and unresponsive.] I could define this specified keepalive action in the DNS Push document, but I think it would be better to have that specification in the keepalive document. Thoughts? Stuart Cheshire Begin forwarded message: > From: internet-dra...@ietf.org > Subject: [dnssd] I-D Action: draft-ietf-dnssd-push-06.txt > Date: 21 March 2016 at 16:58:41 Pacific Daylight Time > To: i-d-annou...@ietf.org > > A New Internet-Draft is available from the on-line Internet-Drafts > directories. > This draft is a work item of the Extensions for Scalable DNS Service > Discovery of the IETF. > > Title : DNS Push Notifications > Authors : Tom Pusateri > Stuart Cheshire > Filename : draft-ietf-dnssd-push-06.txt > Pages : 31 > Date : 2016-03-21 > > Abstract: > The Domain Name System (DNS) was designed to return matching records > efficiently for queries for data that is relatively static. When > those records change frequently, DNS is still efficient at returning > the updated results when polled. But there exists no mechanism for a > client to be asynchronously notified when these changes occur. This > document defines a mechanism for a client to be notified of such > changes to DNS records, called DNS Push Notifications. > > > The IETF datatracker status page for this draft is: > https://datatracker.ietf.org/doc/draft-ietf-dnssd-push/ > > There's also a htmlized version available at: > https://tools.ietf.org/html/draft-ietf-dnssd-push-06 > > A diff from the previous version is available at: > https://www.ietf.org/rfcdiff?url2=draft-ietf-dnssd-push-06 > > > Please note that it may take a couple of minutes from the time of submission > until the htmlized version and diff are available at tools.ietf.org. > > Internet-Drafts are also available by anonymous FTP at: > ftp://ftp.ietf.org/internet-drafts/ > > _______________________________________________ > dnssd mailing list > dn...@ietf.org > https://www.ietf.org/mailman/listinfo/dnssd _______________________________________________ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
