Subject: Re: STOP_SENDING

From: Ian Swett <[email-masked]>
Date: Tue, 1 Aug 2017 12:08:46 -0400

Thanks for pointing this out.

I think it's easier to make STOP_SENDING retransmittable and then stop
sending it once a RST_STREAM is received than the alternatives.

As Martin pointed out, the MUST can be enforced well enough that I think
it's valuable.

In regards to what is retransmittable and what should be.  Most frames are
easiest left as retransmittable unless there's some benefit to other
behavior.  Acks are clear cases of this and likely any sort of flow control
update frame(including MAX_STREAM_ID) is as well, since you'd be better off
sending a new update than retransmitting the old frame.

On Mon, Jul 31, 2017 at 8:53 PM, Martin Thomson <[email-masked]>
wrote:

> Wow, nice catch Subodh, that's somewhat subtle.  This is a frame that
> affects stream state that isn't caught up in the state machine.
>
> Mike is right that you can make the retransmission logic for
> STOP_SENDING independent of the stream state, but I think that could
> be more cumbersome to manage in implementation than is ideal.
>
> I think that the simple fix here is as Subodh suggests: mandate the
> sending of RST_STREAM in response to STOP_SENDING unless the stream is
> already closed.  We can then note the optimization that this enables:
> you can stop sending STOP_SENDING when the stream is closed.
>
> Regarding MUST - I recognize that we fall back to the halting problem,
> but I can still construct a test that will in most cases detect
> misbehaviour: have someone send an infinitely long stream, send
> STOP_SENDING in every packet, if they acknowledge packets for some
> time without sending RST_STREAM, something is badly wrong.  It's not
> deterministic, but it's still worth mandating.
>
> Mike,
>
> The relationship between retransmissions and stream states is
> something that remains open in my mind.  What we have appears to be
> largely driven by some design choices in the Google implementation.  I
> don't know if we have an open issue that tracks that, we've
> flip-flopped on our position over time and I don't think that we have
> a firm consensus on this.  That said, it matters much less now that we
> have MAX_STREAM_ID.
>
>
> On 1 August 2017 at 10:29, Mike Bishop <[email-masked]>
> wrote:
> > Yeah, the retransmission piece of it is interesting.  I can see an
> argument
> > for making it non-retransmittable, but having guidance to periodically
> > resend it if you continue to receive data.  (Kind of like ACKs – you
> don’t
> > blindly re-send the frame, you re-evaluate what needs to be sent.)
> However,
> > that seems heavier-weight than simply sending it reliably.  Note that
> only
> > STREAM frames block the transition to “closed,” and even there the
> > transition happens when you have “completed sending,” which I don’t read
> as
> > everything having been ACK’d unless we added that definition somewhere
> else.
> >
> >
> >
> > The previous RST was only somewhat bidirectional – when you sent a
> > RST_STREAM, you didn’t know the other side’s final offset, so you
> couldn’t
> > wind down their side of the stream until they also sent a RST_STREAM.
> > That’s still the case, but now it’s more honest – the stream continues
> to be
> > open in the other direction until they actually send the RST_STREAM.
> >
> >
> >
> > Conceptually, I’d be okay with a “MUST send RST_STREAM unless the stream
> is
> > already closed,” but this is almost impossible to verify, even if you
> start
> > tracking what streams show up in packet numbers after the ACK of the
> packet
> > that contained the STOP_SENDING frame.  My general rule is that if the
> other
> > party can’t be certain whether you violated a MUST, it needs to be a
> SHOULD.
> >
> >
> >
> > From: QUIC [mailto:[email-masked]] On Behalf Of Subodh Iyengar
> > Sent: Monday, July 31, 2017 4:58 PM
> > To: Martin Thomson <[email-masked]>; QUIC WG <[email-masked]>
> > Subject: Re: STOP_SENDING
> >
> >
> >
> > I commented on the PR, but had a design comment
> >
> > Sending one more frame type has the added burden of needing to
> retransmit it
> > before we go to closed state unless we make STOP_SENDING non
> > retransmittable. Since this frame type is advisory anyway, does it really
> > need to be retransmittable? Also it doesn't make sense to send this if we
> > have received the peers RST. A peer's RST might have raced with our
> > STOP_SENDING and the peer might have got rid of state for the stream.
> Thus
> > any retransmitted STOP_SENDING frames might just be ignored.
> >
> >
> >
> > Previously we had a bidirectional RST. With this change, it makes me a
> bit
> > nervous for an endpoint to rely on a peer following advisory behavior for
> > them to be able to close their stream, for example what would we do
> about a
> > client that chooses not to send a RST on STOP_SENDING, do we rely on
> stream
> > limits only? close the connection? It would be much more comfortable
> with a
> > client MUST send a RST when getting a STOP_SENDING.
> >
> > Subodh
> >
> >
> >
> > ________________________________
> >
> > From: QUIC <[email-masked]> on behalf of Martin Thomson
> > <[email-masked]>
> > Sent: Sunday, July 30, 2017 5:10 PM
> > To: QUIC WG
> > Subject: STOP_SENDING
> >
> >
> >
> > https://github.com/quicwg/base-drafts/pull/171
> >
> > As mentioned in Prague, I want to merge the PR formerly known as
> > DISINTEREST.  Mike has updated it and it is now ready to do.  I plan
> > to merge this in 48 hours, absent any substantial objections.
>
>

---

From: Mikkel Fahnøe Jørgensen <[email-masked]>
Date: Tue, 1 Aug 2017 09:49:44 -0700

I’m only half reading along atm., but I don’t think it is good for the
retransmission logic to reach back into stream state if it can be avoided,
or vice versa. It can be done of course, and this is probably not the only
place.

If STOP_SENDING is not retransmittable, some timer state is needed, which
is annoying, so I agree with IAN that retransmission is easier, just not
that RST_STREAM necessarily must cancel - it can race regardless.
If STOP_SENDING is retransmittable, it is fire and forget. Should a
RST_STREAM be received meanwhile, the late STOP_SENDING should do no harm.
No point in making it an error to receive late STOP_SENDING, other than the
general receive stream related packets very late.

Kind Regards,
Mikkel Fahnøe Jørgensen

On 1 August 2017 at 18.09.19, Ian Swett ([email-masked]) wrote:

---

From: Mike Bishop <[email-masked]>
Date: Tue, 1 Aug 2017 18:14:59 +0000

Okay – I’ve changed the SHOULD to a MUST and added similar text to that about STREAM frames – “MUST retransmit unless….”  In the section specifically about requesting the peer to stop sending, it says that you MAY stop retransmission if the stream has closed on its own.

From: Mikkel Fahnøe Jørgensen [mailto:[email-masked]]
Sent: Tuesday, August 1, 2017 9:50 AM
To: Martin Thomson <[email-masked]>; Ian Swett <[email-masked]>
Cc: QUIC WG <[email-masked]>; Mike Bishop <[email-masked]>; Subodh Iyengar <[email-masked]>
Subject: Re: STOP_SENDING

> I think it's easier to make STOP_SENDING retransmittable and then stop sending it once a RST_STREAM is received than the alternatives.

I’m only half reading along atm., but I don’t think it is good for the retransmission logic to reach back into stream state if it can be avoided, or vice versa. It can be done of course, and this is probably not the only place.

If STOP_SENDING is not retransmittable, some timer state is needed, which is annoying, so I agree with IAN that retransmission is easier, just not that RST_STREAM necessarily must cancel - it can race regardless.
If STOP_SENDING is retransmittable, it is fire and forget. Should a RST_STREAM be received meanwhile, the late STOP_SENDING should do no harm. No point in making it an error to receive late STOP_SENDING, other than the general receive stream related packets very late.

Kind Regards,
Mikkel Fahnøe Jørgensen

On 1 August 2017 at 18.09.19, Ian Swett ([email-masked]<mailto:[email-masked]>) wrote:
I think it's easier to make STOP_SENDING retransmittable and then stop sending it once a RST_STREAM is received than the alternatives.

---

From: Martin Thomson <[email-masked]>
Date: Wed, 2 Aug 2017 10:06:22 +1000

On 2 August 2017 at 02:49, Mikkel Fahnøe Jørgensen <[email-masked]> wrote:
> or vice versa.

This would be an optimization only.  There is no harm in
retransmitting STOP_SENDING until it is acknowledged, but stream end
is a way to cut that off early.