[e2e] Early FIN/close for query-response TCP connections like DNS's

[Stefanos Harhalakis]

Hello,

On Thursday 14 of October 2010, Alfred HÎnes wrote:
> On Thu Oct 14 02:34:15 PDT 2010, Stefanos Harhalakis wrote:
> > On Wednesday 13 of October 2010, Alfred HÎnes wrote:
> >> For instance, an end-system resolver (or a DNS forwarder, e.g. in an
> >> access gateway) that is configured with a single recursive resolver,
> >> to which it will forward all queries, should preferably keep a TCP
> >> connection open for considerable time, ideally forever.
> > 
> > This should only apply whenever a stub resolver is involved. If it
> > isn't or the client API directly contacts the DNS server (like in
> > linux systems without  nscd running) then it is not possible to use
> > this kind of keep-alived connections (no?).
> 
> Most clients -- be they application-based or host-based -- will likely
> talk to a *single* recursive resolver all the time (the one they have
> been configured with via DHCP or PPP[oE], or via static configuration),
> and not to the different authoritative resolvers directly;
> debugging tools like dig are an exception, of course.

Indeed, but the persistent connection may only be used when there is a stub 
resolver running at client-side (For example, you cannot share a TCP 
connection to the DNS server between two clients like Firefox and IE) (this is 
the host-based client you're referring).

> > In that case the client may not benefit from an open connection (e.g.
> > when running "dig") or it is not aware of using TCP.  I believe that
> > this is the case of most implementations that use gethostbyname() (or
> > similars) without using sethostent(1).  Since gethostbyname() will
> > retry using TCP whenever the UDP query was truncated and then close
> > the connection, the early FIN would work there.
> 
> That are per-platform implementation details.

AFAIK, all DNS resolver implementations out there will retry with TCP whenever 
they receive a truncated reply. (No?). I was referring to that, which is not 
platform-specific. gethostbyname() was just an example.

> > The server-side implementation only needs to test the socket for
> > reading ...
> 
>   ... and exceptions! -- receipt of a FIN should perhaps be acted upon
>   quickly!  (Of course, the details depend on the API.)

AFAIK a FIN is not considered an exception. I believe that only URG data are 
considered an exception. At least that's what I've seen when using sockets in 
a couple of Unix OSs and from what is mentioned in various TCP-related mailing 
lists.

> No, but as you have already observed, it depends on the circumstances
> what behavior would be regarded as "optimal" (in some sense).
> A per-host stub resolver, a browser's DNS helper, a small company
> recursive server, a big ISP recursive resolver with many anycast
> replicas, a DNSSEC-validating resolver, a company's authoritative
> server, a large registry's server, ... -- they all will have different
> views of what is "optimal".

Exactly. No argue!

> That's why details in DNS client behavior like what you are
> considering are not standardized.

Exactly^2. That's why I mentioned that as a proposal/guideline which may be 
followed under certain circumstances only, from willing clients only. IOW, 
when it makes sense.

> Note that the RTT of a truncated DNS response that then causes
> the setup of a TCP connection also introduces delay.  The overhead
> amortization over multiple queries is a real advantage -- think of
> an application using service discovery: pick up NAPTRs, then SRVs,
> then address RRs -- all likely served by the same authority; if
> not in cache, there will be bursts of lookups.

Yeap. That's why I was referring only to one-query connections. Most of the 
time, the client already knows whether there is just one query or not (e.g. 
when using gethostbyname() there is always only one query per TCP connection).

> If you are interested in extreme optimization for transactional
> usage of TCP, please wait for the Experimental RFC(-to-be) 6013,
> "TCP Cookie Transactions", to be published soon (maybe next week)
> on the Independent Submission stream or look at the draft for it,
> draft-simpson-tcpct-03 !

I'll. Thanks!