Subject: [quic-protocol] "outstanding data" retransmission

From: Tatsuhiro Tsujikawa <[email-masked]>
Date: Fri, 25 Nov 2016 00:46:14 +0900

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

---

From: Ryan Hamilton <[email-masked]>
Date: Thu, 24 Nov 2016 07:56:59 -0800

> valid use case described in RFC 7540, section 8.1:

​Indeed, when a RST_STREAM NO_ERROR is sent the endpoint should continue
retransmitting outstanding data.

---

From: Martin Thomson <[email-masked]>
Date: Fri, 25 Nov 2016 11:25:52 +1100

On 25 November 2016 at 02:56, Ryan Hamilton <[email-masked]> wrote:
> Indeed, when a RST_STREAM NO_ERROR is sent the endpoint should continue

That's a fairly ugly exception to an otherwise clean function (kill
this stream).  Now you have a code that is (half-kill this stream).

The reason that this works in HTTP/2 is that we don't really have any
option to give up on retransmission.

I would prefer to find a cleaner solution for this.  If that's an
error code, then we should make an explicit half-reset code.

---

From: Ryan Hamilton <[email-masked]>
Date: Sun, 27 Nov 2016 07:48:14 -0800

> error code, then we should make an explicit half-reset code.

​A different error code is fine with me. Being consistent by using the same
code as HTTP/2 seemed nice ​but if folks find that more confusing I'm fine
with that.

---

From: Mike Bishop <[email-masked]>
Date: Sun, 27 Nov 2016 21:37:59 +0000

Well, remember that the HTTP/2 semantic is "I no longer care about what you're sending."  Maybe we meet in the middle and say that you shouldn't continue sending only after receipt?  After sending, you don't have any acknowledgement from the remote side that they don't care about what you're sending.  If they actually don't care, they can RST_STREAM in turn.

-----Original Message-----
From: QUIC [mailto:[email-masked]] On Behalf Of Martin Thomson
Sent: Thursday, November 24, 2016 4:26 PM
To: Ryan Hamilton <[email-masked]>
Cc: IETF QUIC WG <[email-masked]>; Tatsuhiro Tsujikawa <[email-masked]>
Subject: Re: [quic-protocol] "outstanding data" retransmission

On 25 November 2016 at 02:56, Ryan Hamilton <[email-masked]> wrote:
> Indeed, when a RST_STREAM NO_ERROR is sent the endpoint should 
> continue retransmitting outstanding data.

That's a fairly ugly exception to an otherwise clean function (kill this stream).  Now you have a code that is (half-kill this stream).

The reason that this works in HTTP/2 is that we don't really have any option to give up on retransmission.

I would prefer to find a cleaner solution for this.  If that's an error code, then we should make an explicit half-reset code.

---

From: Martin Thomson <[email-masked]>
Date: Mon, 28 Nov 2016 09:47:01 +1100

> Well, remember that the HTTP/2 semantic is "I no longer care about what you're sending."  Maybe we meet in the middle and say that you shouldn't continue sending only after receipt?  After sending,…

That has a subtly different effect.  The client has to wait for the
end of the response.  If the response takes any time to arrive, the
client is still obligated to send.  That said, I think that's the most
workable solution here.  I would like to ensure that a reset is a
reset.