Re: [DNSOP] Mirja Kühlewind's Discuss on draft-ietf-dnsop-session-signal-12: (with DISCUSS and COMMENT)

[Stuart Cheshire <[e-mail]>]

On 30 Jul 2018, at 13:19, Mirja Kühlewind <[e-mail]> wrote:

> ----------------------------------------------------------------------
> DISCUSS:
> ----------------------------------------------------------------------

I’m responding to the “DISCUSS” items right now. I’ll get to the “COMMENT” items shortly.

> 1) In addition to the bullet point in the 6.2 that was flagged by Spencer, I
> would like to discuss the content of section 5.4.  (DSO Response Generation). I
> understand the desire to optimize for the case where the application knows that
> no data will be sent as reply to a certain message, however, TCP does not have
> a notion of message boundaries and therefore cannot and should not act based on
> the reception of a certain message. Indicating to the TCP that an ACK can be
> set immediately in an specific situation is also problematic as ACK processing
> is part of the TCP's internal machinery. However, why it is important at all
> that an TCP-level ACK is send out fast than the delayed ACK timer? The ACK
> receiver does not expose the information when an ACK is received to the
> application and the delayed ACK timer only expires if no further data is
> received/send by the ACK-receiver, therefore this optimization should not have
> any impact in the application performance. I would just recommend to remove
> this section and any additional discussion about delayed ACKs.
> 
> Please note that the problem described in [NagleDA] only occurs for
> request-response protocols where no further request can be sent before the
> response is received. This is not the case in this protocol (as pipelining is
> supported).

The problem here is not further requests, it’s further responses. Consider a client that subscribes for mDNS relay service <https://tools.ietf.org/html/draft-ietf-dnssd-mdns-relay-01>.

If the server gets an mDNS packet and relays it, Nagle blocks relaying of a further mDNS packet until an ack is received. On a campus GigE backbone with sub-millisecond round-trip times, this potentially delays the relaying of a subsequent mDNS packet for up to 200 ms. That’s a long time on a sub-millisecond network. If the client were to send a reply to the first relayed mDNS packet, then TCP would piggyback its ack on that data packet, and Nagle would then free the server to relay the next mDNS packet.

The optimization advocated here is the observation that if a networking API were to allow the server to explicitly indicate an empty reply, then that lets the TCP stack know that it doesn’t need to wait 200 ms in the hope that it can piggyback its ack on an outbound data packet.

Without this, people are tempted to set TCP_NODELAY, which is worse overall for the network.

> 2) Further regarding keep-alives:
> in sec 6.5.2: "For example, a hypothetical keepalive interval
>   value of 100ms would result in a continuous stream of at least ten
>   messages per second, in both directions, to keep the DSO Session
>   alive."
> 
> This does not seems correct. There should be at max one keep-alives message in
> flight. Thus the keep-laives timer should only be restarted after the
> keep-alive reply was received.

On a campus GigE backbone with sub-millisecond round-trip times, even a hypothetical keepalive interval value of 100ms would still have only one keep-alive message in flight at a time. But it would still be an unreasonable keepalive interval.

>   And, in this extreme example, a single packet loss and
>   retransmission over a long path could introduce a momentary pause in
>   the stream of messages, long enough to cause the server to
>   overzealously abort the connection."
> 
> This doesn't really make sense to me: As I said, TCP will retransmit and the
> keep-alive timer should not be running until the reply is received. If you want
> to abort the connection based on keep-alives quickly before the TCP connection
> indicates you a failure, you need to wait at minimum for an interval that is
> larger than the TCP RTO (with is uaually 3 RTTs) which means you basically need
> to know the RTT.

The point of this text is to illustrate that a keepalive interval value of 100ms would be unreasonable. I think you would agree with that. This is to support why the immediately following text mandates a minimum keepalive interval of ten seconds.

> Also sec 7.1: "If the client does not generate the
>      mandated keepalive traffic, then after twice this interval the
>      server will forcibly abort the connection."
> Why must the server terminate the connection at all if the client refuses to
> send keep-alives? Isn't that what the inactivity timer is meant for? Usually
> only the endpoint that initiates the keep-alive should terminate the connection
> if no response is received.

A client cannot refuse to send keep-alives. A connection with an active mDNS relay subscription is never considered “inactive”, but a server may still require reasonable keep-alives to verify that the client is still there.

> 3) There is another contraction regarding the inactive timer:
> Sec 6.2 say
>   "A shorter inactivity timeout with a longer keepalive interval signals
>   to the client that it should not speculatively keep an inactive DSO
>   Session open for very long without reason, but when it does have an
>   active reason to keep a DSO Session open, it doesn't need to be
>   sending an aggressive level of keepalive traffic to maintain that
>   session."
> which indicates that the client may leave the session open longer than
> indicated by the inactive timer of the server. However section 7.1.1 say that
> the client MUST close the connection when the timer is expired.

A connection with an active mDNS relay subscription is never considered “inactive”, because there is still active client/server state, even if no traffic is flowing. A server may still require reasonable keep-alives to verify that the client is still there.

Stuart Cheshire