Re: Split error codes in two

[Martin Thomson <[e-mail]>]

We've drifted dangerously close to defining an API.

You are suggesting an upcall that says "I've received a WRITE_ABORT on
stream X.  (optionally: I've stopped sending stream X.)  Should I (a)
reset, or (b) continue?"

Alternatively, you could configure the answer on streams with
defaults, or when you start writing.

That's a pretty well-defined notion in the abstract, but if we had a
transport-layer message, every generic QUIC stack would need to have
one or other mechanism.

On Tue, Sep 26, 2017 at 9:10 AM, Lubashev, Igor <[e-mail]> wrote:
> I agree that in many cases, "streams-as-messages" model fits well in the application use case (not HTTP Stream 1, though).  It seems reasonable to suppose that an application would occasionally like to send a very large (100MB?) message, and it gives it to the transport in one shot -- maybe using something like Linux sendfile() API call.
>
> So now to your question:
>>   -> what is the transport going to **do** with a STOP_SENDING?
>
> The answer seems orthogonal to bidirectionality.  It would make sense for the transport to stop sending the message and notify the application that it did so.  The alternative is to continue sending the large file, spending significant network and CPU resources doing so, and hoping the application would be prompt at receiving the notification and asking the transport to cancel the transfer.  Both alternatives achieve the same semantics: "an app is notified that that the receiver refused to receive this message in its entirety".  The former option allows saving network and systems resources on the protocol level.
>
> In the "pipe" model (unidirectional or bidirectional), this is a question of whether only the sender is allowed to close the pipe, or the receiver is also allowed to close.
>
>
> -----Original Message-----
> From: Martin Thomson [mailto:[e-mail]]
> Sent: Monday, September 25, 2017 12:03 AM
> To: Roberto Peon <[e-mail]>
> Cc: [e-mail]; Christian Huitema <[e-mail]>
> Subject: Re: Split error codes in two
>
> On Thu, Sep 14, 2017 at 12:40 AM, Lubashev, Igor <[e-mail]> wrote:
>> Thinking about this a bit more, it seems that the key difference
>> between “tcp socket” and “two pipe pairs” models is independence of
>> the send and receive directions.
>
> I prefer Christian's analogy of streams as messages.  That's what motivated the design that I proposed.  Then you don't get "pipe pairs"
> you get "messages and (optionally) response messages".
>
> On Thu, Sep 14, 2017 at 5:03 AM, Roberto Peon <[e-mail]> wrote:
>> So many RPC models have failed utterly because they couldn’t handle
>> receiving the data in a streaming fashion.
>
> That doesn't invalidate the streams-are-messages model, it just recognizes that the messages cannot be sent and received as a single unit (unless they are 0 length, I guess).  Flow control, multiplexing, etc, etc...
>
> ~
>
> I want to come back to the original question in light of what we learned:
>
>  -> what is the transport going to **do** with a STOP_SENDING?
>
> I can't think of anything other than to tell the application.  That makes the answer pretty clear to me.
>
> I don't think that this discussion - valuable as it is been - has changed my position on this much.  Ideally I would like to enable all the various viewpoints on the question to be equally valid.  Building a protocol that can provide something that looks like a TCP socket is challenging though, because the complete close of a coupled pair cannot be done generically - I think that we all agree that this is impossible in the general case.
>
> I can appreciate the desire to build some of the pieces that might be needed to build a bidirectional close, but I think that is more dangerous than useful and would prefer to leave this to application protocols.
>