RE: Split error codes in two

["Lubashev, Igor" <[e-mail]>]

Whether STOP_SENDING is in transport is a matter of picking the guiding principle for what one would consider putting in transport vs application.  Some of the alternatives for the "guiding principle" are:
* "Is likely to be used by many apps?"
* "Will it likely perform better in transport?"
 * "Is it a 'cleaner' design due to all sorts of symmetries?"

I think that STOP_SENDING "may perform better in transport" due to the rule of thumb that "stop" signals should take priority over "ordinary" data.  I.e. having it as a part of an application protocol has a risk that STOP_SENDING would be blocked by flow control, HOL blocking, transport/app interface, etc.  The "symmetry" argument, however, does put STOP_SENDING in the application, since RST_STREAM is never initiated by transport otherwise.  And I have little intuition as far as "use by many apps" is concerned.
 

-----Original Message-----
From: Mike Bishop [mailto:[e-mail]] 
Sent: Wednesday, September 06, 2017 1:55 PM
To: Philipp S. Tiesel <[e-mail]>; Jana Iyengar <[e-mail]>
Cc: Victor Vasiliev <[e-mail]>; QUIC WG <[e-mail]>; Martin Thomson <[e-mail]>; Nick Harper <[e-mail]>
Subject: RE: Split error codes in two

What transport-level single-stream errors are there which shouldn't kill the connection?  The only ones I can think of are flow control violations and max-stream-ID violations.  Perhaps "frame for stream in wrong state," though you have to be somewhat gracious about that one given reordering.  I think I'm okay with making those fatal.

I'm less convinced that STOP_SENDING is HTTP-specific.  To my mind, it's the wire expression of a read_close(), just as RST_STREAM is the wire expression of a write_close().  If we'd gone the advisory route, it would be an HTTP-ism.  (Or at least, the mandated behavior would be at the HTTP layer.)  However, if we think other applications aren't ever going to want to close a read stream....

-----Original Message-----
From: QUIC [mailto:[e-mail]] On Behalf Of Philipp S. Tiesel
Sent: Wednesday, September 6, 2017 2:16 AM
To: Jana Iyengar <[e-mail]>
Cc: Victor Vasiliev <[e-mail]>; QUIC WG <[e-mail]>; Martin Thomson <[e-mail]>; Nick Harper <[e-mail]>
Subject: Re: Split error codes in two


> On 6. Sep 2017, at 03:12, Jana Iyengar <[e-mail]> wrote:
> On Tue, Sep 5, 2017 at 6:10 PM, Martin Thomson <[e-mail]> wrote:
> On Wed, Sep 6, 2017 at 10:59 AM, Jana Iyengar <[e-mail]> wrote:
>>> In the current draft, we've already changed that requirement: the 
>>> application is expected to generate a RST_STREAM in response to a 
>>> received RST_STREAM.
>>> 
>> That text was removed with the addition of STOP_SENDING.  (Or at 
>> least I couldn't find it).  I think that's the right answer, because 
>> this will be entirely discretionary on the part of applications.
>> 
> Yup, I was just pointing out the reasons that we don't need RST_STREAM to be a transport directive.

RST_STREAM is also referenced in the "Stream Errors” section and still makes sense for transport errors only effecting a single stream

Removing RST_STREAM also means making all errors effecting just a single stream connection errors leading to teardown of the whole connection.

AVE!
  Philipp S. Tiesel / phils…