Subject: STOP_SENDING + reordering

From: Ryan Hamilton <[email-masked]>
Date: Wed, 14 Nov 2018 15:11:40 -0800

The section on STOP_SENDING says:

   Receipt of a STOP_SENDING frame is only valid for a send stream that
   exists and is not in the "Ready" state (see Section 3.1).  Receiving
   a STOP_SENDING frame for a send stream that is "Ready" or non-
   existent MUST be treated as a connection error of type
   PROTOCOL_VIOLATION.

However, I'm not sure I'm clear on what should be done in the face of
reordering, but maybe this is obvious. Say an HTTP client sends a request.
This sends a STREAM frame to the server. This move the stream to the "Send"
state. Then, the user cancels the request. So the client sends a RST_STREAM
and a STOP_SENDING in order to completely nuke the stream. However, both
the RST_STREAM and STREAM frames are lost/reordered such that the
STOP_SENDING is the first frame to arrive at the server. As such, the
stream is non-existent I think, which is prohibited. But maybe I'm not
thinking about this the right way?

---

From: Mikkel Fahnøe Jørgensen <[email-masked]>
Date: Wed, 14 Nov 2018 19:24:40 -0500

Without thinking long and hard about this …

I think you are mixing the two directions of a bidi-stream.

RST_STREAM is the sender shutting down. STOP_SENDING is the receiver
requesting a shutdown which usually results in the peer issuing a
RST_STREAM.

Hence, reordering is not important because you are sending frames relating
to two different but related streams (a bidi is two uni streams). But
sending both RST_STREAM and STOP_SENDING is only sensible if you indeed
want to close both directions, and only when the stream is a bidi stream.

NOTE:
I think that the protocol violation happens because the non-initiator is
not allowed to send anything on a stream that it has not yet seen data
from. But lower numbered streams are automatically created when larger
numbered streams of same type are created. However, if a larger ID if same
type has been seen, it might make sense to send an early STOP_SENDING of a
lower valued ID but this could lead to a protocol violation as far as I can
tell. I’m not sure that this is a good idea in this particular case - but I
can’t fully wrap my head around this right now.

On 15 November 2018 at 00.11.58, Ryan Hamilton (
rch=[email-masked]) wrote:

STOP_SENDING is the first frame to arrive at the server.. As such, the

---

From: Mike Bishop <[email-masked]>
Date: Thu, 15 Nov 2018 00:30:45 +0000

Ah, I see what you’re saying – the STREAM frame in the C2S direction is what moves the S2C direction from Ready to Send.  If STOP_SENDING can be reordered relative to that frame, this could cause a valid-when-sent STOP_SENDING frame to arrive while the S2C direction is still in the Ready state.

I think you’re correct; the prohibition on receiving STOP_SENDING in the Ready state is erroneous.  Please file an issue, and thank you!

From: QUIC <[email-masked]> On Behalf Of Ryan Hamilton
Sent: Wednesday, November 14, 2018 3:12 PM
To: IETF QUIC WG <[email-masked]>
Subject: STOP_SENDING + reordering

However, I'm not sure I'm clear on what should be done in the face of reordering, but maybe this is obvious. Say an HTTP client sends a request. This sends a STREAM frame to the server. This move the stream to the "Send" state. Then, the user cancels the request. So the client sends a RST_STREAM and a STOP_SENDING in order to completely nuke the stream. However, both the RST_STREAM and STREAM frames are lost/reordered such that the STOP_SENDING is the first frame to arrive at the server.. As such, the stream is non-existent I think, which is prohibited. But maybe I'm not thinking about this the right way?

---

From: Mikkel Fahnøe Jørgensen <[email-masked]>
Date: Wed, 14 Nov 2018 19:42:42 -0500

@Mike yes I think that is a problem. But also note the problem with lower
valued streams that are entering Ready state but cannot be stopped.

On 15 November 2018 at 01.31.03, Mike Bishop ([email-masked]) wrote:

Ah, I see what you’re saying – the STREAM frame in the C2S direction is
what moves the S2C direction from Ready to Send.  If STOP_SENDING can be
reordered relative to that frame, this could cause a valid-when-sent
STOP_SENDING frame to arrive while the S2C direction is still in the Ready
state.

I think you’re correct; the prohibition on receiving STOP_SENDING in the
Ready state is erroneous.  Please file an issue, and thank you!

*From:* QUIC <[email-masked]> *On Behalf Of * Ryan Hamilton
*Sent:* Wednesday, November 14, 2018 3:12 PM
*To:* IETF QUIC WG <[email-masked]>
*Subject:* STOP_SENDING + reordering

   PROTOCOL_VIOLATION.

---

From: Ryan Hamilton <[email-masked]>
Date: Wed, 14 Nov 2018 16:43:24 -0800

> STOP_SENDING frame to arrive while the S2C direction is still in the Ready

Bingo!

> Ready state is erroneous.  Please file an issue, and thank you!

Will do!

Hm. In the process of doing that, I see
https://github.com/quicwg/base-drafts/issues/1797 which appears to have
been closed by https://github.com/quicwg/base-drafts/pull/1802. As I read
that PR, it looks like a reordered STOP_SENDING should implicitly create
(and reset) the stream. So I guess that clarifies the technical details,
though I wonder if the language I quoted from could perhaps be made more
explicit?

---

From: Mike Bishop <[email-masked]>
Date: Thu, 15 Nov 2018 01:02:40 +0000

Looking back at those, I agree it’s the same issue, and I don’t think that PR actually fixes the original issue.  Feel free to re-open #1797 instead.

From: Ryan Hamilton <[email-masked]>
Sent: Wednesday, November 14, 2018 4:43 PM
To: Mike Bishop <[email-masked]>
Cc: IETF QUIC WG <[email-masked]>
Subject: Re: STOP_SENDING + reordering

On Wed, Nov 14, 2018 at 4:30 PM, Mike Bishop <[email-masked]<mailto:[email-masked]>> wrote:
Ah, I see what you’re saying – the STREAM frame in the C2S direction is what moves the S2C direction from Ready to Send.  If STOP_SENDING can be reordered relative to that frame, this could cause a valid-when-sent STOP_SENDING frame to arrive while the S2C direction is still in the Ready state.

Bingo!

Will do!

Hm. In the process of doing that, I see https://github.com/quicwg/base-drafts/issues/1797 which appears to have been closed by https://github.com/quicwg/base-drafts/pull/1802. As I read that PR, it looks like a reordered STOP_SENDING should implicitly create (and reset) the stream. So I guess that clarifies the technical details, though I wonder if the language I quoted from could perhaps be made more explicit?