Draft: draft-ietf-quic-applicability

Commentary: An alternate approach to , following from comment thereon . 
 I think the new text is now missing two points : 1 ) It might make sense to send keep - alives if the application know that is there is new data coming , e.g. an outstating reply or a following request . I think this is what is recommended for http . 2 ) as meantion in the transport draft we should probably say again that it must be clearly specified which party is performing the active ping - ing Also the text basically " just " explains the situation but does n't really make any recommendation . Do we maybe what to say more than that ? 
  , unicorns mean that I ca n't see comments here , though they appeared in email . In response to those , maybe it is OK to point to HTTP / QUIC 's recommendations about keep - alives . There , it recommends limiting use of PING for keep - alive to while a request is outstanding . 
 The transport draft says : " The PING frame can be used to keep a connection alive when an application or application protocol wishes to prevent the connection from timing out . An application protocol SHOULD provide guidance about the conditions under which generating a PING is recommended . This guidance SHOULD indicate whether it is the client or the server that is expected to send the PING . Having both endpoints send PING frames without coordination can produce an excessive number of packets and poor performance . " Probably we should state this in the applicability statement as well ... 
 The transport draft also provides guidance on on the ping interval : " A connection will time out if no packets are sent or received for a period longer than the time specified in the idle_timeout transport parameter ( see { { termination } } ) . However , state in middleboxes might time out earlier than that . Though  in { { ? RFC4787 } } recommends a 2 minute timeout interval , experience shows that sending packets every 15 to 30 seconds is necessary to prevent the majority of middleboxes from losing state for UDP flows . " 
 That is not intended as guidance , but a caution . This is something that firmly fits in the application space . For instance , in HTTP , sending PING frames to keep the connection alive might be appropriate when a request is outstanding , but it should n't be used otherwise . 
 I a bit of text in PR . Can you have a look at it ? 
 Resolved by PR
Paragraph (version B):
Because QUIC is encapsulated in UDP, applications using QUIC must
deal with short idle timeouts.  Deployed stateful middleboxes will
generally establish state for UDP flows on the first packet state,
and keep state for much shorter idle periods than for TCP.  According
to a 2010 study (Hatonen10), UDP applications can assume that any NAT
binding or other state entry will be expired after just thirty
seconds of inactivity.
Paragraph (version B):
Ignore it, if the application-layer protocol consists only of
interactions with no or very short idle periods.
Paragraph (version B):
Ensure there are no long idle periods.
Paragraph (version B):
Resume the session after a long idle period, using 0-RTT
resumption when appropriate.
Paragraph (version B):
The first strategy is the easiest, but it only applies to certain
applications.
Paragraph (version B):
Either the server or the client in a QUIC application can send PING
frames as keep-alives, to prevent the connection and any on-path
state from timing out.  Recommendations for the use of keep-alives
are application specific, mainly depending on the latency
requirements and message frequency of the application.  In this case,
the application mapping must specify whether the client or server is
responsible for keeping the application alive.  Note that sending
PING frames more frequently than every 30 seconds over long idle
periods may result in a too much unproductive traffic and power usage
for some situations.
Paragraph (version B):
Alternatively, the client (but not the server) can use session
resumption instead of sending keepalive traffic.  In this case, a
client that wants to send data to a server over a connection idle
longer than the server's idle timeout (available from the
idle_timeout transport parameter) can simply reconnect.  When
possible, this reconnection can use 0-RTT session resumption,
reducing the latency involved with restarting the connection.  This
of course only applies in cases in which 0-RTT data is safe, when the
client is the restarting peer, and when the data to be sent is
idempotent.
Paragraph (version B):
The tradeoffs between resumption and keepalive need to be evaluated
on a per-application basis.  However, in general applications should
use keepalives only in circumstances where continued communication is
highly likely; QUIC-HTTP, for instance, recommends using PING frames
for keepalive only when a request is outstanding.