The issue is that turning on TCP_NODELAY doesn't actually do the right thing, nor does removing the delayed ACK timer. Both of these are heuristic solutions that apply across the entire session, and have negative consequences (which is why they are on by default).
What we need is actually a very small thing, in a sense: the ability to say "I got the message, and will not be responding to it," so that the existing heuristic is satisfied in exactly the same way that sending a response satisfies it. It's true that on a gigabit ethernet, just turning off the heuristics and sending whatever we have whenever we have it isn't likely to cause problems, but this stuff also has to work in home networks and over wide-area links and even low-bandwidth mobile links, where we can't assume that we have as much headroom as we do on a gigabit ethernet link. We think that it is probably worth the IETF thinking about this problem, yet at the same time that's out of scope for the current work. But not talking about the problem at all in the current work means that when the solution to this problem starts appearing in APIs, which seems likely, there will be no advice in the document about what the implementation should do. What we propose to do therefore is to put in a paragraph that briefly mentions the issue and says "when unacknowledged messages are received, if an API is present to inform the TCP layer that no response will be sent, the responder SHOULD do so." And then the text from the section as it was when you put the DISCUSS on it would go in an Appendix, so that it's clear what's going on. We can then reference this section in the text telling the implementation what to do. Will this satisfy your DISCUSS (assuming that we don't make mistakes in how we document this)?
_______________________________________________ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
