Subject: [Masque] Charter tweaks

From: Martin Duke <[email-masked]>
Date: Wed, 22 Apr 2020 10:25:05 -0700

Hello MASQUE,

Chris and I added a tweak to the charter to at least consider the
congestion control implications of CONNECTU and IP proxying. The full
charter text is here:

https://github.com/chris-wood/ietf-masque/blob/master/proposed_charter.md

If everyone is reasonably happy with this text, we can move forward with
forming a WG.

Martin

---

From: David Schinazi <[email-masked]>
Date: Wed, 22 Apr 2020 15:33:08 -0700

This text sounds good to me.

David

On Wed, Apr 22, 2020 at 10:25 AM Martin Duke <[email-masked]>
wrote:

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

---

From: Spencer Dawkins at IETF <[email-masked]>
Date: Wed, 22 Apr 2020 19:54:27 -0500

Hi, Martin,

> If everyone is reasonably happy with this text, we can move forward with

This text looks significantly tighter than the original text MASQUE started
with, and I mean that as a compliment to everyone who contributed. Just for
completeness ...

Your e-mail was sent just a bit after I sent an e-mail in the "Consensus on
charter?" thread, at
https://mailarchive.ietf.org/arch/msg/masque/U-fNeWQLhmM6h2nC-6eNl52--K0/,
following up on a conversation between Christopher and Markus about
multipath (reproduced here for your convenience):

On Wed, Apr 22, 2020 at 5:15 AM <[email-masked]> wrote:

>
> > -----Original Message-----
> > From: Christopher Wood <[email-masked]>
>

deleted down to

>
> > I think MP-QUIC is out of scope given that it's not part of QUICv1.
> >
>
> OK. However, from my rough understanding there is nothing which really
> prevents Masque to be used in combination with MP when it becomes
> standardized. Do you share this assumption?
>

And my comment was

The language in the most current QUIC charter is still about "- Enabling
multipath and forward error correction extensions", isn't it?

So, my suggestion for MASQUE, would be to

   - include language like "enabling multipath" in the charter, to prevent
      MASQUE from having to recharter just because QUIC delivered MP-QUIC,
      - include multipath as a consideration for MASQUE, at least as a high
      level design consideration, and
      - trust the MASQUE chairs to manage what MASQUE works on, as we have
      done and continue to do in QUIC.

Adding language like that would also reduce the number of conversations
about "whether multipath is a requirement" as MASQUE does its work.

Do The Right Thing, of course. :-)

Best,

Spencer

---

From: "Martin Thomson" <[email-masked]>
Date: Thu, 23 Apr 2020 11:01:58 +1000

Unwrapping Martin's gift:

> The working group will consider the implications of tunneling congestion-controlled protocols over QUIC and may issue recommendations accordingly. New congestion control algorithms are out of scope.

This says QUIC.  Did you mean HTTP/3?  Because David's proposal for CONNECT-UDP uses STREAM rather than DATAGRAM, which means that you have loss recovery interactions that are more likely to mess with your congestion controller than just having a separate limit on what can be sent.

On Thu, Apr 23, 2020, at 08:33, David Schinazi wrote:
> On Wed, Apr 22, 2020 at 10:25 AM Martin Duke <[email-masked]> wrote:
> > Hello MASQUE,
> > 
> > Chris and I added a tweak to the charter to at least consider the congestion control implications of CONNECTU and IP proxying. The full charter text is here:
> > 
> > If everyone is reasonably happy with this text, we can move forward with forming a WG.
> > 
> > Martin
> >  -- 
> >  Masque mailing list
> > [email-masked]

---

From: Lucas Pardue <[email-masked]>
Date: Thu, 23 Apr 2020 02:11:41 +0100

On Thu, 23 Apr 2020, 02:02 Martin Thomson, <[email-masked]> wrote:

> > The working group will consider the implications of tunneling
> congestion-controlled protocols over QUIC and may issue recommendations
> accordingly. New congestion control algorithms are out of scope.
>
> This says QUIC.  Did you mean HTTP/3?  Because David's proposal for
> CONNECT-UDP uses STREAM rather than DATAGRAM, which means that you have
> loss recovery interactions that are more likely to mess with your
> congestion controller than just having a separate limit on what can be sent.
>

The way I read CONNECT-UDP was that it uses the streams to carry requests
that bootstrap the DATAGRAM flow (control plane). QUIC packets to the
target server are then exchanged in DATAGRAMS (data plane).

Lucas

---

From: Martin Duke <[email-masked]>
Date: Wed, 22 Apr 2020 18:39:45 -0700

Replies, as the chairs and I continue to tighten the charter:

Spencer: thanks for helping crack the whip on consensus. I like the idea of
adding text on high-level design considerations but may have to workshop
the language some.

Martin/Lucas: I share Lucas's perception of this work, that we don't have
to worry about nested loss recovery. It is very possible I have missed
something. As for saying HTTP/3 instead of QUIC, IMO QUIC is the one with
the congestion control, but these are basically synonyms in that sentence.
I don't feel strongly about it.

All: I trust that everyone will be relieved that we will rule multicast to
be out of scope.

If no one is going to lie down in the road over any of these developments,
I hope to wrap this up in less than a week and run this charter through the
IESG for a tsvarea working group.

On Wed, Apr 22, 2020, 18:12 Lucas Pardue <[email-masked]> wrote:

>> accordingly.. New congestion control algorithms are out of scope.
>>

---

From: Spencer Dawkins at IETF <[email-masked]>
Date: Wed, 22 Apr 2020 20:41:11 -0500

FWIW,

> target server are then exchanged in DATAGRAMS (data plane).

I read this the same way Lucas did, but I was guessing, so perhaps this
could be clearer. Is the issue that we think the WG should make decisions
about details at this level?

Best,

Spencer

---

From: Martin Duke <[email-masked]>
Date: Wed, 22 Apr 2020 18:47:32 -0700

The issue is that if UDP or IP are delivered over reliable streams, there
are two layers of loss recovery that will do undesirable things. I'm
assuming the WG will not go that route, and so it doesn't have to worry
about loss recovery.

On Wed, Apr 22, 2020, 18:41 Spencer Dawkins at IETF <
[email-masked]> wrote:

>>> accordingly... New congestion control algorithms are out of scope.
>>>

---

From: "Martin Thomson" <[email-masked]>
Date: Thu, 23 Apr 2020 17:46:54 +1000

On Thu, Apr 23, 2020, at 11:47, Martin Duke wrote:
> The issue is that if UDP or IP are delivered over reliable streams, 
> there are two layers of loss recovery that will do undesirable things. 
> I'm assuming the WG will not go that route, and so it doesn't have to 
> worry about loss recovery.

The designs floated so far have a fallback to TCP, just like most QUIC deployments do, so I wouldn't rely on that.

---

From: Mirja Kuehlewind <[email-masked]>
Date: Thu, 23 Apr 2020 08:51:04 +0000

Also there are use cases where local loss recovery is desired and works well. The precondition is that the latency of the local segment is much smaller than the latency of the end-to-end link. We even have some test results that show these improvements. So I think the wg should consider that and as Martin said probably even has to considered it as in some cases it might not be avoidable.

Mirja

On 23.04.20, 09:47, "Masque on behalf of Martin Thomson" <[email-masked] on behalf of [email-masked]> wrote:

---

From: Spencer Dawkins at IETF <[email-masked]>
Date: Thu, 23 Apr 2020 07:59:06 -0500

Just to continue agreeing with Martin and Mirja :-)

On Thu, Apr 23, 2020 at 3:51 AM Mirja Kuehlewind <mirja.kuehlewind=
[email-masked]> wrote:

> Also there are use cases where local loss recovery is desired and works
> well. The precondition is that the latency of the local segment is much
> smaller than the latency of the end-to-end link. We even have some test
> results that show these improvements. So I think the wg should consider
> that and as Martin said probably even has to considered it as in some cases
> it might not be avoidable.
>
> Mirja
>
>
>
> On 23.04.20, 09:47, "Masque on behalf of Martin Thomson" <
> [email-masked] on behalf of [email-masked]> wrote:
>
>     The designs floated so far have a fallback to TCP, just like most QUIC
> deployments do, so I wouldn't rely on that.
>

So, Some Guy Named Tommy Pauly gave a thought-provoking presentation on TCP
encapsulation for IKEv2 in TSVAREA at IETF 101 (slides at
https://datatracker.ietf.org/meeting/101/materials/slides-101-tsvarea-tcp-encapsulation-experience-and-experiments-with-ike-over-tcp-tommy-pauly-00.pdf),
and he raised the concern about nested loss recovery during his talk, and
we chatted about that lot (multiple pages in the minutes both during the
presentation and during Q&A, minutes at
https://datatracker.ietf.org/meeting/101/materials/minutes-101-tsvarea-00.pdf
).

It's worth rereading the entire discussion in the minutes, because people
said a lot of things that other people didn't know, but my last statement
in the minutes was:

"Spencer as individual: I really appreciate the insight that running
reliable transport protocols independently at multiple layers of the stack
probably isn't as bad an idea now as it was when people were running TCP
without Fast Retransmit over x.25. And since QUIC has state-of-the-art
congestion recovery behavior and runs over UDP, I'm waiting for the day
when someone tries to run QUIC over UDP in a TCP encapsulated tunnel and
seeing how that that will work. (Tommy whimpers quietly into the
microphone, and then gathers his strength to continue)"

Mirja's last statement in the minutes was

'Mirja thanked the room for not freaking out when we put "TCP
Encapsulation" on the agenda.'

So, recognizing that IKEv2 over TCP isn't the only possible nested retry
mechanism (not even close), but that we're still talking about TCP as a
fallback for QUIC, so we're still talking about nested loss recovery, I
think that the topic of nested loss recovery is going to be important for
MASQUE, but I'm guessing that "more investigation will be required", but I
would be fine deferring the "nested loss recovery" investigation until
after the working group is formed, unless there's a better place in an
existing IETF working group to have that conversation.

IMO, of course.

Best,

Spencer

---

From: "Christopher Wood" <[email-masked]>
Date: Sat, 25 Apr 2020 13:16:00 -0700

Thanks for raising these points, all! We adjusted the charter to take them into account. In particular, we added the following paragraph:

"The working group will consider the implications of tunneling protocols with congestion control and loss recovery over MASQUE, and may issue recommendations accordingly. New congestion control and loss recovery algorithms are out of scope."

As before, the full charter text can be found here:

Best,
Chris

On Thu, Apr 23, 2020, at 5:59 AM, Spencer Dawkins at IETF wrote:
> On Thu, Apr 23, 2020 at 3:51 AM Mirja Kuehlewind 
> <mirja.kuehlewind=[email-masked]> wrote:
> So, Some Guy Named Tommy Pauly gave a thought-provoking presentation on 
> TCP encapsulation for IKEv2 in TSVAREA at IETF 101 (slides at 
> https://datatracker.ietf.org/meeting/101/materials/slides-101-tsvarea-tcp-encapsulation-experience-and-experiments-with-ike-over-tcp-tommy-pauly-00.pdf), and he raised the concern about nested loss recovery during his talk, and we chatted about that lot (multiple pages in the minutes both during the presentation and during Q&A, minutes at https://datatracker.ietf.org/meeting/101/materials/minutes-101-tsvarea-00.pdf). 
> 
> It's worth rereading the entire discussion in the minutes, because 
> people said a lot of things that other people didn't know, but my last 
> statement in the minutes was: 
> 
> > "Spencer as individual: I really appreciate the insight that running reliable transport protocols independently at multiple layers of the stack probably isn't as bad an idea now as it was when people were running TCP without Fast Retransmit over x.25. And since QUIC has state-of-the-art congestion recovery behavior and runs over UDP, I'm waiting for the day when someone tries to run QUIC over UDP in a TCP encapsulated tunnel and seeing how that that will work. (Tommy whimpers quietly into the microphone, and then gathers his strength to continue)"
> 
> > 'Mirja thanked the room for not freaking out when we put "TCP Encapsulation" on the agenda.'
> 
> So, recognizing that IKEv2 over TCP isn't the only possible nested 
> retry mechanism (not even close), but that we're still talking about 
> TCP as a fallback for QUIC, so we're still talking about nested loss 
> recovery, I think that the topic of nested loss recovery is going to be 
> important for MASQUE, but I'm guessing that "more investigation will be 
> required", but I would be fine deferring the "nested loss recovery" 
> investigation until after the working group is formed, unless there's a 
> better place in an existing IETF working group to have that 
> conversation. 
> 
> IMO, of course. 
> 
> Best,
> 
> Spencer
> -- 
> Masque mailing list
> [email-masked]

---

From: Martin Duke <[email-masked]>
Date: Wed, 29 Apr 2020 10:35:43 -0700

MASQUE,

Please consider this the last call on the list for the charter. I am
planning to ship it to IESG at the end of the week.

On Sat, Apr 25, 2020 at 1:16 PM Christopher Wood <[email-masked]>
wrote:

> Thanks for raising these points, all! We adjusted the charter to take them
> into account. In particular, we added the following paragraph:
>
> "The working group will consider the implications of tunneling protocols
> with congestion control and loss recovery over MASQUE, and may issue
> recommendations accordingly. New congestion control and loss recovery
> algorithms are out of scope."
>
> > > Also there are use cases where local loss recovery is desired and
> works well. The precondition is that the latency of the local segment is
> much smaller than the latency of the end-to-end link. We even have some
> test results that show these improvements. So I think the wg should
> consider that and as Martin said probably even has to considered it as in
> some cases it might not be avoidable.
> > >
> > >  Mirja
> > >
> > >
> > >
> > >  The designs floated so far have a fallback to TCP, just like most
> QUIC deployments do, so I wouldn't rely on that.
> >
> https://datatracker.ietf.org/meeting/101/materials/minutes-101-tsvarea-00.pdf).
>
> >