Re: [DNSOP] Batch Multiple Query Packet
Paul, (Possibly my answer belongs on dnsex not dnsop, but oh well.) On Tuesday, 2012-02-28 00:49:36 +, Paul Vixie p...@redbarn.org wrote: On 2012-02-28 12:27 AM, Edward Lewis wrote: At 13:35 -0500 2/27/12, Hector Santos wrote: If it doesn't already exist or not considered in the past as an unfeasible concept, I am interest in seeing if this is something worth pursuing. One (not the only, Ohta replied with another) of the oft-cited obstacles is the presence of only one RCODE field in the packet. (What if one query would be NXDOMAIN and the other has an answer?) indeed, this is why multiple queries were not supported in the original DNS, and it's why EDNS doesn't have it either. the number of signalling bits needed to explain what went on with the multiple queries made folks' heads explode. the logic is still online if you want to see it: http://nsa.vix.com/~vixie/edns1.txt. I think we're missing a potential great opportunity here by thinking too small. Rather than mucking about with QDCOUNT and breaking old servers, why not just move additional queries into EDNS(n)? So, the idea is to support additional queries by effectively encapsulating them safely into the EDNS space. Basically, you say here is my question, and if you know the multiple-query DNS extension then please give me those answers too. So for old servers they treat it as an old-style question, and get old-style answers. New servers will give additional information. So on the query side you'd need a field with the real QCOUNT, and then a set of additional QNAME/QTYPE/QCLASS entries, possibly like the normal question section, although we can also consider optimizing this a bit by requiring the same QCLASS for all questions for example. Here's the big win I think... On the answer side, you actually don't need to preserve existing DNS format at all. This is because the server knows that the client supports this wacky new multi-question format. That means that we can design a packet format that ACTUALLY MAKES SENSE!!! Consider the possibilities there! We can eliminate the ridiculous waste of 16-bit fields that only ever use one value; we can align the packet so that the variable length data always comes at the end; we can put a massive nonce in; and so on. I don't think this solves with my personal pet peeve (the need to send concurrent A and queries), but it does provide a necessary piece of the solution. -- Shane ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] Batch Multiple Query Packet
Hector Santos wrote: First, I was focusing on the batching of related types, i.e. a protocol with new RR type but has an initial default intro record and fallback to TXT. The goal is to have a single call that will yield a managed result to assist with the current concerns and waste associated with the migration of TXT to the new RR type usage. That's doable without multiple queries with a QTYPE=NEWTYPE, which matches both NEWTYPE and TXT. However, there is a caching problem as is documented in RFC1035. Masataka Ohta ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] Batch Multiple Query Packet
On 2/28/2012 3:28 AM, Hector Santos wrote: Paul Vixie wrote: ... http://nsa.vix.com/~vixie/edns1.txt. Thanks Paul. Great material. I'm just winging it at this point. First, I was focusing on the batching of related types, i.e. a protocol with new RR type but has an initial default intro record and fallback to TXT. The goal is to have a single call that will yield a managed result to assist with the current concerns and waste associated with the migration of TXT to the new RR type usage. the way this was handled for MX was to have A (and later ) as additional data for the MX QTYPE. we should have made QTYPE include type A as additional data. we still can. we should have amended QTYPE A to include type as additional data. we still can. using additional data for this is great since if it's missing you query for it but it won't always be missing. Second, I considered there is no room for a packet count, but I was thinking of simply bundling two separate packets, i.e. 2*RR for the UPD send and how would the servers read this. RCODE FORMERR. this means the initiator would have to be prepared to try again with discrete queries. this is a form of protocol negotiation -- the fact of a responder's nonsupport would have to be discovered (and cached for a while) by each initiator. this is already happening for EDNS. i would recommend against adding more responder state to initiators. this would also mean that when it works you've got one round trip and when it doesn't work you've got either three (assuming you don't blast #2 and #3 without inter-record gap) or two round trips (if you use blast on #2 and #3.) If DNS servers will barf, then never mind. :) yes. But if its offers a way to perform this concept with no breakage, perhaps the server will just read the first one and act on it or it will process the residual packet as well. Of course, the client will still need to manage the responses with all the potential delays. Again, just winging it. I don't like kludges. :) please consider additional data, or blast. paul ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] Batch Multiple Query Packet
Just some BotE: Overhead for each DNS datagram (on an Ethernet) is 8 B for the Ethernet Preamble, 14B for the Ethernet header, 20B for the IP header, and 8 bytes for the UDP header, for a total of 50B. Assuming the question is 50B, and the answer is 150B, the overhead saved is Not That Much by coalesing two requests into one packet: you only save 100B of overhead for communicating 400B of data, which IS non zero, but not enough to really worry about. But since if you could coalesce you could do parallel, this savings doesn't help latency much at all: just the transit time for 50B out and 50B back. If anything, parallel will be BETTER on the latency since batching would probably require a coalesced response, while parallel is just that, parallel, so if the first record is more useful, it can be acted on immediately. ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] Batch Multiple Query Packet
On 2/28/2012 5:57 PM, Nicholas Weaver wrote: But since if you could coalesce you could do parallel, this savings doesn't help latency much at all: just the transit time for 50B out and 50B back. If anything, parallel will be BETTER on the latency since batching would probably require a coalesced response, while parallel is just that, parallel, so if the first record is more useful, it can be acted on immediately. parallel (what i called blast) is great solution for things that don't run at scale. but the lock-step serialization that we get from the MX approach (where the A/ RRset may be in the additional data section and so we have to wait for the first answer before we ask the second or third question) has a feedback loop effect on rate limiting. it's not as good as tcp windowing but it does tend to avoid WRED in core and edge router egress buffers. all i'm saying is, we have to be careful about too much parallelism since UDP unlike TCP has no windowing of its own. ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] Batch Multiple Query Packet
On Feb 28, 2012, at 10:04 AM, Paul Vixie wrote: On 2/28/2012 5:57 PM, Nicholas Weaver wrote: But since if you could coalesce you could do parallel, this savings doesn't help latency much at all: just the transit time for 50B out and 50B back. If anything, parallel will be BETTER on the latency since batching would probably require a coalesced response, while parallel is just that, parallel, so if the first record is more useful, it can be acted on immediately. parallel (what i called blast) is great solution for things that don't run at scale. but the lock-step serialization that we get from the MX approach (where the A/ RRset may be in the additional data section and so we have to wait for the first answer before we ask the second or third question) has a feedback loop effect on rate limiting. it's not as good as tcp windowing but it does tend to avoid WRED in core and edge router egress buffers. all i'm saying is, we have to be careful about too much parallelism since UDP unlike TCP has no windowing of its own. We don't need to be careful on this until you are talking about ~10 KB of data or more in a single transaction with no interactions, because before then TCP has the same dynamics due to the initial window size (with browsers opening 4+ connections!), and this doesn't seem to bother people. ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
