Re: [DNSOP] draft-ietf-dnsop-edns-chain-query and draft-ietf-dnsop-edns-tcp-keepalive
On 8 Oct 2014, at 21:07, David C Lawrence wrote: > It is just preferable to me that the TCP session behaviour be negotiated. Can you please elaborate? What particular benefits do you anticipate arising from such a negotiation? kind regards, Ray ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] draft-ietf-dnsop-edns-chain-query and draft-ietf-dnsop-edns-tcp-keepalive
Ray Bellis : > It appears to be a solution for a problem that does not exist, based on a > misunderstanding of how TCP clients and servers are already supposed to > interact and a misrepresentation of the recommended shortening of the > standard timeout for TCP sessions that happened in RFC 5966. I support the draft, and I'm not coming from the position of "misunderstanding of how TCP clients and servers are already supposed to interact". I am very clear on the current spec. It is just preferable to me that the TCP session behaviour be negotiated. ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] draft-ietf-dnsop-edns-chain-query and draft-ietf-dnsop-edns-tcp-keepalive
Paul Wouters wrote: > On Wed, 8 Oct 2014, Tony Finch wrote: > > > > this extension allows a significant resource saving when used on mobile > > > phones. > > > > Yes, I pointed that out in the article linked above. But EDNS chain > > queries only reduce the data sent and received, not the number of round > > trips. The maximum number of round trips required is two, with or without > > EDNS chain queries. > > If you keep the TCP connection open, for chain query it would be a > maximum of one round trip. I am not sure how you are saying you can do > all the work in parallel, when you do not know beforehand how many CNAME > or DNAME contstruct will appear in your queries and when you have no > cache other then the root key. Unless you are going to break up on every > dot and send all those packets in parallel. Yes exactly, as I explained in my article from last October. Note that when you get a response involving a CNAME from a recursive server, you get the whole CNAME chain, so you can get all the validation chains in a second round trip. EDNS chain queries also require this second round trip, unless they waste space by eagerly sending all the CNAME validation chains in the first response. But if you send them eagerly you are wasting radio time and battery charge if the client has them in its cache. > > Note that the numbers I was working with did not include NS RRsets. If you > > add those in as required for EDNS chain queries, then I guess you will not > > actually be winning. > > I do not understand this at all? Can you clarify? See the numbers in my previous article. The savings from EDNS chain query were quite large in my example because I chose a deeply nested domain with some non-zone-cut labels. If you have a domain of a more common length and you pad the response with NS RRsets then I doubt EDNS chain queries will save much compared to concurrent standard queries. > > The EDNS chain query option doesn't include enough information for the > > server to optimize its response correctly if the answer is a CNAME or MX > > etc. to a different zone (e.g. under a different TLD). > > I think it does. It can add the required records in the additional > section so that the dns answer packet contains all the components > required for validation. When I say "not enough information" I mean the "last known" name isn't enough for the server to both eliminate wasted validation chains and eliminate second round trips. Say I visit www.ietf.org, and I send an EDNS chain query with a "last known" name of org. The server can either send back just the DS+DNSKEY for ietf.org, or it can also include the whole validation chain for cdn.cloudflare.net. If it sends the short response, I might need to send another query to get Cloudflare's validation chain. If it sends the long response it might be wasted effort if I already have it cached. There is no way I can anticipate what the target of the CNAME is, so there's nothing useful I can add to the EDNS chain query to avoid the wasted effort. There is no way the server can anticipate what is in my cache so it can't avoid sending too little or too much data. > Additionally, those that prefer rapid-fire can already do so and not use > query-chain. Exactly. Tony. -- f.anthony.n.finchhttp://dotat.at/ Trafalgar: Cyclonic in northwest, otherwise mainly northerly or northwesterly 5 or 6. Slight or moderate. Showers in northwest. Good. ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] draft-ietf-dnsop-edns-chain-query and draft-ietf-dnsop-edns-tcp-keepalive
On Wed, 8 Oct 2014, Tony Finch wrote: this extension allows a significant resource saving when used on mobile phones. Yes, I pointed that out in the article linked above. But EDNS chain queries only reduce the data sent and received, not the number of round trips. The maximum number of round trips required is two, with or without EDNS chain queries. If you keep the TCP connection open, for chain query it would be a maximum of one round trip. I am not sure how you are saying you can do all the work in parallel, when you do not know beforehand how many CNAME or DNAME contstruct will appear in your queries and when you have no cache other then the root key. Unless you are going to break up on every dot and send all those packets in parallel. Note that the numbers I was working with did not include NS RRsets. If you add those in as required for EDNS chain queries, then I guess you will not actually be winning. I do not understand this at all? Can you clarify? As chain queries give you all the required validation data in one round trip, how will you do the same without sending an excessive amount of queries and then still needing so send another wave of those if there is a CNAME/DNAME? How would you break even accomplishing 1 RTT (assuming that when you say "win" you don't mean less than 1 RTT :) What is the complexity? It's not introducing any new formats, no new record types, and just an edns option you can ignore if you don't want it? The complexity is in the upstream resolver picking up all the right entries. The client is clean and simple. Send one packet, get a nicely validatable answer back. The client needs to negotiate support and keep track of which servers provide it or not. On the stub, the client would use the assigned forwarders only. So it just needs to remember if its current one or two resolvers support this or not. The EDNS chain query option doesn't include enough information for the server to optimize its response correctly if the answer is a CNAME or MX etc. to a different zone (e.g. under a different TLD). I think it does. It can add the required records in the additional section so that the dns answer packet contains all the components required for validation. It isn't clear to me if including NS records in the response makes sense as the default behaviour. Maybe it does for roaming clients (like Unbound / DNSSEC-trigger) that switch back and forth between forwarding and iterative resolution, but if you have a forwarding-only resolver it is just waste. That is something we could discuss. It might be that the gains for NS records are not worth it. I am not sure yet either way. You could make it optional - or you could just remove the feature and if the client wants NS records it can ask for them using a separate query. In the case of the caching itterative resolver, that might make sense. But all of these questions disappear, and you get negligible loss of performance, if the client sends concurrent queries for just the records it needs. See above. I disagree that rapid-fire is desirable over sending a single query. And I did not yet see how you can achieve this in roughly 1 RTT. Additionally, those that prefer rapid-fire can already do so and not use query-chain. Paul ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] draft-ietf-dnsop-edns-chain-query and draft-ietf-dnsop-edns-tcp-keepalive
Paul Wouters wrote: > On Wed, 8 Oct 2014, Tony Finch wrote: > > Tim Wicinski wrote: > > > > > > https://datatracker.ietf.org/doc/draft-ietf-dnsop-edns-chain-query/ > > > > I do not think this protocol extension is necessary. > > > > I have previously described how you can get the same round-trip > > performance by sending queries for all the chain records at once: > > http://www.ietf.org/mail-archive/web/dnsext/current/msg13540.html > > That doesn't help a stub resolver much. Do you really want the resolver > logic of gathering all this data in asynchronous queries to be in libc? You don't need any asynchronous code to send concurrent queries. If you are using a TCP socket you don't even need to select(). Just write out the queries then read the replies. (You only need to go async if you want to be concurrent with other activity in the program, in which case it isn't relevant to compare with the non-async libc resolver.) > > The performance problem that EDNS chain queries are trying to fix is an > > problem with existing server implementations, NOT a protocol limitation. > > Both BIND and Unbound fail to handle queries concurrently when they arrive > > over one TCP connection. > > this extension allows a significant resource saving when used on mobile > phones. Yes, I pointed that out in the article linked above. But EDNS chain queries only reduce the data sent and received, not the number of round trips. The maximum number of round trips required is two, with or without EDNS chain queries. Note that the numbers I was working with did not include NS RRsets. If you add those in as required for EDNS chain queries, then I guess you will not actually be winning. Perhaps a more useful option would be to request minimal responses. > > It would be much better to spend time working on fixing these bugs instead > > of adding complexity to the protocol. > > What is the complexity? It's not introducing any new formats, no new > record types, and just an edns option you can ignore if you don't want > it? The complexity is in the upstream resolver picking up all the right > entries. The client is clean and simple. Send one packet, get a nicely > validatable answer back. The client needs to negotiate support and keep track of which servers provide it or not. The EDNS chain query option doesn't include enough information for the server to optimize its response correctly if the answer is a CNAME or MX etc. to a different zone (e.g. under a different TLD). It isn't clear to me if including NS records in the response makes sense as the default behaviour. Maybe it does for roaming clients (like Unbound / DNSSEC-trigger) that switch back and forth between forwarding and iterative resolution, but if you have a forwarding-only resolver it is just waste. You could make it optional - or you could just remove the feature and if the client wants NS records it can ask for them using a separate query. But all of these questions disappear, and you get negligible loss of performance, if the client sends concurrent queries for just the records it needs. Tony. -- f.anthony.n.finchhttp://dotat.at/ Trafalgar: Cyclonic in northwest, otherwise mainly northerly or northwesterly 5 or 6. Slight or moderate. Showers in northwest. Good. ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] draft-ietf-dnsop-edns-chain-query and draft-ietf-dnsop-edns-tcp-keepalive
On Wed, 8 Oct 2014, Ray Bellis wrote: https://datatracker.ietf.org/doc/draft-ietf-dnsop-edns-tcp-keepalive/ I do NOT support adoption of edns-tcp-keepalive. It appears to be a solution for a problem that does not exist, based on a misunderstanding of how TCP clients and servers are already supposed to interact and a misrepresentation of the recommended shortening of the standard timeout for TCP sessions that happened in RFC 5966. I agree. We investigated and we found that it was not needed to detect bad broken TCP. But then some other people wanted this extension for better determining of load on DNS servers, and they said they would like this document to continue. So the original reason is indeed not needed. We could expand on the second reason in the draft, or drop the draft if there is no one left who wants it. Paul ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] draft-ietf-dnsop-edns-chain-query and draft-ietf-dnsop-edns-tcp-keepalive
On Wed, Oct 8, 2014 at 9:34 AM, Paul Wouters wrote: > I have previously described how you can get the same round-trip >> performance by sending queries for all the chain records at once: >> http://www.ietf.org/mail-archive/web/dnsext/current/msg13540.html >> > > That doesn't help a stub resolver much. Do you really want the resolver > logic of gathering all this data in asynchronous queries to be in libc? Why not? Check out OpenBSD's libc. It contains a fully asynchronous resolver. The standard APIs are simply wrappers around their non-standard async counterparts. Overall I find it much cleaner and simpler than glibc's. The point is: asynchronism does not necessarily imply complexity. Simon ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] draft-ietf-dnsop-edns-chain-query and draft-ietf-dnsop-edns-tcp-keepalive
On Wed, 8 Oct 2014, Tony Finch wrote: Tim Wicinski wrote: https://datatracker.ietf.org/doc/draft-ietf-dnsop-edns-chain-query/ I do not think this protocol extension is necessary. I have previously described how you can get the same round-trip performance by sending queries for all the chain records at once: http://www.ietf.org/mail-archive/web/dnsext/current/msg13540.html That doesn't help a stub resolver much. Do you really want the resolver logic of gathering all this data in asynchronous queries to be in libc? The performance problem that EDNS chain queries are trying to fix is an problem with existing server implementations, NOT a protocol limitation. Both BIND and Unbound fail to handle queries concurrently when they arrive over one TCP connection. this extension allows a significant resource saving when used on mobile phones. It would be much better to spend time working on fixing these bugs instead of adding complexity to the protocol. What is the complexity? It's not introducing any new formats, no new record types, and just an edns option you can ignore if you don't want it? The complexity is in the upstream resolver picking up all the right entries. The client is clean and simple. Send one packet, get a nicely validatable answer back. Paul ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] draft-ietf-dnsop-edns-chain-query and draft-ietf-dnsop-edns-tcp-keepalive
On 8 Oct 2014, at 10:35, Tony Finch wrote: > > The performance problem that EDNS chain queries are trying to fix is an > problem with existing server implementations, NOT a protocol limitation. > Both BIND and Unbound fail to handle queries concurrently when they arrive > over one TCP connection. This is one of the issues to be addressed in 5966-bis - specifying that TCP queries should not be processed serially causing "head of queue" blocking. kind regards, Ray ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] draft-ietf-dnsop-edns-chain-query and draft-ietf-dnsop-edns-tcp-keepalive
Tim Wicinski wrote: > > https://datatracker.ietf.org/doc/draft-ietf-dnsop-edns-chain-query/ I do not think this protocol extension is necessary. I have previously described how you can get the same round-trip performance by sending queries for all the chain records at once: http://www.ietf.org/mail-archive/web/dnsext/current/msg13540.html The performance problem that EDNS chain queries are trying to fix is an problem with existing server implementations, NOT a protocol limitation. Both BIND and Unbound fail to handle queries concurrently when they arrive over one TCP connection. It would be much better to spend time working on fixing these bugs instead of adding complexity to the protocol. Tony. -- f.anthony.n.finchhttp://dotat.at/ Trafalgar: Cyclonic in northwest, otherwise mainly northerly or northwesterly 5 or 6. Slight or moderate. Showers in northwest. Good. ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] draft-ietf-dnsop-edns-chain-query and draft-ietf-dnsop-edns-tcp-keepalive
On 7 Oct 2014, at 18:27, Tim Wicinski wrote: > All > > We have two drafts expiring shortly and I wanted to get the sense of the > working group. > > These are the two EDNS extensions worked on by Mr. Paul Wouters. They > initially had no home, and we gave them a home, and there was a lot of > discussion around them, and paul turned these documents several times to > address issues. > > DNSOP went and got their charter changed, to address work like this. Since > then we've had no discussion on them. However, I am confident that the > previous rounds gave these documents a strong vetting. They have been adopted > as working group documents some time ago. > > The documents are: > > https://datatracker.ietf.org/doc/draft-ietf-dnsop-edns-chain-query/ > > https://datatracker.ietf.org/doc/draft-ietf-dnsop-edns-tcp-keepalive/ I do NOT support adoption of edns-tcp-keepalive. It appears to be a solution for a problem that does not exist, based on a misunderstanding of how TCP clients and servers are already supposed to interact and a misrepresentation of the recommended shortening of the standard timeout for TCP sessions that happened in RFC 5966. The latter is mentioned in the abstract where the draft asserts this makes "making use of TCP only suitable for individual queries generated as a fallback protocol for truncated UDP answers”. This assertion is not supported (or even mentioned) anywhere else in the text. Like HTTP/1.1, DNS over TCP sessions should _already_ be considered persistent, albeit with shorter timeouts since RFC 5966 (I see that Apache 2.2 uses a 5 second timeout). There’s no need to use an option to ask for it, nor IMHO any need for the value of the timeout to be communicated between client and server (or vice versa). There’s a small group of us that are looking at an update to 5966 to reflect lessons learnt since that was published in August ’10 and to propose further clarifications. On discussion with one of that group a few days ago the primary missing feature I could see relating to socket handling in TCP over DNS was an analogue of the HTTP/1.1 “Connection: close” flag from server to client - in effect the server asking the client nicely to close the connection from its end. This puts the TCP TIME_WAIT burden on the client instead of the server and could be trivially accomplished with a single bit flag in the EDNS flags. kind regards, Ray ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] draft-ietf-dnsop-edns-chain-query and draft-ietf-dnsop-edns-tcp-keepalive
On Tue, Oct 07, 2014 at 01:27:40PM -0400, Tim Wicinski wrote: > The documents are: > > https://datatracker.ietf.org/doc/draft-ietf-dnsop-edns-chain-query/ > https://datatracker.ietf.org/doc/draft-ietf-dnsop-edns-tcp-keepalive/ I support both, and will review if needed. -- Evan Hunt -- e...@isc.org Internet Systems Consortium, Inc. ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
[DNSOP] draft-ietf-dnsop-edns-chain-query and draft-ietf-dnsop-edns-tcp-keepalive
All We have two drafts expiring shortly and I wanted to get the sense of the working group. These are the two EDNS extensions worked on by Mr. Paul Wouters. They initially had no home, and we gave them a home, and there was a lot of discussion around them, and paul turned these documents several times to address issues. DNSOP went and got their charter changed, to address work like this. Since then we've had no discussion on them. However, I am confident that the previous rounds gave these documents a strong vetting. They have been adopted as working group documents some time ago. The documents are: https://datatracker.ietf.org/doc/draft-ietf-dnsop-edns-chain-query/ https://datatracker.ietf.org/doc/draft-ietf-dnsop-edns-tcp-keepalive/ I have thought about tbis and the opinion of this chair is that they are actually ready for a WGLC round and we pick up some shepherds and editoring and move them down the road. Before I did this, I wanted to take the temperature of the group, and see if there are any issues with moving forward. thanks tim ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
