[dnssd] Draft-ietf-dnsop-edns-tcp-keepalive and DNS Push Notifications

[Stuart Cheshire <[e-mail]>]

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: [e-mail]
> Subject: [dnssd] I-D Action: draft-ietf-dnssd-push-06.txt
> Date: 21 March 2016 at 16:58:41 Pacific Daylight Time
> To: [e-mail]
> 
> 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
> [e-mail]
> https://www.ietf.org/mailman/listinfo/dnssd