HI Daniel, So true, and thank you very much.... also thanks to Shane.... On Fri, Dec 2, 2016 at 11:48 AM, Daniel Kahn Gillmor <[email protected]> wrote:
> On Fri 2016-12-02 01:22:40 -0500, Tariq Saraj wrote: > > Thanks for your detailed reply, the point I am trying to highlight is the > > changes in TCP for DNS which is "TCP out of order packet delivery, i.e. > the > > OOOP". > > I think you're referring to "out of order processing" for DNS requests > by a recursive resolver. While necessary for reasonable performance > over TCP, I don't think this approach remediates TCP > head-of-line-blocking. > > imagine a client who makes two queries across a TCP connection in rapid > succession, the first for slow.example and the second for fast.example. > > many traditional (old, unoptimized) DNS recursive resolvers will try to > find the answer for slow.example before they even start making the > queries needed for fast.example. they might not even read the second > query from the TCP connection before responding to the first one. > > OOOP says that a DNS recursive resolver should read queries as they come > in over TCP, even if it still has responses pending for other queries > from that connection. > > IOW, the dns resolution *itself* should not block based on slow DNS > responses from the authoritative servers it queries. > > but none of that resolves the problem of TCP head-of-line blocking. if > one packet carrying a query on one TCP connection gets dropped, the > receiving server can't see any of the rest of the packets until the > earlier packet is re-sent. (and vice versa for replies going from > recursor to stub) > > does this make sense? > > --dkg > -- Regards Tariq Saraj Riphah Institute of Systems Engineering, Islamabad
_______________________________________________ dns-privacy mailing list [email protected] https://www.ietf.org/mailman/listinfo/dns-privacy
