> Mark Delany <mailto:[email protected]> > Saturday, January 24, 2015 2:09 PM > On 24Jan15, Paul Vixie allegedly wrote: > >> could violate older implementations' reasonable-at-the-time assumptions, >> against the burden of choosing a non-interfering signal pattern, like a >> new port number, or a new protocol verb. > > Does it have to be that drastic? Wouldn't an EDNS option "I understand > out-of-order" be enough? Once seen in a TCP session it would hold true > until closed. The non-presence of such an option could then entrench > the in-order assumptions that may exist in the installed base.
i'd be fine with that. note that the "ask" and "answer" codes must differ, to avoid parrots. but i know that any new signal is seen as a bad bargain for those who wish to aggressively embrace TCP, simply because they won't be able to start pipelining until after they've heard their first answer (and then, only if that first answer contains an "i agree to persistency" indication.) perhaps since this information can be cached once discovered, i'm wrong to expect objections on this topic. this is a balancing act. but because RFC 1035 4.2.2 is so weak, and because TCP is in the current installed base a fallback not a primary or preferred transport, it's necessary to limit a client's occupancy time of a server's TCP slot to an extremely small time window unless you have current or recently-cached knowledge that the server does "big TCP". (by which i mean, the server has the new logic, and the server has discovered that its kernel can tolerate vast numbers of open sessions, and the server has been configured to operate this way by some operator who knows he won't be killing off his stateful firewall again.) it's a "first, do no harm" situation. any damage incurred must be upon the newest revision of the protocol. > > >> i expected that DNS-over-HTTP would work the same as WWW-over-HTTP, >> which is to open multiple parallel TCP/80 (or TCP/443) sessions if >> parallelism is required. > > If DNS over HTTP is really being considered, would it be better to > start with HTTP/2.0 as the base protocol rather than 1.* then you get > parallel for "free". i don't know. it sounds great, but i'd want to know that the design team on HTTP/2.0 had very carefully seen to backward compatibility with the billion-or-so transparent middleboxes that think they know every element TCP/80 can contain and the meaning of all possible permutations thereof. in other words i'd like DNS not to be the test case for it. but if it has parallelism and it's well designed and it's coming anyway, then, sure, why not? -- Paul Vixie
_______________________________________________ DNSOP mailing list [email protected] https://www.ietf.org/mailman/listinfo/dnsop
