Subject: Re: [DNSOP] Review of edns-tcp-keepalive-01

From: Alexander Mayrhofer <[email-masked]>
Date: Thu, 22 Jan 2015 15:54:47 +0000

> * PROTOCOL: Is the expected behaviour (MUST) from both client and server
> that they should add the Option to every single request / response during a
> keepalive session? Please clarify the intended behaviour..

Two final comments, sorry:

* EDITORIAL/PROTOCOL: Shouldn't the option (as well as the draft) be renamed from "keepalive" to "timeout"? To my understanding "keepalive" would refer to a mechanism where "empty, ping style packets" would be used to keep the session established, and be misleading for a mechanism to negotiate timeout values... change to "edns-tcp-timeout" Option, and according draft name?

* PROTOCOL: Are there any race conditions when this Option is used in conjunction with Ray's "Connection Close" flag (https://tools.ietf.org/html/draft-bellis-dnsop-connection-close-00)? 

Alex

---

From: Tim Wicinski <[email-masked]>
Date: Thu, 22 Jan 2015 12:06:44 -0500

> * PROTOCOL: Are there any race conditions when this Option is used in conjunction with Ray's "Connection Close" flag (https://tools.ietf.org/html/draft-bellis-dnsop-connection-close-00)?

The two options are alternative proposals - there should never be a 
reality where both proposals exist as supported options.

tim

---

From: Andrew Sullivan <[email-masked]>
Date: Thu, 22 Jan 2015 12:16:41 -0500

On Thu, Jan 22, 2015 at 12:06:44PM -0500, Tim Wicinski wrote:
> 
> The two options are alternative proposals - there should never be a reality
> where both proposals exist as supported options.

Right.  The question is whether you think people are going to behave
well (which is more or less what Ray's proposal enables; the server if
under attack just closes its TCP anyway), or whether you prefer a
mechanism where the server gives hints that guide a client's behaviour.

I prefer the latter approach (which is what's in Paul's and Joe's
draft).  I think it provides data by which a server can develop
profiles of those requesters that reach it, and thereby make more
intelligent decisions about resource allocation.  But that would be
complicated and tricky, and Ray's proposal has the really notable
advantage that it's quite simple.  So I'd like one of these documents
to go ahead.

A

-- 
Andrew Sullivan
[email-masked]