Subject: [Masque] Context reset rather than register ack Re: Spelling context registration

From: Lucas Pardue <[email-masked]>
Date: Fri, 16 Apr 2021 13:05:54 +0100

Hi Ben,

Thanks for writing down the CAPSULE design. I had one response, which you
suggested be in a different thread, so here goes.

On Fri, 16 Apr 2021, 02:01 Ben Schwartz, <bemasc=[email-masked]>
wrote:

>
> CAPSULE:DatagramContextRegistrationResult(varint id, bool success)*** -
> Indicate whether a registration succeeded.
>

<snip>

> *** I think we don't need this, and probably should not define it, but
> that's a topic for a different thread.
>

For the datagram use cases I can think of, they benefit from the Fast Open
model where I don't want to wait for a response (HTTP status or context
registration) before sending datagrams.

So I agree that I don't think we need DatagramContextRegistrationResult.
But what would be nice is to discriminate closing a context for sending vs
closing it for receiving. For example, after receiving an extended context
instance (to use your term from the interim) I could test it and find that
it fails due to deployment or operational conditions. At that stage I'd
like to tell you to give up on that context.

If IDs allocated are differently across client and server (even and odd),
we can simply use your CloseDatagramContext message because there is no
ambiguity what is being closed. If IDs are the same either side, it seems
ambiguous which context is being closed - we might need a
StopDatagramContext to tell the peer to stop using the context correlating
to *its* ID.

Cheers
Lucas

---

From: Ben Schwartz <[email-masked]>
Date: Fri, 16 Apr 2021 10:30:06 -0400

On Fri, Apr 16, 2021 at 8:06 AM Lucas Pardue <[email-masked]>
wrote:
...

> it fails due to deployment or operational conditions.
>

If that is possible, then I think we probably should have a result/ack.  My
claim is that we don't need this to be possible.  We can simply demand
that, after initial capability negotiation in the headers, well-formed
registrations always succeed.  I believe this greatly simplifies clients
and servers.

I've heard a few examples of where registration could fail.  One case was
an "invalid" (unroutable?) IP address in something like CONNECT-IP.  I
don't think this is a good motivating case, because the CONNECT-IP base
form (full IP packets) is fully capable of expressing any IP address, so
the error condition is related to the packet, not the registration.

Another case was QUIC connection ID collisions, for proxies that want to
multiplex QUIC users onto one 5-tuple.  This could be avoided in various
ways, e.g. requiring connection IDs to be globally unique, or providing a
server-controlled connection-ID in a response header.

At that stage I'd like to tell you to give up on that context.
> StopDatagramContext to tell the peer to stop using the context correlating

I was thinking about one-way contexts, which are registered, used, and
closed/freed only by the sender.  I was imagining a "Max-Contexts" header
exchanged by both parties, so both parties know when they need to release
old contexts before creating a new one.

---

From: Mirja Kuehlewind <[email-masked]>
Date: Fri, 16 Apr 2021 15:31:39 +0000

Top-level posting as I don’t even know where exactly to reply but this seems to get more and more complicated and it’s not entirely clear if we really need this. I think it would be much, much easier to restrict all context negotiation to the request setup time.

From: Masque <[email-masked]> on behalf of Ben Schwartz <bemasc=[email-masked]>
Date: Friday, 16. April 2021 at 16:30
To: Lucas Pardue <[email-masked]>
Cc: MASQUE <[email-masked]>
Subject: Re: [Masque] Context reset rather than register ack Re: Spelling context registration

On Fri, Apr 16, 2021 at 8:06 AM Lucas Pardue <[email-masked]<mailto:[email-masked]>> wrote:
...
For the datagram use cases I can think of, they benefit from the Fast Open model where I don't want to wait for a response (HTTP status or context registration) before sending datagrams.

So I agree that I don't think we need DatagramContextRegistrationResult. But what would be nice is to discriminate closing a context for sending vs closing it for receiving. For example, after receiving an extended context instance (to use your term from the interim) I could test it and find that it fails due to deployment or operational conditions.

If that is possible, then I think we probably should have a result/ack.  My claim is that we don't need this to be possible.  We can simply demand that, after initial capability negotiation in the headers, well-formed registrations always succeed.  I believe this greatly simplifies clients and servers.

I've heard a few examples of where registration could fail.  One case was an "invalid" (unroutable?) IP address in something like CONNECT-IP.  I don't think this is a good motivating case, because the CONNECT-IP base form (full IP packets) is fully capable of expressing any IP address, so the error condition is related to the packet, not the registration.

Another case was QUIC connection ID collisions, for proxies that want to multiplex QUIC users onto one 5-tuple.  This could be avoided in various ways, e.g. requiring connection IDs to be globally unique, or providing a server-controlled connection-ID in a response header.

If IDs allocated are differently across client and server (even and odd), we can simply use your CloseDatagramContext message because there is no ambiguity what is being closed. If IDs are the same either side, it seems ambiguous which context is being closed - we might need a StopDatagramContext to tell the peer to stop using the context correlating to *its* ID.

I was thinking about one-way contexts, which are registered, used, and closed/freed only by the sender.  I was imagining a "Max-Contexts" header exchanged by both parties, so both parties know when they need to release old contexts before creating a new one.

Cheers
Lucas

---

From: Alex Chernyakhovsky <[email-masked]>
Date: Fri, 16 Apr 2021 11:33:41 -0400

I do not see how restricting this to set up time removes any appreciable
complexity.

Sincerely,
-Alex

On Fri, Apr 16, 2021 at 11:31 AM Mirja Kuehlewind <mirja.kuehlewind=
[email-masked]> wrote:

> Top-level posting as I don’t even know where exactly to reply but this
> seems to get more and more complicated and it’s not entirely clear if we
> really need this. I think it would be much, much easier to restrict all
> context negotiation to the request setup time.
>
>
>
>
>
>
>
> *From: *Masque <[email-masked]> on behalf of Ben Schwartz
> <bemasc=[email-masked]>
> *Date: *Friday, 16. April 2021 at 16:30
> *To: *Lucas Pardue <[email-masked]>
> *Cc: *MASQUE <[email-masked]>
> *Subject: *Re: [Masque] Context reset rather than register ack Re:
> Spelling context registration
>
>
>
>
>
>
>
>
>
> If that is possible, then I think we probably should have a result/ack.
> My claim is that we don't need this to be possible.  We can simply demand
> --
> Masque mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/masque
>

---

From: Mirja Kuehlewind <[email-masked]>
Date: Fri, 16 Apr 2021 15:37:01 +0000

Because you don’t need to care about opening or closing. All contexts are valid for the whole life time of the forwarding session, and if the client request too many or not supported contexts you deny the whole request (with a meaningful error message).

From: Alex Chernyakhovsky <achernya=[email-masked]>
Date: Friday, 16. April 2021 at 17:34
To: Mirja Kuehlewind <[email-masked]>
Cc: Ben Schwartz <[email-masked]>, Lucas Pardue <[email-masked]>, MASQUE <[email-masked]>
Subject: Re: [Masque] Context reset rather than register ack Re: Spelling context registration

I do not see how restricting this to set up time removes any appreciable complexity.

Sincerely,
-Alex

On Fri, Apr 16, 2021 at 11:31 AM Mirja Kuehlewind <mirja.kuehlewind=[email-masked]<mailto:[email-masked]>> wrote:
Top-level posting as I don’t even know where exactly to reply but this seems to get more and more complicated and it’s not entirely clear if we really need this. I think it would be much, much easier to restrict all context negotiation to the request setup time.

From: Masque <[email-masked]<mailto:[email-masked]>> on behalf of Ben Schwartz <bemasc=[email-masked]<mailto:[email-masked]>>
Date: Friday, 16. April 2021 at 16:30
To: Lucas Pardue <[email-masked]<mailto:[email-masked]>>
Cc: MASQUE <[email-masked]<mailto:[email-masked]>>
Subject: Re: [Masque] Context reset rather than register ack Re: Spelling context registration

Cheers
Lucas
--
Masque mailing list
[email-masked]<mailto:[email-masked]>
https://www.ietf.org/mailman/listinfo/masque

---

From: Alex Chernyakhovsky <[email-masked]>
Date: Fri, 16 Apr 2021 11:55:13 -0400

That seems like a small part of the complexity -- the contexts still need
to be defined, identified, and transported. The capability of
opening/closing them mid-stream is pretty straightforward and we have prior
art in QUIC's streams anyway.

Sincerely,
-Alex

On Fri, Apr 16, 2021 at 11:37 AM Mirja Kuehlewind <mirja.kuehlewind=
[email-masked]> wrote:

> Because you don’t need to care about opening or closing. All contexts are
> valid for the whole life time of the forwarding session, and if the client
> request too many or not supported contexts you deny the whole request (with
> a meaningful error message).
>
>
>
>
>
> *From: *Alex Chernyakhovsky <achernya=[email-masked]>
> *Date: *Friday, 16. April 2021 at 17:34
> *To: *Mirja Kuehlewind <[email-masked]>
> *Cc: *Ben Schwartz <[email-masked]>, Lucas Pardue <
> [email-masked]>, MASQUE <[email-masked]>

---

From: Lucas Pardue <[email-masked]>
Date: Fri, 16 Apr 2021 17:29:45 +0100

Hey Ben,

On Fri, Apr 16, 2021 at 3:30 PM Ben Schwartz <bemasc=
[email-masked]> wrote:

>> For the datagram use cases I can think of, they benefit from the Fast
>> Open model where I don't want to wait for a response (HTTP status or
>> context registration) before sending datagrams.
>>

These are compelling points!

The main error case I can think of, that is generic, is a problem in the
DATAGRAM format. The simplest of which is to receive an HTTP/3 DATAGRAM
whose length is shorter than the format specified (shorter than mandatory
fields for an extension). This is a pretty critical error, so it should be
handled. Rather than reject an individual flow, we could tear down the
request stream or whole connection (as EKR suggested during the interim).
Stream errors can only carry an error code, that might be enough fidelity
but it might not be.

---

From: Mirja Kuehlewind <[email-masked]>
Date: Fri, 16 Apr 2021 18:37:19 +0000

That’s exactly my concern: of course we need to define and transport contexts but copying the full semantics of how we handle streams in QUIC seems a bit overengineered, at least for MASQUE (there might be other datagram use cases).

From: Alex Chernyakhovsky <achernya=[email-masked]>
Date: Friday, 16. April 2021 at 17:55
To: Mirja Kuehlewind <[email-masked]>
Cc: Alex Chernyakhovsky <[email-masked]>, Ben Schwartz <[email-masked]>, MASQUE <[email-masked]>, Lucas Pardue <[email-masked]>
Subject: Re: [Masque] Context reset rather than register ack Re: Spelling context registration

That seems like a small part of the complexity -- the contexts still need to be defined, identified, and transported. The capability of opening/closing them mid-stream is pretty straightforward and we have prior art in QUIC's streams anyway.

Sincerely,
-Alex

On Fri, Apr 16, 2021 at 11:37 AM Mirja Kuehlewind <mirja.kuehlewind=[email-masked]<mailto:[email-masked]>> wrote:
Because you don’t need to care about opening or closing. All contexts are valid for the whole life time of the forwarding session, and if the client request too many or not supported contexts you deny the whole request (with a meaningful error message).

From: Alex Chernyakhovsky <achernya=[email-masked]<mailto:[email-masked]>>
Date: Friday, 16. April 2021 at 17:34
To: Mirja Kuehlewind <[email-masked]<mailto:[email-masked]>>
Cc: Ben Schwartz <[email-masked]<mailto:[email-masked]>>, Lucas Pardue <[email-masked]<mailto:[email-masked]>>, MASQUE <[email-masked]<mailto:[email-masked]>>
Subject: Re: [Masque] Context reset rather than register ack Re: Spelling context registration

Sincerely,
-Alex

Cheers
Lucas

---

From: Lucas Pardue <[email-masked]>
Date: Fri, 16 Apr 2021 20:13:46 +0100

Hey,

On Fri, 16 Apr 2021, 19:37 Mirja Kuehlewind, <[email-masked]>
wrote:

> That’s exactly my concern: of course we need to define and transport
> contexts but copying the full semantics of how we handle streams in QUIC
> seems a bit overengineered, at least for MASQUE (there might be other
> datagram use cases).
>
We have done something akin to this this already with HTTP/3 server push,
which allows constraints on Push ID limits, cancelling pushed streams
before they are dispatched, etc.

We are taking a transport resource and subdividing it at the application
layer. I don't have an issue with designing a management later for that
resource. I agree though it should be motivated by real challenges, so
navigating the hypotheticals, and discounting them is useful to me at least.

Cheers
Lucas

---

From: Ian Swett <[email-masked]>
Date: Mon, 19 Apr 2021 13:41:03 -0400

On Fri, Apr 16, 2021 at 3:14 PM Lucas Pardue <[email-masked]>
wrote:

> Hey,
>
> On Fri, 16 Apr 2021, 19:37 Mirja Kuehlewind, <
> [email-masked]> wrote:
>

Push is different in at least one key way: The server is unsure if the
client has any use for the content until the push promise is sent.  In the
MASQUE use cases I'm aware of, the peer always wants the data being
received.  So for a given application, I think we should be able to
avoid needing to reject sub-flows.

---

From: Lucas Pardue <[email-masked]>
Date: Mon, 19 Apr 2021 18:52:21 +0100

> avoid needing to reject sub-flows.

True. But push is also the same as HTTP in one key way: The client can
reject the individual pushed response (STOP_SENDING) if it is invalid -
syntactically or semantically.

I'm not attempting to argue strongly in favor rejection but I'd like to get
our error handled principles of this new context resource agreed and
captured.

Cheers,
Lucas