Re: [dnsext] draft-ietf-dnsext-dns-tcp-requirements-00 / a way forward

[Ray.Bellis@nominet.org.uk]

> So let's focus on TCP.
> 
> I fully support the idea of the draft, as already indicated.
> 
> And I fully support Michael in that we want to use "unmodified
TCP".

Indeed - modifying TCP itself is not (as far as I'm
concerned) on the table.

> But TCP has a lot of Options, and perhaps all commercial and
> open-source TCP stack implementations have a lot of tuning knobs
> to adjust parameters, enable/disable options and mechanisms, etc.
> -- that's particularly interesting for DNS server/resolver operators.
> Furthermore, the TCP (socket) API contains features that allow
> programmatic access to particular features, mechanisms and options
> of TCP -- how to best make use thereof is highly interesting for
> implementers of DNS software.

It certainly is.

FWIW, yesterday I performed some benchmark tests against
Bind 9.6.

Over TCP/IP I was able to do 3000 qps.  That
was with a brand new TCP connection for each query, with no parallelisation.
 The client code was literally:

while (1) {
  socket(...);
  connect(...);
  write(2 byte len);
  write(request)
  read(2 byte len);
  read(response);
  close();
}

The same server will do about 23000 qps over UDP.

Personally I think that TCP performance is pretty
good.  I expect that with more queries in flight at the same time
the effective performance might be double that at least.

[BTW, the TCP stack on the _server_ didn't suffer
at all, as it was the client end that was actively closing the connection.
 However the client very rapidly ran out of ephemeral ports because
of the quantity that were in TIME_WAIT state].

> The main reason for having this draft is the perceived unwillingness
> of various parties to implement/support/allow TCP as it was intended,
> a mandatory transport for DNS in case UDP does not suffice, in
> particular for packet size / fragmentation reasons.

Exactly, yes.

> We (or many of us) want to convince those parties posing obstacles
> to this use of TCP that their opposition is not justified, and that
> IMO cannot be done by a simple normative statement of "MUST"
for TCP.
> No, we need to provide arguments and show ways to mitigate the raised
> concerns!  Exploring the effects of TCP options and parameters
and
> giving recommendations to implementers and operators of how to use
TCP
> in the best possible manner seems the right way to achieve this goal.
> This should include concrete arguments for implementors and vendors
> of middleboxes that DNS over TCP is not evil.

This is what I've attempted to do already, but I accept
that it needs more work.

Mostly what I'd like to be able to do is dispel (or
at least mitigate) the FUD about TCP as a transport mechanism for DNS.

> If we can agree on this strategy, the draft has a chance to be
> amended and turned into a valuable document that gives enough
> concrete guidance to both implementers and operators to actually
> overcome the observed reservedness against the TCP support for
> DNS transactions as specified in STD 13 and STD 3.
> 
> Such exploration and elaboration should also better educate the
> WG on aspects of DNS transport, allowing it to perform -- in a
> second step then -- a more targeted evaluation of proposals for
> alternate DNS transport(s), and eventually make better informed
> decisions on how to proceed with new proposals to this end.
> 
> N.B.: The priority of dealing with possible signalling of Transport
> (and/or other feature) support in DNS servers may very well be made
> dependent on the outcome of the first steps above.
> 
> Can wee agree on this way forward?

This sounds sensible, although I would like to take
the counsel of those wiser to the ways of the IETF than I am.

At the very least, the idea of having a real expert
on TCP advise is very sensible.

kind regards,

Ray

-- 
Ray Bellis, MA(Oxon) MIET
Senior Researcher in Advanced Projects, Nominet
e: ray@nominet.org.uk, t: +44 1865 332211