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/AAAA 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
