Re: Splitting transport and application error code spaces

[Mirja Kühlewind <[e-mail]>]

That’s what the applicability draft should capture. If you have concrete things that need to be mentioned somewhere, you can file an issue there. However, as the base specs are still changing quite a bit, it’s a bit hard for me to track all things now…


> Am 16.08.2017 um 09:32 schrieb 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.