In message <54c424f2.4020...@redbarn.org>, Paul Vixie writes: > > > Mark Delany <mailto:f...@november.emu.st> > > 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.
To tell the server "you can send out of order responses" it does not matter if the server is broken in that way or not. EDNS cookies also doesn't care if the server incorrectly echos back the option. You still get all the signaling the client needs to detect spoofed responses in the echos. That said the behaviour should be stomped on with extreme prejudice. > 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. Of course they can start pipe lining without waiting. The existing servers don't break when we do it today without signaling. The real problem is that servers misbehave when presented with a unknown EDNS option. > 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. There is a difference between "reusing a existing socket because it is already open rather than opening a new socket" (BIND 9.11 will do this for query processing) or "we will use tcp for this set of queries because we expect we will need to use tcp anyway" (update forwarding in BIND uses TCP and reuses the socket if it is open, the later is new in BIND 9.11) and "holding a socket open longer because perhaps we may re-use it." The first two use TCP for the minimal amount of time required and out of order processsing reduces that amount of time the socket is held open. netstat held the socket open and used tcp because it was asking lots of queries. Even then it wasn't pipelining queries. -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: ma...@isc.org _______________________________________________ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
