> Francis Dupont <mailto:francis.dup...@fdupont.fr> > Wednesday, March 25, 2015 4:01 PM > (other points, i.e., not TCP mandatory or timeouts) > > In your previous mail you wrote: > >> this means that while it's not ideal, it's not as broken as it could be. >> with changes to recommended initiator behaviour, we could make these >> existing servers more broken, or we could preserve their present level >> of brokenness, but we cannot make them less broken. i'm going to argue, >> below, for preserving their present level of brokenness. > > => IMHO this means we need to introduce a bit of signaling before > trying a better behaviour at any side, so legacy initiators and > servers are recognized.
we are in agreement on this point. > >> i am comfortable with this approach, but i would like to also specify >> (in one of the tcp related documents now circulating, or in a new one, >> that's a detail) that initiators SHOULD NOT remain connected and idle >> unless they are acting under some later specification under which >> idleness has been explicitly negotiated. > > => at the exception of the SOA + xXFR case I don't believe that > idling initiators are common today. you are correct, and you have corrected me. even though the initiator's second transaction in the SOA+xFR case is synchronous to its receipt of the response to its first transaction, that period could be described as "idle". in extreme endpoint sets (where much RTT and congestion exist) this could be a matter of seconds, which is an eternity from the point of view of a server trying to resist an attack against its connection resources. (this realization came from a different thread, and informed my recommendation in that thread as to how a server should set up its timeout policy.) >> note that >> <http://tools.ietf.org/html/draft-ietf-dnsop-edns-tcp-keepalive-01> is >> an example of a protocol revision by which idleness could be explicitly >> negotiated. i think a simpler approach could work, like adding one bit >> of the EDNS extended-flags mask to say "the sender of this message would >> be happy about remaining connected but idle". my reason for thinking >> this would be enough is, there's no way to reliably tune specific idle >> periods, and a TCP speaker who signals their willingness to remain idle >> must also be prepared to close least-recently-used connections when the >> pool of potential connections is running dry. > > => the advantage of the keepalive proposal is the server can give the > timeout it wants to use. And a bit carries too few infos, e.g., > how to announce the initiator is smart but in this case allows > (or wants) the server to close after the response? that draft deserves discussion. in your example, the client could send a FIN at the end of its request, which is an unambiguous signal to the server that it should likewise send a FIN at the end of its response. in my mind's eye, i envision a server policy that can change at the end of each response, so that if its connection resources are in the "green zone" it sets the "idle OK" bit on its response, and in the "yellow zone" it clears the "idle OK" bit, allowing a client to send pent-up back to back requests but then to FIN when they run out of things to send. (if the server gets into the "red" zone, it just starts closing connections.) -- Paul Vixie
_______________________________________________ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
