Re: Splitting transport and application error code spaces

[Mikkel Fahnøe Jørgensen <[e-mail]>]

If STOP_SENDING is moved a basic application will no longer have a language
to communicate intent.
This is perhaps a broader issue - but the question is: what are the minimum
primitives a basic application with no advanced higher level protocol needs
in order to move data on multiple streams? It relates to adding bidi
streams on top of uni streams.

I’m not sure if STOP_SENDING is important in this context, or not, but I
believe it is a worthwhile question.

Kind Regards,
Mikkel Fahnøe Jørgensen


On 16 August 2017 at 01.57.11, Jana Iyengar ([e-mail]) wrote:

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.
>