Re: Last Call: <draft-ietf-httpbis-http2-16.txt> (Hypertext Transfer Pro

Subject: Re: Last Call: <draft-ietf-httpbis-http2-16.txt> (Hypertext Transfer 
Protocol version 2) to Proposed Standard Date: Sat, Jan 03, 2015 at 05:53:46PM 
+0100 Quoting Eliot Lear (lear(_at_)cisco(_dot_)com):
> Finally, to address Måns' comments, additional data for the target
> doesn't get signed (but correct me if I missed a change).  
My testing reveals that 

- if the Additional Data is signed, 

- if the answering name server holding the SRV record also holds authority
  over the records in the Target field of the queried SRV records,

..then the Additional data will be sent with RRSIG records. It
is, however, a common configuration of for instance NSD to use
"minimal-responses" setup wherein Additional is not sent even when it
would be possible. In that case, of course, the signatures won't get
sent, either.

Test case: 

dig @primary.se _kerberos._udp.besserwisser.org. SRV +dnssec

        (Server BIND 9, does send Additional. I did test on NSD too,
        and there no Additional is sent, on that particular server node.)

> And this leads us back to performance.  I personally do not have an
> answer for what acceptable performance is in these circumstances.  And
> so some experimentation would really REALLY be good.  Is 100 ms for this
> feature acceptable? 30? 80? 200?  I really can't say, and there was no
> desire in the WG to go this far.  I will say that Cisco has an open RFP
> for related work if any researchers want to take the challenge.[2]
So, what I'm reading here, paraphrased, can be rewritten, tongue-in-cheek
to "We are so certain SRV will take time compared to strange 4-hop CNAME
scenarios that we won't test it." ;-)

Back-of-envelope test: 

Since we've established, above, that Additional MAY be sent and that
some name servers do send it, we can test thusly:

        (I've got a local unbound on the node and the network latency
        is below 1 ms from my machine to the closest server so this is
        just processing delay variations)

for i in `seq 1 20` ; do
        unbound-control flush_zone kth.se > /dev/null 2>1
        dig kth.se A | awk '/Query\ time:/ { printf "A\t%d\n",$4; }'
        unbound-control flush_zone kth.se > /dev/null 2>1 
        dig _kerberos._udp.kth.se SRV |awk '/Query\ time:/ { printf 
"SRV\t%d\n",$4; }'
done

(now, don't go load KTH name servers too much, please.) 

I did a 50 each query run of the above and came up with data that looks
like it is no difference between A and SRV. Hardly surprising. I did
not ask with +dnssec, (kth.se is signed) but behaviour is identical and
there are no truncation issues, since the EDNS0 buffer goes up.

http://vvv.besserwisser.org/Public/Bilder/QTIME.spectrum.png

The cost of SRV vs the cost of A+CNAME thus seems to be entirely dependent
on how things are configured. Not on SRV /per se/. The guide lines for
SRV deployment are then identical to those for A/CNAME: "Do not make
yourself dependent on too many zones you do not control and/or serve and
please do pay attention to TTL".

The remaining question is then whether to ask for SRV first or not. (And
here is the real discussion on acceptable latency.  The rest is just
setting the scene.) 

I think Patrik had some pretty correct hand waving sentences :) on that,
but the main point is that I believe that we can be leaning on the
aggressive side when specifying, because the user-agent people will be
aggressive anyway. And the caching will mostly contain the eagerness. (As
a sysadmin, I'm usually more concerned over stupid caching in browsers
than lack of caching because of too short TTL. And I care for the
resolvers...) By aggressive I think we should emulate happy eyeballs,
probably starting off with SRV for what is written in the browser, falling
back to AAAA, then A queries for sought name, then www.name, etc. Timers
might be around 70% of the average query time last 100 DNS queries took..

Finally, I agree with Patrik that there needs to be text. I offer to
send text if there is agreement on trying to include such. 

-- 
Måns Nilsson     primary/secondary/besserwisser/machina
MN-1334-RIPE                             +46 705 989668
I want another RE-WRITE on my CEASAR SALAD!!

signature.asc
Description: Digital signature