> On Jul 27, 2015, at 3:28 PM, 神明達哉 <jin...@wide.ad.jp> wrote: > > I have a couple of minor comments on 5966bis-02:
Tatuya, thank you for the comments. > > - 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 since an application cannot > always/fully control a specific TCP segment contains how much data: it > depends on the state of the TCP connection, specific implementation > details of the TCP stack, etc. I suggest rephrasing this as follows > (and I guess that was actually what was intended to say here): > > 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) so it will be 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). 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)? > > My impression from this sentence is that it assumes path MTU discovery > is used for TCP and fragmentation should normally not happen for TCP. > If this is the intent, I think it will need to explain a bit more, > including this particular assumption and why UDP can't benefit from > it. If my impression is incorrect, I'd like to understand what it > actually tries to say. 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? DW
smime.p7s
Description: S/MIME cryptographic signature
_______________________________________________ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
