Re: Splitting transport and application error code spaces

[Jana Iyengar <[e-mail]>]

I like the idea of moving STOP_SENDING to the application entirely. It's
basically an HTTP/2 thing anyway, so that seems like an excellent clean-up.

Mike: QUIC currently does not use RST_STREAM without the application asking
for it outside of responding to STOP_SENDING; do you think there are
conditions under which it may be useful for the transport to issue one?
STOP_SENDING was the only thing I could think of, but moving it up to HTTP
makes that moot.

On Mon, Aug 14, 2017 at 11:52 PM, Mike Bishop <[e-mail]>
wrote:

> I'm a little unhappy about that one.  I see the logic, but that would
> leave each direction of a stream solely in the hands of the sender and the
> receiver has no way to communicate (at the transport layer) if it wishes
> that stream to cease.  (Other, perhaps, than starving it via flow
> control.)  Though I agree, it is consistent with the principle that stream
> lifetime is entirely in the hands of the application.
>
> -----Original Message-----
> From: Martin Thomson [mailto:[e-mail]]
> Sent: Monday, August 14, 2017 5:49 PM
> To: Jana Iyengar <[e-mail]>
> Cc: Mike Bishop <[e-mail]>; QUIC WG <[e-mail]>
> Subject: Re: Splitting transport and application error code spaces
>
> On 15 August 2017 at 10:00, Jana Iyengar <[e-mail]> wrote:
> > I'm not sure exactly what this split buys us... and it changes
> > behavior on receiving STOP_SENDING.
>
> So, what the split buys us is certainty: an application is responsible for
> the lifetime of streams.  In return the application can be certain that the
> transport won't destroy any state that it puts on streams at a whim.  The
> split enforces this separation.
>
> This issue with STOP_SENDING is a good one.  I have a solution to that as
> well: move STOP_SENDING to HTTP.  If the required reaction (RST_STREAM), is
> an application-layer action, then we should make the trigger
> application-layer as well.
>