[quic-protocol] "outstanding data" retransmission

[Tatsuhiro Tsujikawa <[e-mail]>]

Hi,

I have a question regarding "outstanding data" retransmission specifically,
https://tools.ietf.org/html/draft-hamilton-quic-transport-protocol-01#section-7

"""
   A packet may contain frames and/or application data, only some of
   which may require reliability.  When a packet is detected as lost,
   the sender SHOULD only resend frames that require retransmission.

   o  All application data sent in STREAM frames MUST be retransmitted,
      with one exception.  When an endpoint sends a RST_STREAM frame,
      data outstanding on that stream SHOULD NOT be retransmitted, since
      subsequent data on this stream is expected to not be delivered by
      the receiver.
"""

First bullet states that endpoint should not retransmit data
outstanding on the stream where it sent RST_STREAM.

The question is: what "data outstanding" actually means?  Is the
STREAM frame that has been sent before sending RST_STREAM and not
ACKed yet?  Or it the STREAM frame which has not sent yet?  Or
both?

I suspect that it means the STREAM frame that has been sent
before RST_STREAM but not ACKed yet.  This is because the above
text uses "retransmitted" which indicates that they have been
sent once.  And sending STREAM frame after RST_STREAM is
obviously protocol error.

If it is correct, and if we assume that RST_STREAM of HTTP/2 is
directly mapped to quic's RST_STREAM (well, this is not mentioned
in h2 mapping document, not sure why), we might miss the
valid use case described in RFC 7540, section 8.1:

https://tools.ietf.org/html/rfc7540#section-8.1

"""
   An HTTP response is complete after the server sends -- or the client
   receives -- a frame with the END_STREAM flag set (including any
   CONTINUATION frames needed to complete a header block).  A server can
   send a complete response prior to the client sending an entire
   request if the response does not depend on any portion of the request
   that has not been sent and received.  When this is true, a server MAY
   request that the client abort transmission of a request without error
   by sending a RST_STREAM with an error code of NO_ERROR after sending
   a complete response (i.e., a frame with the END_STREAM flag).
   Clients MUST NOT discard responses as a result of receiving such a
   RST_STREAM, though clients can always discard responses at their
   discretion for other reasons.
"""

If packet containing STREAM and RST_STREAM frames is lost, then
we will retransmit, but we
​are ​
only allowed to retransmit RST_STREAM.
We can still send RST_STREAM after getting ACK against STREAM
frame from peer, but it incurs latency, and it is unnecessarily
complicated.  Over TCP, we just send them in one packet, and it
works fine.



Best regards,
Tatsuhiro Tsujikawa