tqbf
Thomas H. Ptacek
Dan, DNS lookups over TCP are 10-20ms slower than UDP lookups. Your measurement code is broken.
dakami
Dan Kaminsky
@tqbf On latency, you always get +1RTT, which you can then amortize across some number of queries. Throughput grows though
@tqbf On latency, you always get +1RTT, which you can then amortize across some number of queries. Throughput grows though
tqbf
Thomas H. Ptacek
@dakami I have no idea what you're trying to say. All I did was: actually measure, over many hundreds of queries, TCP vs. UDP.
@dakami I have no idea what you're trying to say. All I did was: actually measure, over many hundreds of queries, TCP vs. UDP.
dakami
Dan Kaminsky
@tqbf let me clarify then: traditionally, we thought if everyone ran dns over tcp, it would knock over name servers
@tqbf let me clarify then: traditionally, we thought if everyone ran dns over tcp, it would knock over name servers
dakami
Dan Kaminsky
@tqbf ...because they would have to dedicate too many resources to each open socket
@tqbf ...because they would have to dedicate too many resources to each open socket
dakami
Dan Kaminsky
@tqbf with modern libevent socket handling though, mass tcp sockets are now fast and low resource
@tqbf with modern libevent socket handling though, mass tcp sockets are now fast and low resource
tqbf
Thomas H. Ptacek
@dakami Are you saying this because it SOUNDS true, or are you going to post measurement code? Because: TCP is 20ms slower.
@dakami Are you saying this because it SOUNDS true, or are you going to post measurement code? Because: TCP is 20ms slower.
tqbf
Thomas H. Ptacek
@dakami Because you got up on stage and told people TCP was faster and said "I have no idea why". It isn't.
@dakami Because you got up on stage and told people TCP was faster and said "I have no idea why". It isn't.
dakami
Dan Kaminsky
@tqbf this all came up because the reason we went with source port randomization, rather than TCP upgrade, was server perf
@tqbf this all came up because the reason we went with source port randomization, rather than TCP upgrade, was server perf
tqbf
Thomas H. Ptacek
@dakami You know what I totally believe you about all of this but I can't get past "TCP is faster than UDP" because it clearly isn't.
@dakami You know what I totally believe you about all of this but I can't get past "TCP is faster than UDP" because it clearly isn't.
asteingruebl
Andy Steingruebl
@dakami @tqbf On this topic though, seriously, you're going to need a ton of work to benchmark. Does CPU usage count? etc.
@dakami @tqbf On this topic though, seriously, you're going to need a ton of work to benchmark. Does CPU usage count? etc.
dakami
Dan Kaminsky
.@asteingruebl @tqbf this all really comes up when the question is, can we tunnel DNSSEC over HTTP to get around firewalls?
.@asteingruebl @tqbf this all really comes up when the question is, can we tunnel DNSSEC over HTTP to get around firewalls?
asteingruebl
Andy Steingruebl
@dakami @tqbf OK, sure we can, we can also tunnel it over ICMP.. :) A lot of feasibility depends on the nameserver, keepalives, etc.
@dakami @tqbf OK, sure we can, we can also tunnel it over ICMP.. :) A lot of feasibility depends on the nameserver, keepalives, etc.
dakami
Dan Kaminsky
@tqbf So while there's a round trip latency hit, your server's total qps actually increases.
@tqbf So while there's a round trip latency hit, your server's total qps actually increases.
tqbf
Thomas H. Ptacek
@dakami Ok, give me a server that answers both TCP and UDP where I will see TCP responses come back faster.
@dakami Ok, give me a server that answers both TCP and UDP where I will see TCP responses come back faster.
dakami
Dan Kaminsky
@tqbf you're not listening. It's not faster in terms of latency. It's faster in terms of throughput.
@tqbf you're not listening. It's not faster in terms of latency. It's faster in terms of throughput.
tqbf
Thomas H. Ptacek
@dakami You're saying, if I connected to a nameserver and asked 1000 queries, they'd come back faster with TCP?
@dakami You're saying, if I connected to a nameserver and asked 1000 queries, they'd come back faster with TCP?
dakami
Dan Kaminsky
@tqbf if that nameserver was built off libevent, yes. I really need to put together the repro steps.
@tqbf if that nameserver was built off libevent, yes. I really need to put together the repro steps.
tqbf
Thomas H. Ptacek
@dakami You realize libevent works fine with UDP, and that TCP is rate limited and UDP isn't, right?
@dakami You realize libevent works fine with UDP, and that TCP is rate limited and UDP isn't, right?
dakami
Dan Kaminsky
@tqbf you realize I actually wrote a libevent based DNSSEC proxy with UDP TCP and HTTP endpoints, don't you?
@tqbf you realize I actually wrote a libevent based DNSSEC proxy with UDP TCP and HTTP endpoints, don't you?
tqbf
Thomas H. Ptacek
@dakami I'd have to modify the UDP side to be dumb enough to simply hammer the server with 1000 back to back queries, but, no big deal.
@dakami I'd have to modify the UDP side to be dumb enough to simply hammer the server with 1000 back to back queries, but, no big deal.
dionthegod
Dion
@dakami I'm not arguing sandboxes are impenetrable. I agree with @chrisrohlf and @dinodaizovi -- kernel bugs are many times cheaper
@dakami I'm not arguing sandboxes are impenetrable. I agree with @chrisrohlf and @dinodaizovi -- kernel bugs are many times cheaper
dakami
Dan Kaminsky
@dionthegod so for sandboxes to be effective you must posit an attacker who can afford the expensive bug but not the cheap one
@dionthegod so for sandboxes to be effective you must posit an attacker who can afford the expensive bug but not the cheap one
vrybdpkt
vrybdpkt
@tqbf @dakami does what I'm reading amount to "my implementation and use case" and not anything modeled and measured?
@tqbf @dakami does what I'm reading amount to "my implementation and use case" and not anything modeled and measured?
dakami
Dan Kaminsky
@vrybdpkt @tqbf Nah, there's definite modeling and measuring going on. Otherwise I'd be tweeting and not rebuilding the environ
@vrybdpkt @tqbf Nah, there's definite modeling and measuring going on. Otherwise I'd be tweeting and not rebuilding the environ
vrybdpkt
vrybdpkt
@dakami @tqbf I've got to say I don't see how TCP can be faster than UDP. All things being equal UDP responds by the time the TWH is done.
@dakami @tqbf I've got to say I don't see how TCP can be faster than UDP. All things being equal UDP responds by the time the TWH is done.
tqbf
Thomas H. Ptacek
@vrybdpkt The 3WH is amortized over many queries, but UDP keeps firehosing when packets get dropped and doesn't slow-start.
@vrybdpkt The 3WH is amortized over many queries, but UDP keeps firehosing when packets get dropped and doesn't slow-start.
tqbf
Thomas H. Ptacek
@dakami I have a libevented UDP and TCP DNS client right here if I'm wrong and you actually have a DNS server to point me at.
@dakami I have a libevented UDP and TCP DNS client right here if I'm wrong and you actually have a DNS server to point me at.
dakami
Dan Kaminsky
@tqbf non-libevent stacks *crumble* on throughput, which was what was so surprising.
@tqbf non-libevent stacks *crumble* on throughput, which was what was so surprising.