On Mon, Mar 2, 2015 at 9:00 AM, Ilari Liusvaara <[email protected] > wrote:
> On Mon, Mar 02, 2015 at 07:49:08AM -0500, Phillip Hallam-Baker wrote: > > > > Having long experience of trying to persuade browser providers to do OCSP > > with TLS, I do not see any possibility that DNS over TCP is going to be > > acceptable to them. > > > > I don't care how many graphs are presented showing that TCP is as fast > > under lab conditions or with a specific stack or with new extensions > etc. I > > would not be convinced and I see no reason why Google is going to be. > > Reducing the time to load of the first page is a really big deal for the > > Chrome team. > > > > So when people are saying 'DNS over TCP isn't a major overhead' what the > > Chrome team are probably hearing is 'giving up half your annual bonus to > do > > privacy our way shouldn't be a problem'. > > Are you talking about: > > - Overhead of establishing (secured) TCP connection (AFAIK, 2RTT without > extensions)? > - Bad handling of packet loss by TCP (don't know)? > - Latency increase from increased bandwidth and encryption/decryption > (AFAICT, on order of 0.1ms or so)? > All of the above > The hot assoication performance looks acceptable. Are you talking about > cold association performance being important? > As soon as you put an adjective in there, I think you lose them. The origin of my proposal is that I was trying to reduce the overhead of doing OCSP checks to an acceptable level because they were refusing to hardfail on TLS cert status checks. Now DPRIV might be a higher security priority but I somehow doubt it. I don't think we have any chance of getting the fish to bite unless we can show a performance advantage in virtually every case without exception. Also, the end that bears the burnt of keeping hot associations is the > server end (recursive resolver in case of stub<->recursive), not the > client (stub) end. I have heard of single system image managing to keep > 1 million TCP connections at once (that was some time ago, likely > higher now). > Again, that is an argument that I think only has weight if it comes from some party that is going to deploy a highly trafficked recursive. And I think it is only something that we should even consider if there isn't any other alternative. We have an alternative and it is just as easy to implement and guarantees performance at least as good as current DNS for 97% of network circumstances. > I would see the point of using UDP (which means increased complexity): > - If cold case 2RTT is unacceptable. > - If packet loss handling of TCP proves too troublesome. > - If maintaining enough associations is problem for recursive servers. > > Using UDP does virtually nothing to extra bandwidth latency. > The startup and session maintenance costs are significant. > >
_______________________________________________ dns-privacy mailing list [email protected] https://www.ietf.org/mailman/listinfo/dns-privacy
