Subject: [quicwg/base-drafts] only require RESET_STREAM on STOP_SENDING in Ready and Sent state (#2268)

From: Marten Seemann <[email-masked]>
Date: Fri, 28 Dec 2018 03:53:13 -0800

When all data has already been sent on a stream, we allow two responses to receiving a STOP_SENDING:
> If the STOP_SENDING frame is received on a stream that is already in the “Data Sent” state, an endpoint that wishes to cease retransmission of previously-sent STREAM frames on that stream MUST first send a RESET_STREAM frame.

The two options:
1. reliably deliver all STREAM frames
2. cease retransmission of STREAM frames, and send a RESET_STREAM instead

In case 1., it's not necessary to send a RESET_STREAM frame, since the peer will learn about the final offset of the stream from the STREAM frame with the FIN bit.
You can view, comment on, or merge this pull request online at:

  https://github.com/quicwg/base-drafts/pull/2268

-- Commit Summary --

  * only require RESET_STREAM on STOP_SENDING in Ready and Sent state

-- File Changes --

    M draft-ietf-quic-transport.md (8)

-- Patch Links --

https://github.com/quicwg/base-drafts/pull/2268.patch
https://github.com/quicwg/base-drafts/pull/2268.diff

-- 
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
https://github.com/quicwg/base-drafts/pull/2268

---

From: Martin Thomson <[email-masked]>
Date: Sun, 30 Dec 2018 18:26:41 -0800

martinthomson requested changes on this pull request.

I think that this needs to include Data Sent also.  Though the end of stream might be in flight, you have no assurance that it was received (yet).  You could say that the endpoint MAY defer sending the RESET_STREAM until any outstanding data on the stream is declared lost.

The text you quote can be struck.  The race here we were trying to service isn't really one we need to deal with - we mandate the use of STOP_SENDING in response to RESET_STREAM.

-- 
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
https://github.com/quicwg/base-drafts/pull/2268#pullrequestreview-188457150

---

From: Marten Seemann <[email-masked]>
Date: Sun, 30 Dec 2018 18:46:30 -0800

I don’t think this is necessary. An endpoint that has finished sending can also just make sure that the Fin is reliably delivered. What’s required for the protocol to work is that the final offset is delivered, either with a Fin or with a RESET.

-- 
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
https://github.com/quicwg/base-drafts/pull/2268#issuecomment-450602940

---

From: Martin Thomson <[email-masked]>
Date: Sun, 30 Dec 2018 18:57:36 -0800

I could go as far as "MAY defer action and send either a RESET_STREAM or all remaining stream data until unacknowledged data is declared lost."  I think that allows for what you say.

-- 
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
https://github.com/quicwg/base-drafts/pull/2268#issuecomment-450603427

---

From: Kazuho Oku <[email-masked]>
Date: Mon, 31 Dec 2018 22:42:07 -0800

@martinthomson 
> I could go as far as "MAY defer action and send either a RESET_STREAM or all remaining stream data until unacknowledged data is declared lost." I think that allows for what you say.

I think that we need to at least state that.

Our consensus is that endpoints can simply retransmit the entire payload of a lost packet (see #1612, #2082). That means that theoretically, an endpoint can receive an awfully outdated STOP_SENDING frame. However, we do not want endpoints to perpetually remember the final offsets of all the streams it has ever used. Therefore, we need to allow an endpoint to ignore STOP_SENDING when it knows that the peer has already seen either a RESET_STREAM or a FIN for the stream the STOP_SENDING frame designates.

-- 
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
https://github.com/quicwg/base-drafts/pull/2268#issuecomment-450712796