RE: STOP_SENDING

[Mike Bishop <[e-mail]>]

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:[e-mail]] On Behalf Of Subodh Iyengar
Sent: Monday, July 31, 2017 4:58 PM
To: Martin Thomson <[e-mail]>; QUIC WG <[e-mail]>
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 <[e-mail]<mailto:[e-mail]>> on behalf of Martin Thomson <[e-mail]<mailto:[e-mail]>>
Sent: Sunday, July 30, 2017 5:10 PM
To: QUIC WG
Subject: STOP_SENDING

https://github.com/quicwg/base-drafts/pull/171<https://na01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Fquicwg%2Fbase-drafts%2Fpull%2F171&data=04%7C01%7Cmichael.bishop%40microsoft.com%7C296782094b2c423d21f108d4d86fefcf%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C636371422734759522%7CUnknown%7CVW5rbm93bnx7IlYiOiIwLjAuMDAwMCIsIlAiOiJXaW4zMiIsIkFOIjoiT3RoZXIifQ%3D%3D%7C-1&sdata=W1OI1vIeX7yxBvszcG6lc7PJss6qtdI2k%2F0d8WG%2F%2BfY%3D&reserved=0>

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.