At Mon, 3 Aug 2015 22:47:24 +0000, "Wessels, Duane" <dwess...@verisign.com> wrote:
> > - Section 8 > > > > For reasons of efficiency, DNS clients and servers SHOULD transmit > > the two-octet length field, and the message described by that length > > field, in a single TCP segment. > > > > I suspect we cannot reasonably require this (with a "SHOULD") at the > > level of DNS client/server implementation [...] > This section now reads: > > For reasons of efficiency, DNS clients and servers SHOULD pass the > two-octet length field, and the message described by that length > field, to the TCP layer at the same time (e.g., in a single write() > system call) to make it more likely that all the data will be > transmitted in a single TCP segment. This additionally avoids > problems due to some DNS servers being very sensitive to timeout > conditions on receiving messages (they may abort a TCP session if the > first TCP segment does not contain both the length field and the > entire message). > > - Appendix A > > > > TCP does not suffer from UDP's issues with fragmentation. > > > > Exactly what does this mean? Is this to say IP fragmentation won't > > happen for TCP? Or does this mean even if fragmentation occurs TCP is > > free from the "UDP's issues" (what are they, btw)? [...] > I propose the following new text: > > IP fragmentation is less of a problem for TCP than it is for UDP. > TCP stacks generally implement Path MTU Discovery so they can avoid > IP fragmentation of TCP segments. UDP, on the other hand, does not > provide reassembly, which means datagrams that exceed the path MTU > size must experience fragmentation [RFC5405]. Middleboxes are known > to block IP fragments, leading to timeouts and forcing client > implementations to "hunt" for EDNS0 reply size values supported by > the network path. Additionally, fragmentation may lead to cache > poisoning [fragmentation-considered-poisonous]. > > Do these changes sufficiently address your concerns? Yes, both look good to me. Thanks. -- JINMEI, Tatuya _______________________________________________ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
