Re: [DNSOP] Working Group Last Call for draft-ietf-dnsop-edns-chain-query

[Paul Vixie <[e-mail]>]

On Wednesday, November 11, 2015 03:56:31 PM Tony Finch wrote:
> Paul Vixie <[e-mail]> wrote:
> 
> > second, you can't send a burst of queries, as a validator. even apart
> > from the fact that any CNAME (RFC 2317 style) can add delegation points
> > that weren't at label boundaries in your original QNAME, and there can
> > be more than one of these, so you're not at RTT=1 or even RTT<=2, you're
> > at RTT>0 without knowing the upper bound...
> 
> You get the entire CNAME chain in the first RTT so you can validate all
> the links in the chain in the second RTT.

here, you appear to be planning for a stub validator, which makes RD=1 queries. in a 
recursive caching validator, it would only receive CNAME chains of length>1 for in-zone 
CNAME's or CNAME's that cross zones where both the source and destination zones are 
served by the authority server you happen to be speaking to at the moment. for RFC 2317 
that's almost never the case.

> 
> > ...you can't flood the channel.
> 
> In most cases this will be four or six concurrent queries which is hardly
> flooding the channel. ...

yes, that's flooding the channel. you're allowed one work-stream per query, in order that 
timeouts and other loss are only felt as backpressure by those apps who caused them.

> This is comparable to the TCP initial window or the
> burst of SYNs you get when a browser starts fetching a page full of
> images.
> 
> Browsers send a lot of concurrent queries. My experience with adns tells
> me that concurrent queries work nicely at volumes orders of magnitude
> bigger than we are considering here.

these aren't browsers, those aren't web servers, and i'm not talking about TCP.

> 
> If you already have a TCP channel open you can send all the queries with
> one write and they'll happily fit in a single segment.

i have no objection to multiple parallel outstanding upstream queries over a TCP stream.

-- 
P Vixie