Stream correlation in Transport

[MikeBishop]

This is an augmentation of @martinthomson's PR to add stream correlation, as promised.

Major changes

Leveraging @igorlord's insight that OO=00 only occurs on the first STREAM frame of a stream, I used that as the trigger for a Stream Properties byte. Two bits of that byte describe the directionality of the stream:

• Unidirectional (no response expected)
• Initial bidirectional (one response expected)
• Initial multi-response (one or more responses expected; needs a better name)
• Response

If the type is Response, there's an Associated Stream ID field, length given by two more bits following the same pattern as the SS bits in the STREAM frame ID.

Personal Opinion

On the plus side, these stream types seem to cover the abstractions I can envision for most applications. You can unilaterally send something (unidirectional), do request/response (bidirectional), or pub/sub (single subscription stream, series of update streams).

I don't care for the fact that I still need the stream type header in HTTP after putting this in the transport. That will be ameliorated if we go back to one stream per request, since all unidirectional streams will be push streams. (As a side-note, I considered using the multiple-response option in the HTTP mapping, but then I need a stream header again to indicate which is the response and which the pushes.)

I particularly don't like that you now have to look at the frame type header to find out whether a field exists which tells you the length of something else in the header. I'd like to simplify that. I went with this model over a CREATE_STREAM frame because of @mikkelfj's use-case of very small messages -- this adds only one byte to the first frame on a stream in one direction and 2-5 bytes to the first frame of response streams. A separate frame type would be somewhat larger, but could be cleaner in that respect.

[mikkelfj]

I have so far only looked at transport.md - I think the exact encoding is not too important for now - notably var length integers might replace bits in the type byte.

One thought is that it might not be desirable to check for association errors because the initial stream might be closed and gone before a response arrives. Checking validity would require state to be retained - in principle indefinitely. But the association type may still be useful to an API layer.

[MikeBishop]

Good point. Most things fall quickly into the bucket of “associating to these is not valid” – all unidirectional streams, response streams, and bidirectional streams that have seen a response are the same. But every pub/sub stream remains valid forever, as does a bidirectional stream that never gets answered. There are some possible memory attacks there we’d need to iron out if we went this way. From: MikkelFJ [mailto:notifications@github.com] Sent: Wednesday, June 28, 2017 4:10 PM To: quicwg/base-drafts <base-drafts@noreply.github.com> Cc: Mike Bishop <Michael.Bishop@microsoft.com>; Author <author@noreply.github.com> Subject: Re: [quicwg/base-drafts] Stream correlation in Transport (#672) I have so far only looked at transport.md - I think the exact encoding is not too important for now - notably var length integers might replace bits in the type byte. One thought is that it might not be desirable to check for association errors because the initial stream might be closed and gone before a response arrives. Checking validity would require state to be retained - in principle indefinitely. But the association type may still be useful to and API layer. — You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub<https://na01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Fquicwg%2Fbase-drafts%2Fpull%2F672%23issuecomment-311817033&data=02%7C01%7CMichael.Bishop%40microsoft.com%7Cf33c31e5652d4d04e59b08d4be7ac60f%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C636342881899061982&sdata=ZllkXdSDwGP7V8GLwBoLvFousQKYgRxOzb8G73zkJQo%3D&reserved=0>, or mute the thread<https://na01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Fnotifications%2Funsubscribe-auth%2FAEE2haeX7CVj98vhhchOYqzJb1J7qq1tks5sIt05gaJpZM4OIm8f&data=02%7C01%7CMichael.Bishop%40microsoft.com%7Cf33c31e5652d4d04e59b08d4be7ac60f%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C636342881899061982&sdata=b%2FJhB8vT5XBHIZjK6X8MXEV6X6STZ6e7cvcI40hVXcY%3D&reserved=0>.

[martinthomson]

@MikeBishop, do you think that #720 might be better and we could close this?

[MikeBishop]

Closed in favor of #720.