Subject: Re: [DNSOP] comments on draft-ietf-dnsop-5966bis-02

From: "Wessels, Duane" <[email-masked]>
Date: Mon, 3 Aug 2015 22:47:24 +0000

> On Jul 27, 2015, at 3:28 PM, 神明達哉 <[email-masked]> 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

---

From: 神明達哉 <[email-masked]>
Date: Wed, 5 Aug 2015 18:00:28 -0700

At Mon, 3 Aug 2015 22:47:24 +0000,
"Wessels, Duane" <[email-masked]> wrote:

> > level of DNS client/server implementation [...]

> > free from the "UDP's issues" (what are they, btw)?
[...]
> Do these changes sufficiently address your concerns?

Yes, both look good to me.  Thanks.

--
JINMEI, Tatuya

---

From: John Heidemann <[email-masked]>
Date: Thu, 06 Aug 2015 11:15:46 -0700

>   first TCP segment does not contain both the length field and the

Personally, I would strike the "This additionally avoids...message).".
An app that requires the length and payload in the same segment is buggy
becuase, in general, there is NO way for sender to guarantee that
property.  This is the limitation Jinmei pointed out.

Fortunately, app-level messages that are split across multiple TCP
segments (and therefore may require mutliple read() calls) are well
known to TCP developers (ex: web browser and server developers).

Also fortunatley, this is just a SHOULD :-).

   -John Heidemann