Subject: DISINTEREST frame

From: Mike Bishop <[email-masked]>
Date: Tue, 7 Mar 2017 18:45:38 +0000

At the Tokyo interim, we had a discussion around Issue #165<https://github.com/quicwg/base-drafts/issues/165>, PR #171<https://github.com/quicwg/base-drafts/pull/171> proposing a REQUEST_RST frame, and the fact that Google QUIC currently special-cases the same semantics to a RST_STREAM with a specific error code.  (There is a TODO in the text to write up this "special case.")  My sense of the consensus at the interim was that special casing particular error codes felt hacky, and there was moderate support for making it a different frame type altogether, but people wanted to look at the PR in more detail.

At Martin's suggestion, the frame in the PR has been renamed to DISINTEREST.  It's an explicit signal that incoming data is not being read by the application and will be discarded by the transport upon receipt; the receiver of a DISINTEREST frame is suggested to abruptly terminate the stream in question.  In terms of application API, think of it as the wire signal that the read handle has been closed.

I think this should explicitly not be a special case of a RST_STREAM error code, because it has different semantics around retransmissions.  In particular, the sender of a DISINTEREST frame might still be sending data, still be retransmitting lost STREAM frames, and still expecting that data to be consumed.  A special case around whether to process the incoming data, I could accept; a special case around whether retransmission is still enabled on the stream feels really wrong.

In order to enable this, the PR changes the semantics of RST_STREAM as well.  Streams consist of a data channel in each direction.  That data channel can be closed cleanly (FIN) or abruptly (RST_STREAM) in each direction.  If cleanly, data gets retransmitted in that direction.  If abruptly, nothing more will be sent, whether it got through or not.  Only the sender can close their data channel, and only they decide how and when it closes.  (Though DISINTEREST is a strong signal there's no point in continuing to transmit.)

In Tokyo, we said we wanted to wait while folks reviewed the PR.  We've had a month, and I've gotten some good feedback from one more person (thanks, Lucas!).  Have people reviewed and are okay with it?  Have people not looked and violently disagree?  If so, let's discuss.  We still have a few days before the draft deadline; maybe we can reach consensus before -02?

---

From: Martin Thomson <[email-masked]>
Date: Wed, 8 Mar 2017 12:34:03 +1100

I think that this is a step in the right direction.  We have use cases
that this serves.

On 8 March 2017 at 05:45, Mike Bishop <[email-masked]> wrote:
> At the Tokyo interim, we had a discussion around Issue #165, PR #171
> proposing a REQUEST_RST frame, and the fact that Google QUIC currently
> special-cases the same semantics to a RST_STREAM with a specific error code.
> (There is a TODO in the text to write up this “special case.”)  My sense of
> the consensus at the interim was that special casing particular error codes
> felt hacky, and there was moderate support for making it a different frame
> type altogether, but people wanted to look at the PR in more detail.
>
>
>
> At Martin’s suggestion, the frame in the PR has been renamed to DISINTEREST.
> It’s an explicit signal that incoming data is not being read by the
> application and will be discarded by the transport upon receipt; the
> receiver of a DISINTEREST frame is suggested to abruptly terminate the
> stream in question.  In terms of application API, think of it as the wire
> signal that the read handle has been closed.
>
>
>
> I think this should explicitly not be a special case of a RST_STREAM error
> code, because it has different semantics around retransmissions.  In
> particular, the sender of a DISINTEREST frame might still be sending data,
> still be retransmitting lost STREAM frames, and still expecting that data to
> be consumed.  A special case around whether to process the incoming data, I
> could accept; a special case around whether retransmission is still enabled
> on the stream feels really wrong.
>
>
>
> In order to enable this, the PR changes the semantics of RST_STREAM as well.
> Streams consist of a data channel in each direction.  That data channel can
> be closed cleanly (FIN) or abruptly (RST_STREAM) in each direction.  If
> cleanly, data gets retransmitted in that direction.  If abruptly, nothing
> more will be sent, whether it got through or not.  Only the sender can close
> their data channel, and only they decide how and when it closes.  (Though
> DISINTEREST is a strong signal there’s no point in continuing to transmit.)
>
>
>
> In Tokyo, we said we wanted to wait while folks reviewed the PR.  We’ve had
> a month, and I’ve gotten some good feedback from one more person (thanks,
> Lucas!).  Have people reviewed and are okay with it?  Have people not looked
> and violently disagree?  If so, let’s discuss.  We still have a few days
> before the draft deadline; maybe we can reach consensus before -02?

---

From: Ryan Hamilton <[email-masked]>
Date: Tue, 7 Mar 2017 18:40:17 -0800

Sounds reasonable to me. We should also clarify the impact it has on
flow-control. I assume that since the sender of such a frame will not be
reading, the receiver of the frame (and the sender of data) needs to stop
sending since it will not be receiving flow control updates.

We'll also want to clarify the HTTP mapping since HTTP/2 defines the
RST_STREAM + NO_ERROR semantics that is leveraged in the current QUIC doc.

But these are both minor points.

---

From: "Lubashev, Igor" <[email-masked]>
Date: Wed, 8 Mar 2017 03:01:18 +0000

A minor point.

+ [...] If the DISINTEREST frame is received on a
+stream that is already in the "half-closed (local)" or "closed" states, a
+RST_STREAM frame SHOULD still be sent

What if the sender already received an ACK for a packet that contained FIN or RST_STREAM for that stream?  Is the recommendation still "SHOULD send RST_STREAM"? (This can happen in case of packet reordering.)

-----Original Message-----
From: Martin Thomson [mailto:[email-masked]] 
Sent: Tuesday, March 07, 2017 8:34 PM
To: Mike Bishop <[email-masked]>
Cc: IETF QUIC WG <[email-masked]>
Subject: Re: DISINTEREST frame

I think that this is a step in the right direction.  We have use cases that this serves.

On 8 March 2017 at 05:45, Mike Bishop <[email-masked]> wrote:
> (There is a TODO in the text to write up this “special case.”)  My 
> sense of the consensus at the interim was that special casing 
> particular error codes felt hacky, and there was moderate support for 
> making it a different frame type altogether, but people wanted to look at the PR in more detail.
>
>
>
> stream in question.  In terms of application API, think of it as the 
> wire signal that the read handle has been closed.
>
>
>
> I think this should explicitly not be a special case of a RST_STREAM 
> error code, because it has different semantics around retransmissions.  
> In particular, the sender of a DISINTEREST frame might still be 
> sending data, still be retransmitting lost STREAM frames, and still 
> expecting that data to be consumed.  A special case around whether to 
> process the incoming data, I could accept; a special case around 
> whether retransmission is still enabled on the stream feels really wrong.
>
>
>
> Streams consist of a data channel in each direction.  That data 
> channel can be closed cleanly (FIN) or abruptly (RST_STREAM) in each 
> direction.  If cleanly, data gets retransmitted in that direction.  If 
> abruptly, nothing more will be sent, whether it got through or not.  
> Only the sender can close their data channel, and only they decide how 
> and when it closes.  (Though DISINTEREST is a strong signal there’s no 
> point in continuing to transmit.)
>
>
>
> In Tokyo, we said we wanted to wait while folks reviewed the PR.  
> We’ve had a month, and I’ve gotten some good feedback from one more 
> person (thanks, Lucas!).  Have people reviewed and are okay with it?  
> Have people not looked and violently disagree?  If so, let’s discuss.  
> We still have a few days before the draft deadline; maybe we can reach consensus before -02?

---

From: Martin Thomson <[email-masked]>
Date: Wed, 8 Mar 2017 14:34:25 +1100

> What if the sender already received an ACK for a packet that contained FIN or RST_STREAM for that stream?  Is the recommendation still "SHOULD send RST_STREAM"? (This can happen in case of packet r…

I think that the advice should be that RST_STREAM is sent unless all
outstanding data has been sent AND acknowledged.  You are right, if
the state is all long gone, likely due to reordering, then there is no
point in resetting.

---

From: "Lubashev, Igor" <[email-masked]>
Date: Wed, 8 Mar 2017 03:51:39 +0000

Why require ALL outstanding data to be ACKed to suppress RST_SYREAM? Why is an ACK of FIN not enough? The peer now has the stream in "half-closed (remote)" or "closed" already; he is not keeping any rcv data buffers anymore; why send RST_STREAM?

---

From: Martin Thomson <[email-masked]>
Date: Wed, 8 Mar 2017 14:53:52 +1100

On 8 March 2017 at 14:51, Lubashev, Igor <[email-masked]> wrote:
> Why require ALL outstanding data to be ACKed to suppress RST_SYREAM? Why is
> an ACK of FIN not enough? The peer now has the stream in "half-closed
> (remote)" or "closed" already; he is not keeping any rcv data buffers
> anymore; why send RST_STREAM?

You can ACK the packet that contained FIN without ever having received
the packet that preceded it.  In that case, you want to send
RST_STREAM to say "I'm going to stop retransmitting those bytes."

---

From: "Lubashev, Igor" <[email-masked]>
Date: Wed, 8 Mar 2017 04:27:08 +0000

Why do you need to say "I'm going to stop retransmitting those bytes" to someone who just told you that "I'm going to throw away anything I receive from you" (DISINTEREST)?

---

From: Martin Thomson <[email-masked]>
Date: Wed, 8 Mar 2017 15:28:37 +1100

On 8 March 2017 at 15:27, Lubashev, Igor <[email-masked]> wrote:
> Why do you need to say "I'm going to stop retransmitting those bytes" to
> someone who just told you that "I'm going to throw away anything I receive
> from you" (DISINTEREST)?

Because DISINTEREST doesn't actually affect the state of the stream,
it's a request to the sender of a stream to cease transmission.  The
bytes will still be delivered unless the sender explicitly abandons
them.

---

From: "Lubashev, Igor" <[email-masked]>
Date: Wed, 8 Mar 2017 04:35:19 +0000

We are taking about a case when the sender of the stream is already in "half-closed (local)" (or "closed") and the receiver is already in "half-closed (remote)" (or "closed"). This RST_STREAM will not affect the state of the stream for any peer. The only information RST_STREAM contains now is "I will not transmit". But the peer already sent DISINTERESTED to indicate it does not care about retransmissions.

---

From: Martin Thomson <[email-masked]>
Date: Wed, 8 Mar 2017 15:41:46 +1100

On 8 March 2017 at 15:35, Lubashev, Igor <[email-masked]> wrote:
> We are taking about a case when the sender of the stream is already in
> "half-closed (local)" (or "closed") and the receiver is already in
> "half-closed (remote)" (or "closed"). This RST_STREAM will not affect the
> state of the stream for any peer. The only information RST_STREAM contains
> now is "I will not transmit". But the peer already sent DISINTERESTED to
> indicate it does not care about retransmissions.

Even after closing a stream, an endpoint needs to retransmit data.  It
closes when it first sends the FIN.

---

From: Ian Swett <[email-masked]>
Date: Wed, 8 Mar 2017 09:51:10 -0500

Martin's right, you definitely need "RST_STREAM is sent unless all
outstanding data has been sent AND acknowledged.", otherwise the peer waits
forever for data that won't arrive.

Question: Why call it DISINTEREST, instead of REQUEST_RST?  It wasn't
obvious to me what DISINTEREST was until I read further, whereas
REQUEST_RST is pretty obvious, assuming you know about RST_STREAM.

---

From: Mike Bishop <[email-masked]>
Date: Wed, 8 Mar 2017 16:07:38 +0000

Both names are about equal to me.  REQUEST_RST is a very clear statement at the transport level of what it does.  DISINTEREST is a very clear statement about what application behavior it reflects and why you’d send it.  Both names are somewhat opaque from the opposite standpoint.

I think Martin has some ultimate goal of moving away from the baggage that comes with the terms RST and FIN from TCP.  If so, he can expound when it’s convenient for him.

From: Ian Swett [mailto:[email-masked]]
Sent: Wednesday, March 8, 2017 6:51 AM
To: Martin Thomson <[email-masked]>
Cc: Lubashev, Igor <[email-masked]>; Mike Bishop <[email-masked]>; [email-masked]
Subject: Re: DISINTEREST frame

Martin's right, you definitely need "RST_STREAM is sent unless all outstanding data has been sent AND acknowledged.", otherwise the peer waits forever for data that won't arrive.

Question: Why call it DISINTEREST, instead of REQUEST_RST?  It wasn't obvious to me what DISINTEREST was until I read further, whereas REQUEST_RST is pretty obvious, assuming you know about RST_STREAM.

On Tue, Mar 7, 2017 at 11:41 PM, Martin Thomson <[email-masked]<mailto:[email-masked]>> wrote:

---

From: Mike Bishop <[email-masked]>
Date: Wed, 8 Mar 2017 16:09:41 +0000

That’s a good point – the PR currently discusses the impact on connection-level flow control (everything works like normal), but doesn’t discuss what either party should do with stream-level flow control.  Probably just letting it block is fine – the sender will probably see the DISINTEREST before they get blocked, and if not, there’s no harm.

From: Ryan Hamilton [mailto:[email-masked]]
Sent: Tuesday, March 7, 2017 6:40 PM
To: Martin Thomson <[email-masked]>
Cc: Mike Bishop <[email-masked]>; IETF QUIC WG <[email-masked]>
Subject: Re: DISINTEREST frame

Sounds reasonable to me. We should also clarify the impact it has on flow-control. I assume that since the sender of such a frame will not be reading, the receiver of the frame (and the sender of data) needs to stop sending since it will not be receiving flow control updates.

We'll also want to clarify the HTTP mapping since HTTP/2 defines the RST_STREAM + NO_ERROR semantics that is leveraged in the current QUIC doc.

On Tue, Mar 7, 2017 at 5:34 PM, Martin Thomson <[email-masked]<mailto:[email-masked]>> wrote:
I think that this is a step in the right direction.  We have use cases
that this serves.

---

From: "Lubashev, Igor" <[email-masked]>
Date: Wed, 8 Mar 2017 17:10:17 +0000

Ø  you definitely need "RST_STREAM is sent unless all outstanding data has been sent AND acknowledged.", otherwise the peer waits forever for data that won't arrive.

I guess this is the core of the question, which goes beyond the choice for this rare condition. “It is reasonable to think that the peer who sent DISINTEREST is still waiting for any data?”  The whole point of DISINTEREST is to indicate that “I am not waiting for any more data”.

From: Ian Swett [mailto:[email-masked]]
Sent: Wednesday, March 08, 2017 9:51 AM
To: Martin Thomson <[email-masked]>
Cc: Lubashev, Igor <[email-masked]>; [email-masked]; [email-masked]
Subject: Re: DISINTEREST frame

---

From: "Lubashev, Igor" <[email-masked]>
Date: Wed, 8 Mar 2017 17:18:33 +0000

P.S.
  The paragraph above states:

Ø  [STREAM frames received after sending DISINTEREST] will be discarded

So I read it that the peer who send DISINTEREST will not be waiting for that data.  That peer does not need any accounting for flow control either, since he has already received the FIN (with the byte offset) and is already in “half-closed (remote)” or “closed” state.

From: Lubashev, Igor [mailto:[email-masked]]
Sent: Wednesday, March 08, 2017 12:10 PM
To: Ian Swett <[email-masked]>; Martin Thomson <[email-masked]>
Cc: [email-masked]; [email-masked]
Subject: RE: DISINTEREST frame

From: Ian Swett [mailto:[email-masked]]
Sent: Wednesday, March 08, 2017 9:51 AM
To: Martin Thomson <[email-masked]<mailto:[email-masked]>>
Cc: Lubashev, Igor <[email-masked]<mailto:[email-masked]>>; [email-masked]<mailto:[email-masked]>; [email-masked]<mailto:[email-masked]>
Subject: Re: DISINTEREST frame

---

From: Mike Bishop <[email-masked]>
Date: Wed, 8 Mar 2017 17:53:42 +0000

You’re correct that the sender of DISINTEREST no longer cares about the data, other than for flow control and state consistency.

I had been trying to approach it from a principle that only the sender can affect the stream state in their direction – the receiver can only request changes.  As the draft currently reads, the receiver counts flow control as STREAM frames are received, and upon receipt of a RST_STREAM.  If a STREAM frame is delayed, it doesn’t (yet) count against the receiver’s flow control window, even if it can infer that the data has been sent (by virtue of receiving a later offset).  Only upon receipt of a RST_STREAM do you account all outstanding data against the flow control window.

Changing it so that all data up to the furthest offset received on a stream counts is certainly possible, but feels like an orthogonal change to this PR.  I’ve opened issue #370 for that.  In that world, the requirement would be to reliably deliver either a RST_STREAM or a STREAM frame with the FIN bit set (basically, you MUST communicate your final offset).  So long as one of those gets through, DISINTEREST by itself could stop retransmissions.  That feels marginally more complicated, since it adds an additional path to stop retransmission on a stream and makes the accounting logic on receipt of a STREAM frame more complicated.

My inclination is to leave retransmissions tied to having sent RST_STREAM, but I’ll defer to others whether the complexity is worth the potential savings.

From: Lubashev, Igor [mailto:[email-masked]]
Sent: Wednesday, March 8, 2017 9:19 AM
To: Lubashev, Igor <[email-masked]>; Ian Swett <[email-masked]>; Martin Thomson <[email-masked]>
Cc: Mike Bishop <[email-masked]>; [email-masked]
Subject: RE: DISINTEREST frame

P.S.

  *   [STREAM frames received after sending DISINTEREST] will be discarded

From: Lubashev, Igor [mailto:[email-masked]]
Sent: Wednesday, March 08, 2017 12:10 PM
To: Ian Swett <[email-masked]<mailto:[email-masked]>>; Martin Thomson <[email-masked]<mailto:[email-masked]>>
Cc: [email-masked]<mailto:[email-masked]>; [email-masked]<mailto:[email-masked]>
Subject: RE: DISINTEREST frame

  *   you definitely need "RST_STREAM is sent unless all outstanding data has been sent AND acknowledged.", otherwise the peer waits forever for data that won't arrive.

---

From: Martin Thomson <[email-masked]>
Date: Thu, 9 Mar 2017 08:07:49 +1100

On 9 March 2017 at 03:07, Mike Bishop <[email-masked]> wrote:
> I think Martin has some ultimate goal of moving away from the baggage that
> comes with the terms RST and FIN from TCP.  If so, he can expound when it’s
> convenient for him.

At some point I plan to propose new names for these control related
mechanisms.  FIN, RST, and SYN have proven to carry some baggage.

---

From: "Lubashev, Igor" <[email-masked]>
Date: Thu, 9 Mar 2017 04:36:23 +0000

Thanks for opening the issue, Mike!

> In that world, the requirement would be to reliably
> deliver either a RST_STREAM or a STREAM frame
> with the FIN bit set (basically, you MUST
> communicate your final offset). So long as one of
> those gets through, DISINTEREST by itself could
> stop retransmissions. That feels marginally more
> complicated

Here is where our sense of "complexity" differs. To me, RST_STREAM and STREAM+FIN are virtually identical, because they cause identical transitions of stream states. It is just that the former says "I am done and will not retransmit" while the later says "I am done and will retransmit (unless you tell me you do not need my data -- something I am arguing is implicit in this promise)".

-----Original Message-----
From: Mike Bishop [[email-masked]]
Received: Wednesday, 08 Mar 2017, 12:53PM
To: Lubashev, Igor [[email-masked]]; Ian Swett [[email-masked]]; Martin Thomson [[email-masked]]
CC: [email-masked] [[email-masked]]
Subject: RE: DISINTEREST frame

You're correct that the sender of DISINTEREST no longer cares about the data, other than for flow control and state consistency.

I had been trying to approach it from a principle that only the sender can affect the stream state in their direction - the receiver can only request changes.  As the draft currently reads, the receiver counts flow control as STREAM frames are received, and upon receipt of a RST_STREAM.  If a STREAM frame is delayed, it doesn't (yet) count against the receiver's flow control window, even if it can infer that the data has been sent (by virtue of receiving a later offset).  Only upon receipt of a RST_STREAM do you account all outstanding data against the flow control window.

Changing it so that all data up to the furthest offset received on a stream counts is certainly possible, but feels like an orthogonal change to this PR.  I've opened issue #370 for that.  In that world, the requirement would be to reliably deliver either a RST_STREAM or a STREAM frame with the FIN bit set (basically, you MUST communicate your final offset).  So long as one of those gets through, DISINTEREST by itself could stop retransmissions.  That feels marginally more complicated, since it adds an additional path to stop retransmission on a stream and makes the accounting logic on receipt of a STREAM frame more complicated.

My inclination is to leave retransmissions tied to having sent RST_STREAM, but I'll defer to others whether the complexity is worth the potential savings.

P.S.

So I read it that the peer who send DISINTEREST will not be waiting for that data.  That peer does not need any accounting for flow control either, since he has already received the FIN (with the byte offset) and is already in "half-closed (remote)" or "closed" state.

I guess this is the core of the question, which goes beyond the choice for this rare condition. "It is reasonable to think that the peer who sent DISINTEREST is still waiting for any data?"  The whole point of DISINTEREST is to indicate that "I am not waiting for any more data".

---

From: Mirja Kühlewind <[email-masked]>
Date: Thu, 9 Mar 2017 11:50:17 +0100

Okay, that's now a little bit a hack but after sending DISINTEREST you could 
just acknowledge all data up to the highest packet number you've seen, no 
matter if you received them or not because you don't need them anymore 
anynway; that would avoid any retransmissions...

Mirja

On 08.03.2017 18:53, Mike Bishop wrote:
> You’re correct that the sender of DISINTEREST no longer cares about the data,
> other than for flow control and state consistency.
>
>
>
> I had been trying to approach it from a principle that only the sender can
> affect the stream state in their direction – the receiver can only request
> changes.  As the draft currently reads, the receiver counts flow control as
> STREAM frames are received, and upon receipt of a RST_STREAM.  If a STREAM
> frame is delayed, it doesn’t (yet) count against the receiver’s flow control
> window, even if it can infer that the data has been sent (by virtue of
> receiving a later offset).  Only upon receipt of a RST_STREAM do you account
> all outstanding data against the flow control window.
>
>
>
> Changing it so that all data up to the furthest offset received on a stream
> counts is certainly possible, but feels like an orthogonal change to this
> PR.  I’ve opened issue #370 for that.  In that world, the requirement would
> be to reliably deliver /either/ a RST_STREAM /or/ a STREAM frame with the FIN
> bit set (basically, you MUST communicate your final offset).  So long as one
> of those gets through, DISINTEREST by itself could stop retransmissions.
> That feels marginally more complicated, since it adds an additional path to
> stop retransmission on a stream and makes the accounting logic on receipt of
> a STREAM frame more complicated.
>
>
>
> My inclination is to leave retransmissions tied to having sent RST_STREAM,
> but I’ll defer to others whether the complexity is worth the potential savings.
>
>
>
> *From:*Lubashev, Igor [mailto:[email-masked]]
> *Sent:* Wednesday, March 8, 2017 9:19 AM
> *To:* Lubashev, Igor <[email-masked]>; Ian Swett <[email-masked]>;
> Martin Thomson <[email-masked]>
> *Cc:* Mike Bishop <[email-masked]>; [email-masked]
> *Subject:* RE: DISINTEREST frame
>
>
>
> P.S.
>
> So I read it that the peer who send DISINTEREST will /not/ be waiting for
> that data.  That peer does not need any accounting for flow control either,
> since he has already received the FIN (with the byte offset) and is already
> in “half-closed (remote)” or “closed” state.
>
>
>
>
>
> *From:*Lubashev, Igor [mailto:[email-masked]]
> *Sent:* Wednesday, March 08, 2017 12:10 PM
> *To:* Ian Swett <[email-masked] <mailto:[email-masked]>>; Martin
> Thomson <[email-masked] <mailto:[email-masked]>>
> *Cc:* [email-masked] <mailto:[email-masked]>;
> [email-masked] <mailto:[email-masked]>
> *Subject:* RE: DISINTEREST frame
>
>
>
>   * you definitely need "RST_STREAM is sent unless all outstanding data has
>     been sent AND acknowledged.", otherwise the peer waits forever for data
>     that won't arrive.
>
>
>
>
>
> I guess this is the core of the question, which goes beyond the choice for
> this rare condition. “It is reasonable to think that the peer who sent
> DISINTEREST is still waiting for any data?”  The whole point of DISINTEREST
> is to indicate that “I am /not/ waiting for any more data”.
>
>
>
>
>
> *From:*Ian Swett [mailto:[email-masked]]
> *Sent:* Wednesday, March 08, 2017 9:51 AM
> *To:* Martin Thomson <[email-masked] <mailto:[email-masked]>>
> *Cc:* Lubashev, Igor <[email-masked] <mailto:[email-masked]>>;
> [email-masked] <mailto:[email-masked]>;
> [email-masked] <mailto:[email-masked]>
> *Subject:* Re: DISINTEREST frame
>
>
>
> Question: Why call it DISINTEREST, instead of REQUEST_RST?  It wasn't obvious
> to me what DISINTEREST was until I read further, whereas REQUEST_RST is
> pretty obvious, assuming you know about RST_STREAM.
>
>
>
> On Tue, Mar 7, 2017 at 11:41 PM, Martin Thomson <[email-masked]
> <mailto:[email-masked]>> wrote:
>

---

From: Ian Swett <[email-masked]>
Date: Thu, 9 Mar 2017 07:48:38 -0500

On Thu, Mar 9, 2017 at 5:50 AM, Mirja Kühlewind <
[email-masked]> wrote:

> Okay, that's now a little bit a hack but after sending DISINTEREST you
> could just acknowledge all data up to the highest packet number you've
> seen, no matter if you received them or not because you don't need them
> anymore anynway; that would avoid any retransmissions...
>
>
That would 'work' if exactly one stream was active and there weren't any
important non-Stream frames you were inadvertently acking.  But most of the
time it will result in major state inconsistency, so I would never
recommend acking non-received packets in the QUIC transport doc.

>> obvious

---

From: Mike Bishop <[email-masked]>
Date: Thu, 9 Mar 2017 14:42:26 +0000

No, because those packets could have contained frames from other streams.  It would totally violate the semantics of ACK and likely break the connection.

Sent from my Windows 10 phone

From: Mirja Kühlewind<mailto:[email-masked]>
Sent: Thursday, March 9, 2017 2:50 AM
To: Mike Bishop<mailto:[email-masked]>; Lubashev, Igor<mailto:[email-masked]>
Cc: [email-masked]<mailto:[email-masked]>
Subject: Re: DISINTEREST frame

Mirja