Re: [DNSOP] Followup Discussion on TCP keepalive proposals

In your previous mail you wrote: > If you want to make the connections full-duplex instead of > half-duplex, you need to negotiate connection teardown at the DNS > layer. Otherwise, the TCP connection teardown will result in loss of > already-transmitted responses. => I don't understand: to

Re: [DNSOP] Followup Discussion on TCP keepalive proposals

> On 31 Jan 2015, at 16:56, Florian Weimer wrote: > > If you want to make the connections full-duplex instead of > half-duplex, you need to negotiate connection teardown at the DNS > layer. Otherwise, the TCP connection teardown will result in loss of > already-transmitted responses. This is w

Re: [DNSOP] Followup Discussion on TCP keepalive proposals

> Why do you think this? RFC 103[45] has client initiated shutdown. > The client sends out x queries withe unique ids. It waits for > responses to all of them. It then closes the connection. The > client still has to cope with the connection being closed early. Indeed. Please let's not go down

Re: [DNSOP] Followup Discussion on TCP keepalive proposals

In message <878ugidh2g@mid.deneb.enyo.de>, Florian Weimer writes: > * John Heidemann: > > > DNS over TCP/53 is *already* persistent. No *protocol* changes are > > needed. > > If you want to make the connections full-duplex instead of > half-duplex, you need to negotiate connection teardown

Re: [DNSOP] Followup Discussion on TCP keepalive proposals

* John Heidemann: > DNS over TCP/53 is *already* persistent. No *protocol* changes are > needed. If you want to make the connections full-duplex instead of half-duplex, you need to negotiate connection teardown at the DNS layer. Otherwise, the TCP connection teardown will result in loss of alre

Re: [DNSOP] Followup Discussion on TCP keepalive proposals

> Francis Dupont > Wednesday, January 28, 2015 5:19 AM > In your previous mail you wrote: > >> Francis, while my own thinking goes further-- an initiator should >> not leave a persistent TCP session idle, even for a microsecond, >> unless the responder has s

Re: [DNSOP] Followup Discussion on TCP keepalive proposals

In your previous mail you wrote: > Francis, while my own thinking goes further-- an initiator should > not leave a persistent TCP session idle, even for a microsecond, > unless the responder has signaled its approval of such strategy-- => it is what RFC 1035 said so a bit difficult to change

Re: [DNSOP] Followup Discussion on TCP keepalive proposals

John Heidemann wrote: > If adns does pipelining over its TCP connection, does it handle > reordered replies? Yes, it has done for ever. > Do you have any comments on the successful use of TCP with adns > initiators to other responders? How many responders keep your TCP > connection on and actu

Re: [DNSOP] Followup Discussion on TCP keepalive proposals

> Francis Dupont > Tuesday, January 27, 2015 4:06 AM > ... > > Now about the DNS over TCP scaling issue: as I said at the last meeting > DNS over TCP won't scale until servers will be allowed to use any > timeout they want, including a zero timeout (which means

Re: [DNSOP] Followup Discussion on TCP keepalive proposals

On Mon, 26 Jan 2015 14:58:47 +, Tony Finch wrote: >Paul Vixie wrote: >> >> the installed initiator base does not use pipelining, ever. > >adns has done since 1999. Great! Running code should say a lot. Two questions for folks with adns experience: If adns does pipelining over its TCP conn

Re: [DNSOP] Followup Discussion on TCP keepalive proposals

In your previous mail you wrote: > If you see a use case for the EDNS tcp-keepalive option as originally > discussed, please say so, on the list, by February 4, 2015. => I have one (more later). > If you want to pursue the connection-close draft, please say so, on the > list, by February

Re: [DNSOP] Followup Discussion on TCP keepalive proposals

Paul Vixie wrote: > > > adns has done since 1999. > > in glibc, adns provides the gethostby*() interface and similar, No, adns has nothing to do with the glibc resolver. > are you saying that some important apps use the former, or are you > saying that adns has a socket pool shared amongst multi

Re: [DNSOP] Followup Discussion on TCP keepalive proposals

> Tony Finch > Monday, January 26, 2015 1:42 AM > > ["transport encoding" of "deflate"] doesn't help with HTTP's header > overhead, nor will it help with > expansion due to textual instead of binary crypto blobs. makes sense. -- Paul Vixie ___

Re: [DNSOP] Followup Discussion on TCP keepalive proposals

> Tony Finch > Monday, January 26, 2015 6:58 AM > > adns has done since 1999. in glibc, adns provides the gethostby*() interface and similar, but also offers its own asynch API. i believe that most apps in the world use the latter, which is synchronous. are you saying that

Re: [DNSOP] Followup Discussion on TCP keepalive proposals

Paul Vixie wrote: > > the installed initiator base does not use pipelining, ever. adns has done since 1999. Tony. -- f.anthony.n.finchhttp://dotat.at/ Lundy, Fastnet, Irish Sea: Northwest backing southwest 4 or 5, occasionally 6 at first in Irish Sea. Slight or moderate in Irish Sea, otherw

Re: [DNSOP] Followup Discussion on TCP keepalive proposals

Paul Vixie wrote: > > Tony Finch > > Saturday, January 24, 2015 5:09 PM > > > > Sorry, I was being too terse. I meant extra latency due to the time > > taken to transmit all that redundant data. > > isn't that what "transport encoding" of "deflate" is meant for? That doesn'

Re: [DNSOP] Followup Discussion on TCP keepalive proposals

TL;DR: i'd like to only behave differently if the other side signals its readiness for it. in a "big TCP" model where thousands or tens of thousands of sessions remain open while idle (even if only for a few seconds), we are asking for application, library, kernel, RAM, CPU, and firewall conditions

Re: [DNSOP] Followup Discussion on TCP keepalive proposals

On 25Jan15, John Heidemann allegedly wrote: > I think these statements are both overly strong. They both suggest > that careful signaling is required before deploying DNS over TCP with > pipelining or > persistence. If virtually no initiators send multiple requests then your conclusion seems re

Re: [DNSOP] Followup Discussion on TCP keepalive proposals

On Sun, 25 Jan 2015 09:44:24 +1100, Mark Andrews wrote: > >In message <54c40d28.7050...@redbarn.org>, Paul Vixie writes: >> > Mark Andrews >> > Thursday, January 22, 2015 6:29 PM >> > In message <32707.1421975...@dash.isi.edu>, John Heidemann writes: >> >> ... >> >> I'm conf

Re: [DNSOP] Followup Discussion on TCP keepalive proposals

> Tony Finch > Saturday, January 24, 2015 5:09 PM > > Sorry, I was being too terse. I meant extra latency due to the time taken > to transmit all that redundant data. isn't that what "transport encoding" of "deflate" is meant for? -- Paul Vixie __

Re: [DNSOP] Followup Discussion on TCP keepalive proposals

In message <54c424f2.4020...@redbarn.org>, Paul Vixie writes: > > > Mark Delany > > Saturday, January 24, 2015 2:09 PM > > On 24Jan15, Paul Vixie allegedly wrote: > > > >> could violate older implementations' reasonable-at-the-time assumptions, > >> against the burde

Re: [DNSOP] Followup Discussion on TCP keepalive proposals

Paul Vixie wrote: > > i don't think there's any real time (measurable) difference in > serialization (and deserialization) latency. Sorry, I was being too terse. I meant extra latency due to the time taken to transmit all that redundant data. Tony. -- f.anthony.n.finchhttp://dotat.at/ Bisca

Re: [DNSOP] Followup Discussion on TCP keepalive proposals

In message <54c4267a.9030...@redbarn.org>, Paul Vixie writes: > > Mark Andrews > > Saturday, January 24, 2015 2:44 PM > > In message <54c40d28.7050...@redbarn.org>, Paul Vixie writes: > > Pipeling over UDP has been standard practice between nameservers for > > 25 years. Why

Re: [DNSOP] Followup Discussion on TCP keepalive proposals

In message <20150124220926.82207.qm...@f5-external.bushwire.net>, "Mark Delany" writes: > On 24Jan15, Paul Vixie allegedly wrote: > > > could violate older implementations' reasonable-at-the-time assumptions, > > against the burden of choosing a non-interfering signal pattern, like a > > new por

Re: [DNSOP] Followup Discussion on TCP keepalive proposals

> Mark Andrews > Saturday, January 24, 2015 2:44 PM > In message <54c40d28.7050...@redbarn.org>, Paul Vixie writes: > Pipeling over UDP has been standard practice between nameservers for > 25 years. Why are we even worrying about whether it should be > permitted over TCP?

Re: [DNSOP] Followup Discussion on TCP keepalive proposals

> Mark Delany > Saturday, January 24, 2015 2:09 PM > On 24Jan15, Paul Vixie allegedly wrote: > >> could violate older implementations' reasonable-at-the-time assumptions, >> against the burden of choosing a non-interfering signal pattern, like a >> new port number, o

Re: [DNSOP] Followup Discussion on TCP keepalive proposals

In message <54c40d28.7050...@redbarn.org>, Paul Vixie writes: > > Mark Andrews > > Thursday, January 22, 2015 6:29 PM > > In message <32707.1421975...@dash.isi.edu>, John Heidemann writes: > >> ... > >> I'm confused. I thought we agreed the installed base doesn't do TCP > >

Re: [DNSOP] Followup Discussion on TCP keepalive proposals

On 24Jan15, Paul Vixie allegedly wrote: > could violate older implementations' reasonable-at-the-time assumptions, > against the burden of choosing a non-interfering signal pattern, like a > new port number, or a new protocol verb. Does it have to be that drastic? Wouldn't an EDNS option "I under

Re: [DNSOP] Followup Discussion on TCP keepalive proposals

> Tony Finch > Friday, January 23, 2015 10:35 AM > > Paul Vixie wrote: > > > why aren't we preferring a TCP/80 (and perhaps TCP/443) solution > > Inefficient encoding > -> wastes battery > -> greater serialization latency i see your point about battery, and i hadn't consi

Re: [DNSOP] Followup Discussion on TCP keepalive proposals

> Mark Andrews > Thursday, January 22, 2015 6:29 PM > In message <32707.1421975...@dash.isi.edu>, John Heidemann writes: >> ... >> I'm confused. I thought we agreed the installed base doesn't do TCP >> pipelining basically ever. > > The installed base has supported pipelin

Re: [DNSOP] Followup Discussion on TCP keepalive proposals

Paul Vixie wrote: > > why aren't we preferring a TCP/80 (and perhaps TCP/443) solution Inefficient encoding -> wastes battery -> greater serialization latency In-order responses -> head-of-line blocking Tony. -- f.anthony.n.finchhttp://dotat.at/ Wight, Portland: Southwest veering northw

Re: [DNSOP] Followup Discussion on TCP keepalive proposals

In message <32707.1421975...@dash.isi.edu>, John Heidemann writes: > > [Warning to rubberneckers: seems like at least two topics here: about > the spec and about TCP as a DoS.] > > On Wed, 21 Jan 2015 14:29:22 -0800, Paul Vixie wrote: > ># > >John Heidemann > >Wednesday, January 21

Re: [DNSOP] Followup Discussion on TCP keepalive proposals

[Warning to rubberneckers: seems like at least two topics here: about the spec and about TCP as a DoS.] On Wed, 21 Jan 2015 14:29:22 -0800, Paul Vixie wrote: ># >John Heidemann >Wednesday, January 21, 2015 1:53 PM >On Wed, 21 Jan 2015 09:30:44 +, Ray Bellis wrote: > >

Re: [DNSOP] Followup Discussion on TCP keepalive proposals

On Wed, 21 Jan 2015 16:58:32 -0500, Christopher Morrow wrote: >On Wed, Jan 21, 2015 at 4:53 PM, John Heidemann wrote: >> I don't see how DoS is an argument against TCP for DNS. (Unless one >> assumes hardware and software at the servers is fixed to something like >> 2004 standards.) What am I m

Re: [DNSOP] Followup Discussion on TCP keepalive proposals

> John Heidemann > Wednesday, January 21, 2015 1:53 PM > On Wed, 21 Jan 2015 09:30:44 +, Ray Bellis wrote: > > I want to restate this, because people often confuse current practice > with current specifications: > > DNS over TCP/53 is *already* persistent. No *protocol*

Re: [DNSOP] Followup Discussion on TCP keepalive proposals

On Wed, Jan 21, 2015 at 4:53 PM, John Heidemann wrote: > I don't see how DoS is an argument against TCP for DNS. (Unless one > assumes hardware and software at the servers is fixed to something like > 2004 standards.) What am I missing? What's the average client load expected (number of unique

Re: [DNSOP] Followup Discussion on TCP keepalive proposals

On Wed, 21 Jan 2015 09:30:44 +, Ray Bellis wrote: > >> i realize that "no" votes aren't counted. but that's going to be my input if >> any document along the lines of adding persistence to tcp/53 is adopted by >> the WG. so, for full disclosure, i wanted to weigh in at this stage. > >TCP/53

Re: [DNSOP] Followup Discussion on TCP keepalive proposals

Paul Wouters wrote: > > responders do not need to be upgraded for this, as we found out on this > list about two years ago when Mark Andrews patched dig and I ran a test > with that. Not entirely true. Persistent TCP works but it needs some performance engineering. Responders need to be upgraded

Re: [DNSOP] Followup Discussion on TCP keepalive proposals

> Paul Wouters > Wednesday, January 21, 2015 8:38 AM > On Wed, 21 Jan 2015, Paul Vixie wrote: > >> even if changing TCP/53's connection semantics could be done without >> creating new DoS vectors, the small number of DNS TCP initiators and >> responders who will ever be up

Re: [DNSOP] Followup Discussion on TCP keepalive proposals

On Wed, 21 Jan 2015, Paul Vixie wrote: even if changing TCP/53's connection semantics could be done without creating new DoS vectors, the small number of DNS TCP initiators and responders who will ever be upgraded responders do not need to be upgraded for this, as we found out on this list abo

Re: [DNSOP] Followup Discussion on TCP keepalive proposals

> Ray Bellis > Wednesday, January 21, 2015 1:30 AM > > TCP/53 is already persistent, it just happens most clients don't take > advantage of that feature. if they did, then those initiators would either be a DoS from the responder's point of view, or a DoS from

Re: [DNSOP] Followup Discussion on TCP keepalive proposals

On Tue, 20 Jan 2015, Paul Vixie wrote: my input is not a direct answer to either question, but, may be relevant. my view is: we can't reliably signal this capability, so any option we pursue will create a DoS vector for either new or old initiators or responders, and the right answer is to purs

Re: [DNSOP] Followup Discussion on TCP keepalive proposals

I agree with Paul Hoffman. While I think draft-ietf-dnsop-edns-tcp-keepalive is good, even the simpler draft-bellis-dnsop-connection-close would be much better than the current situation, so I support its adoption. DW On Jan 20, 2015, at 11:21 AM, Paul Hoffman wrote: > On Jan 20, 2015, at 7:3

Re: [DNSOP] Followup Discussion on TCP keepalive proposals

> i realize that "no" votes aren't counted. but that's going to be my input if > any document along the lines of adding persistence to tcp/53 is adopted by > the WG. so, for full disclosure, i wanted to weigh in at this stage. TCP/53 is already persistent, it just happens most clients don't tak

Re: [DNSOP] Followup Discussion on TCP keepalive proposals

> Tim Wicinski > Tuesday, January 20, 2015 7:37 AM > ... > The chairs are wondering: > 1) if their is still have a need for such an option, and > > 2) if there is consensus on competing proposals. > > > If you see a use case for the EDNS tcp-keepalive option a

Re: [DNSOP] Followup Discussion on TCP keepalive proposals

On Jan 20, 2015, at 7:37 AM, Tim Wicinski wrote: draft-ietf-dnsop-edns-tcp-keepalive is a reasonable document, but draft-bellis-dnsop-connection-close achieves a great deal at a very low cost. If we drop draft-ietf-dnsop-edns-tcp-keepalive (which seems likely if the authors don't want to pursu

[DNSOP] Followup Discussion on TCP keepalive proposals

All Way back, we had a draft that was adopted by the working group on TCP Keepalives (draft-ietf-dnsop-edns-tcp-keepalive). Prior to IETF91, we received an alternative proposal that was then presented (draft-bellis-dnsop-connection-close). There was some discussion during the meeting, but