Subject: [quicwg/base-drafts] More detailed stream states (#894)

From: Martin Thomson <[email-masked]>
Date: Fri, 20 Oct 2017 08:56:55 +0000 (UTC)

This takes the state machines that @MikeBishop showed at the Seattle interim
and turns them into text and ASCII art.

I made a few changes in the process.  The state where all data is available
didn't turn out to be any different to the state preceding it, so I removed it.
I also found it valuable to recognize that streams might be created for sending
before any frames are sent (I considered doing the same for receive streams,
but it complicated the transitions more than I liked, I could be convinced to
add this still, it just seems less valuable).

I added a section on composite states, showing how this mess all maps to stuff
you already know (h2).

This is still work-in-progress.  I have changed the main chunk of text on
states, but I haven't changed any of the rest of the document, which still
talks about "idle" and all that.  I'll do that next if people are generally
happy with the direction this is headed.

There are probably a few minor regressions here.  In particular, I need to look at
what retransmissions can be received after they are no longer needed.  But it's
late enough already.

(Note, this is currently based on master, but this assumes the bidi/uni proposal from @RyanAtGoogle or myself is taken in some form.  I'll rebase once that settles.)
You can view, comment on, or merge this pull request online at:

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

-- Commit Summary --

  * More detailed stream states

-- File Changes --

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

-- Patch Links --

https://github.com/quicwg/base-drafts/pull/894.patch
https://github.com/quicwg/base-drafts/pull/894.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/894

---

From: MikkelFJ <[email-masked]>
Date: Fri, 20 Oct 2017 10:31:12 +0000 (UTC)

Just a quick note from a glance: It woud be useful to have a clear overview of which frames can be sent from which states. In its current form self transitions are not included. It could be in a separate transition table to reduce clutter.

-- 
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/894#issuecomment-338169934

---

From: Martin Thomson <[email-masked]>
Date: Sun, 22 Oct 2017 20:54:35 -0700

@martinthomson pushed 3 commits.

651cb09  Summarize what can be sent and when
d87ad0c  The stream mapping is just a possibility
9d1426f  Don't overdo it

-- 
You are receiving this because you are subscribed to this thread.
View it on GitHub:
https://github.com/quicwg/base-drafts/pull/894/files/63e844327bfc3deaa10cf9f353eb2a2ee7b30683..9d1426f5ec7cfc592755cbc9a60e740e6f2fde1c

---

From: Martin Thomson <[email-masked]>
Date: Thu, 26 Oct 2017 00:09:46 +0000 (UTC)

@martinthomson pushed 1 commit.

8d3e67b  Complete the changes

-- 
You are receiving this because you are subscribed to this thread.
View it on GitHub:
https://github.com/quicwg/base-drafts/pull/894/files/9d1426f5ec7cfc592755cbc9a60e740e6f2fde1c..8d3e67bb62824dddaa24dea5ac5da1b59d2e6d12

---

From: Martin Thomson <[email-masked]>
Date: Thu, 26 Oct 2017 00:10:44 +0000 (UTC)

This is now essentially complete - at least in my view.  I've checked that I didn't miss anything from the original state machine and that the remainder of the document (and documents) don't refer to the old stream states.

-- 
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/894#issuecomment-339511195

---

From: MikkelFJ <[email-masked]>
Date: Wed, 25 Oct 2017 17:35:26 -0700

mikkelfj commented on this pull request.

-While STOP_SENDING frames are retransmittable, an implementation MAY choose not
-to retransmit a lost STOP_SENDING frame if the stream has already been closed
-in the appropriate direction since the frame was first generated.
-See {{packetization}}.
+STOP_SENDING can only be sent for a receive stream that has not been
+reset. STOP_SENDING is most useful for streams in the "Recv" or "Size Known"
+states.
+
+An endpoint is expected to send STOP_SENDING frames if packets containing the
+frame are lost.  However, once either all stream data has been received or a
+RST_STREAM frame - that is, any receive stream state other than "Recv" or "Size
+Known" - sending the frame is not necessary.

Can this be formulated more clearly? I think the paragraph is discussing retransmission while avoiding using the loaded term. E.g. what does "the frame is lost" mean? Which frame is lost? Does it mean something like: A STOP_SENDING frame should be retransmitted in case of packet loss until acknowledged or a FIN or RST_STREAM signal has been received.

-- 
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/894#pullrequestreview-72052579

---

From: Martin Thomson <[email-masked]>
Date: Thu, 26 Oct 2017 05:38:42 +0000 (UTC)

375b0d5  Forgot about MAX_STREAM_DATA

-- 
You are receiving this because you are subscribed to this thread.
View it on GitHub:
https://github.com/quicwg/base-drafts/pull/894/files/8d3e67bb62824dddaa24dea5ac5da1b59d2e6d12..375b0d54eed0204713a8a113887231b8ab6e2ce1