Subject: Re: [Masque] Charter tweaks

From: Mark Nottingham <[email-masked]>
Date: Fri, 1 May 2020 18:19:16 +1000

Hey Martin et al,

I just caught up with the threads over the last few weeks; sorry for coming in at the last minute, I got distracted.

Overall I like and agree with where this landed. A few observations, FWIW:

* '... develop mechanisms that allow configuring and concurrently running multiple proxied stream- and datagram-based flows ...' -> is 'stream- and' still relevant?

* 'The group will specify HTTP or HTTP/3 extensions' -> It's important that we understand the differences between these. HTTP extensions are methods, headers, status codes and the like; HTTP/3 extensions are frame types, options and the like. What's being attempted here appears to be defining a HTTP extension (or more) to negotiate use of one or more HTTP/3 extensions. The problem we're going to face is that HTTP extensions are supposed to be version-independent; CONNECT and Upgrade have caused a fair amount of pain because they're not, and we're talking about extending that pattern. Not a showstopper, but we need to be thoughtful.

* 'client-initiated services' -> I'd feel much better if the converse were explicitly ruled out, to make it crystal clear.

* 'IP proxying' -> This is my only substantive concern; I strongly suspect that shoving the desired semantics into HTTP is going to distort both the protocol and the use case beyond recognition. It's one thing to have a single (!) gigacorp do it in a self-to-self integration for a specific purpose; that doesn't give us any information about whether it's useful or good to standardise it. Can we PLEASE drop this from the charter until we at least see a straw-man of how it might operate?

* Regarding venue - I don't have strong feelings about this, as long as the HTTP semantics involved are discussed early and often with the *whole* HTTP WG (which means showing up and giving a summary of progress / taking feedback at regular intervals; unlike QUIC, this is defining HTTP semantics). FWIW we do have some capacity opening up there, and I think there would be willingness to take the UDP part on, at least.
 
Cheers,

> On 30 Apr 2020, at 3:35 am, Martin Duke <[email-masked]> wrote:
> 
> 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."
> 
> As before, the full charter text can be found here:
> 
>    https://github..com/chris-wood/ietf-masque/blob/master/proposed_charter.md

                   ^ Hey look - IETF mailing lists are still editing our message content.

> 
> Best,
> Chris
> 
> On Thu, Apr 23, 2020, at 5:59 AM, Spencer Dawkins at IETF wrote:
> > 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:
> > > 
> > >  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.
> > 
> > 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
> > -- 
> > Masque mailing list
> > [email-masked]
> > https://www.ietf.org/mailman/listinfo/masque
> >
> 
> -- 
> Masque mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/masque
> -- 
> Masque mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/masque

--
Mark Nottingham   https://www.mnot.net/

---

From: Martin Duke <[email-masked]>
Date: Fri, 1 May 2020 10:45:29 -0700

Hi Mark--

Thank you very much for the comments. We will certainly look at
incorporating your minor concerns into the charter.

As for IP proxying: although I gather that you believe that this is not
worth pursuing, I gather that there is a strong cohort in the community
that disagrees. Whether or not it's in the charter, if there are specific
problems that arise that make IP proxying unworkable,  there are numerous
veto points that can block the work from moving further in the WG.

That said, I would like to adjust the charter language to ease your
concerns, if possible. Is there something that would do that short of
striking it entirely?

On Fri, May 1, 2020 at 1:19 AM Mark Nottingham <[email-masked]> wrote:

> Hey Martin et al,
>
> I just caught up with the threads over the last few weeks; sorry for
> coming in at the last minute, I got distracted.
>
> * '... develop mechanisms that allow configuring and concurrently running
> multiple proxied stream- and datagram-based flows ...' -> is 'stream- and'
> still relevant?
>
> * 'The group will specify HTTP or HTTP/3 extensions' -> It's important
> that we understand the differences between these. HTTP extensions are
> methods, headers, status codes and the like; HTTP/3 extensions are frame
> types, options and the like. What's being attempted here appears to be
> defining a HTTP extension (or more) to negotiate use of one or more HTTP/3
> extensions. The problem we're going to face is that HTTP extensions are
> supposed to be version-independent; CONNECT and Upgrade have caused a fair
> amount of pain because they're not, and we're talking about extending that
> pattern. Not a showstopper, but we need to be thoughtful.
>
> * 'client-initiated services' -> I'd feel much better if the converse were
> explicitly ruled out, to make it crystal clear.
>
> * 'IP proxying' -> This is my only substantive concern; I strongly suspect
> that shoving the desired semantics into HTTP is going to distort both the
> protocol and the use case beyond recognition. It's one thing to have a
> single (!) gigacorp do it in a self-to-self integration for a specific
> purpose; that doesn't give us any information about whether it's useful or
> good to standardise it. Can we PLEASE drop this from the charter until we
> at least see a straw-man of how it might operate?
>
> * Regarding venue - I don't have strong feelings about this, as long as
> the HTTP semantics involved are discussed early and often with the *whole*
> HTTP WG (which means showing up and giving a summary of progress / taking
> feedback at regular intervals; unlike QUIC, this is defining HTTP
> semantics). FWIW we do have some capacity opening up there, and I think
> there would be willingness to take the UDP part on, at least.
>
> Cheers,
>
>
> > 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.
> >
> > 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."
> >
> >    https://github.
> .com/chris-wood/ietf-masque/blob/master/proposed_charter.md
>
> > > > 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.
> > >
> > > 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).
>
> > >
> > > > "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)"
> > >

---

From: Eric Rescorla <[email-masked]>
Date: Fri, 1 May 2020 16:54:47 -0700

Thanks for working ont his charter. This seems quite close.

1. I would like to see the WG explicitly prioritize the UDP work first.
Like Mark, I would actually prefer to drop IP, but won't lie down in the
ground over it. I do think it would be worthwhile getting a stronger sense
of community interests: specifically, a list of implementors who would do
it.
2. I agree with Mark that we need to decide whether CONNECT-UDP (or
whatever we call it) will work with HTTP < 3. I believe the answer should
be "yes"

-Ekr

On Fri, May 1, 2020 at 10:51 AM Martin Duke <[email-masked]> wrote:

>> * 'client-initiated services' -> I'd feel much better if the converse
>> were explicitly ruled out, to make it crystal clear.
>>
>> * 'IP proxying' -> This is my only substantive concern; I strongly
>> suspect that shoving the desired semantics into HTTP is going to distort
>> both the protocol and the use case beyond recognition. It's one thing to
>> have a single (!) gigacorp do it in a self-to-self integration for a
>> specific purpose; that doesn't give us any information about whether it's
>> useful or good to standardise it. Can we PLEASE drop this from the charter
>> until we at least see a straw-man of how it might operate?
>>
>> > On 30 Apr 2020, at 3:35 am, Martin Duke <[email-masked]
>> <[email-masked]>> wrote:
>> >
>> > MASQUE,
>> >
>> > "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
>> [email-masked] on behalf of [email-masked]
>> <mt@lowentropy..net>> wrote:
>> > > >
>> > > > "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)"
>> > >

---

From: Mark Nottingham <[email-masked]>
Date: Mon, 4 May 2020 16:27:56 +1000

> On 2 May 2020, at 3:45 am, Martin Duke <[email-masked]> wrote:
> 
> Hi Mark-- 
> 
> Thank you very much for the comments. We will certainly look at incorporating your minor concerns into the charter.
> 
> As for IP proxying: although I gather that you believe that this is not worth pursuing, I gather that there is a strong cohort in the community that disagrees. Whether or not it's in the charter, if there are specific problems that arise that make IP proxying unworkable,  there are numerous veto points that can block the work from moving further in the WG.

It's not that I don't think IP proxying is worth pursuing; on the face of it, it seems potentially worthwhile. I'm just not convinced that we have enough information to charter something that will succeed, and I'm concerned about the collateral damage of a partial failure. 

That may be because I'm biased towards charters with a defined goal and a shared understanding of a plan to get here (usually in the form of a proposed starting point); in my experience, that leads to successful outcomes. It's not always the case that this is necessary; sometimes you need room to experiment and fail. However, the consequences of a failure here would not be contained to this WG; there's a history of WGs that create messes that the HTTP WG later has to clean up (e.g., WEBDAV). 

So, if this were a proposal that came to the HTTP WG, we would (very reasonably, I think) ask that the proponents write down a proposal in draft form and present it to the WG before we adopted work in that area. I don't think it's unreasonable to ask that a more substantial proposal be available before something is chartered here.

> That said, I would like to adjust the charter language to ease your concerns, if possible. Is there something that would do that short of striking it entirely?

The usual practice in this situation is something like:

"Additionally, the Working Group can explore proposals for IP proxying over HTTP. If one gains consensus and demonstrated implementer interest, the group may request re-chartering to include such work. In doing so, the HTTP Working Group will need to be consulted regarding the design of any HTTP extensions."

Cheers,

---

From: Mirja Kuehlewind <[email-masked]>
Date: Mon, 4 May 2020 16:30:39 +0000

Hi all,

I agree with Martin that I thought we already had reached quite strong agreement that we have use cases and interest in implementing IP proxying. For many use cases, I see IP proxying as a way to support the same function for non UDP/QUIC traffic, e.g. for tunneling TCP, and that is an important incentive for deployment. I agree that more work is needed and we should focus in UDP proxying first but I don't see the same risk of failure as Mark seems to. I strongly support to have IP proxying in the charter in order to accommodate the use cases people are interested in and set the goals of this group clearly.

Mirja

    

    

    
    Cheers,

    > Mark Nottingham   https://protect2.fireeye.com/v1/url?k=f27833a8-acd889c6-f2787333-869a14f4b08c-56165197c79316e4&q=1&e=5b6cfd4d-28da-4c77-9cf1-0149352aadde&u=https%3A%2F%2Fwww.mnot.net%2F
    > 
    
    --
    Mark Nottingham   https://protect2.fireeye.com/v1/url?k=12f8b28a-4c5808e4-12f8f211-869a14f4b08c-10fde3d5f0b90f32&q=1&e=5b6cfd4d-28da-4c77-9cf1-0149352aadde&u=https%3A%2F%2Fwww.mnot.net%2F

---

From: David Schinazi <[email-masked]>
Date: Mon, 4 May 2020 14:46:55 -0700

Hi Mark,

I understand that you do not have a use for proxying IP. However, many
folks on this list have shown interest in it, and a desire to work on it. I
don't think it's fair to request that we solve the problem before we
charter a WG. We already have agreement on the fact that proxying UDP will
be done first, and that ensures that IP proxying won't cause collateral
damage to UDP proxying. The charter also contains text about coordinating
closely with HTTPBIS, so members of that WG will have the opportunity to
prevent a "mess" from being published. I don't think we should prevent
discussion on this topic because of past unrelated "messes".

Thanks,
David

On Mon, May 4, 2020 at 9:30 AM Mirja Kuehlewind <mirja.kuehlewind=
[email-masked]> wrote:

> Hi all,
>
> I agree with Martin that I thought we already had reached quite strong
> agreement that we have use cases and interest in implementing IP proxying.
> For many use cases, I see IP proxying as a way to support the same function
> for non UDP/QUIC traffic, e.g. for tunneling TCP, and that is an important
> incentive for deployment. I agree that more work is needed and we should
> focus in UDP proxying first but I don't see the same risk of failure as
> Mark seems to. I strongly support to have IP proxying in the charter in
> order to accommodate the use cases people are interested in and set the
> goals of this group clearly.
>
> Mirja
>
>
> On 04.05.20, 08:28, "Masque on behalf of Mark Nottingham" <
> [email-masked] on behalf of [email-masked]> wrote:
>
>     > As for IP proxying: although I gather that you believe that this is
> not worth pursuing, I gather that there is a strong cohort in the community
>     It's not that I don't think IP proxying is worth pursuing; on the face
> of it, it seems potentially worthwhile. I'm just not convinced that we have
> enough information to charter something that will succeed, and I'm
> concerned about the collateral damage of a partial failure.
>
>     That may be because I'm biased towards charters with a defined goal
> and a shared understanding of a plan to get here (usually in the form of a
> proposed starting point); in my experience, that leads to successful
> outcomes. It's not always the case that this is necessary; sometimes you
> need room to experiment and fail. However, the consequences of a failure
> here would not be contained to this WG; there's a history of WGs that
> create messes that the HTTP WG later has to clean up (e.g., WEBDAV).
>
>     So, if this were a proposal that came to the HTTP WG, we would (very
> reasonably, I think) ask that the proponents write down a proposal in draft
> form and present it to the WG before we adopted work in that area. I don't
> think it's unreasonable to ask that a more substantial proposal be
> available before something is chartered here.
>
>     "Additionally, the Working Group can explore proposals for IP proxying
> over HTTP. If one gains consensus and demonstrated implementer interest,
> the group may request re-chartering to include such work. In doing so, the
> HTTP Working Group will need to be consulted regarding the design of any
> HTTP extensions."
>
>     Cheers,
>
>
>     >
>     > * '... develop mechanisms that allow configuring and concurrently
> running multiple proxied stream- and datagram-based flows ...' -> is
> 'stream- and' still relevant?
>     >
>     > * 'The group will specify HTTP or HTTP/3 extensions' -> It's
> important that we understand the differences between these. HTTP extensions
> are methods, headers, status codes and the like; HTTP/3 extensions are
> frame types, options and the like. What's being attempted here appears to
> be defining a HTTP extension (or more) to negotiate use of one or more
> HTTP/3 extensions. The problem we're going to face is that HTTP extensions
> are supposed to be version-independent; CONNECT and Upgrade have caused a
> fair amount of pain because they're not, and we're talking about extending
> that pattern. Not a showstopper, but we need to be thoughtful.
>     >
>     > * 'client-initiated services' -> I'd feel much better if the
> converse were explicitly ruled out, to make it crystal clear.
>     >
>     > * Regarding venue - I don't have strong feelings about this, as long
> as the HTTP semantics involved are discussed early and often with the
> *whole* HTTP WG (which means showing up and giving a summary of progress /
> taking feedback at regular intervals; unlike QUIC, this is defining HTTP
>     > > 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.
>     > >
>     > > Thanks for raising these points, all! We adjusted the charter to
> take them into account. In particular, we added the following paragraph:
>     > >
>     > > > > 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
>     > > > >  The designs floated so far have a fallback to TCP, just like
> most QUIC deployments do, so I wouldn't rely on that.
>     > > >
>     > Mark Nottingham
> https://protect2.fireeye.com/v1/url?k=f27833a8-acd889c6-f2787333-869a14f4b08c-56165197c79316e4&q=1&e=5b6cfd4d-28da-4c77-9cf1-0149352aadde&u=https%3A%2F%2Fwww.mnot.net%2F
>     >
>
>     --
>     Mark Nottingham
> https://protect2.fireeye.com/v1/url?k=12f8b28a-4c5808e4-12f8f211-869a14f4b08c-10fde3d5f0b90f32&q=1&e=5b6cfd4d-28da-4c77-9cf1-0149352aadde&u=https%3A%2F%2Fwww.mnot.net%2F
>
>     --
>     Masque mailing list
>     [email-masked]

---

From: Mark Nottingham <[email-masked]>
Date: Tue, 5 May 2020 07:51:17 +1000

David,

Could you please read and reply to my response to Martin? Apparently I didn’t express myself well; it’s not that I think it’s useless.  

Sent from my iPhone

> On 5 May 2020, at 7:47 am, David Schinazi <[email-masked]> wrote:
> 
> 
> Hi Mark,
> 
> I understand that you do not have a use for proxying IP. However, many folks on this list have shown interest in it, and a desire to work on it. I don't think it's fair to request that we solve the problem before we charter a WG. We already have agreement on the fact that proxying UDP will be done first, and that ensures that IP proxying won't cause collateral damage to UDP proxying. The charter also contains text about coordinating closely with HTTPBIS, so members of that WG will have the opportunity to prevent a "mess" from being published. I don't think we should prevent discussion on this topic because of past unrelated "messes".
> 
> Thanks,
> David
> 
>> On Mon, May 4, 2020 at 9:30 AM Mirja Kuehlewind <mirja.kuehlewind=[email-masked]> wrote:
>> Hi all,
>>

---

From: David Schinazi <[email-masked]>
Date: Mon, 4 May 2020 17:22:09 -0700

Hi folks,

Mark and I had a productive side-conversation about this offline, and came
to a resolution that I think we both like. (Mark please confirm whether you
agree with this summary)

How about we tweak the charter to say that MASQUE will start with two work
items:
1) a protocol solution for UDP proxying
2) a requirements document for IP proxying
and once those two have been completed successfully, work can start on
3) a protocol solution for IP proxying

I think this addresses Mark's concerns while not requiring us to recharter
to get the IP proxying work done.

Would that be an acceptable resolution?

Thanks,
David

On Mon, May 4, 2020 at 2:51 PM Mark Nottingham <[email-masked]> wrote:

> David,
>
> Could you please read and reply to my response to Martin? Apparently I
> didn’t express myself well; it’s not that I think it’s useless.
>
>
> Sent from my iPhone
>
>>     It's not that I don't think IP proxying is worth pursuing; on the
>> face of it, it seems potentially worthwhile. I'm just not convinced that we
>> have enough information to charter something that will succeed, and I'm
>>     "Additionally, the Working Group can explore proposals for IP
>> proxying over HTTP. If one gains consensus and demonstrated implementer
>> interest, the group may request re-chartering to include such work. In
>> doing so, the HTTP Working Group will need to be consulted regarding the
>> design of any HTTP extensions."
>>
>>     Cheers,
>>
>>
>>     >
>>     > I just caught up with the threads over the last few weeks; sorry
>> for coming in at the last minute, I got distracted.
>>     >
>>     > * Regarding venue - I don't have strong feelings about this, as
>> long as the HTTP semantics involved are discussed early and often with the

---

From: Eric Rescorla <[email-masked]>
Date: Mon, 4 May 2020 17:32:59 -0700

I can live with this. I can also live with the current text if need be, but
I think this is better.

-Ekr

On Mon, May 4, 2020 at 5:22 PM David Schinazi <[email-masked]>
wrote:

>>>     > As for IP proxying: although I gather that you believe that this
>>> is not worth pursuing, I gather that there is a strong cohort in the
>>> community that disagrees. Whether or not it's in the charter, if there are
>>> specific problems that arise that make IP proxying unworkable,  there are
>>> numerous veto points that can block the work from moving further in the WG.
>>>
>>>     > That said, I would like to adjust the charter language to ease
>>> your concerns, if possible. Is there something that would do that short of
>>> striking it entirely?
>>>
>>>     > > 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.
>>>     > >
>>>     > > > > 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.
>>>     > > >

---

From: "Martin Thomson" <[email-masked]>
Date: Tue, 05 May 2020 10:33:39 +1000

> 3) a protocol solution for IP proxying

This sounds far more achievable.  Thanks for working that out.

---

From: Spencer Dawkins at IETF <[email-masked]>
Date: Mon, 4 May 2020 21:11:11 -0500

> This sounds far more achievable.  Thanks for working that out.

I think that's "sufficiently chartered for IP", and chairs can certainly
prioritize the work among deliverables.

Mark and David, thanks for proposing the text.

Spencer

---

From: "Christopher Wood" <[email-masked]>
Date: Tue, 05 May 2020 13:49:58 -0700

Thanks, all! Here's an updated snippet of the charter that includes this feedback (as well as other comments from Mark):

~~~
The primary goal of this working group is to develop mechanisms that allow configuring and concurrently running multiple proxied stream- and datagram-based flows inside an HTTP connection. The group will specify HTTP and/or HTTP/3 extensions to enable this functionality. The group will focus on a limited set of client-initiated services: (1) UDP CONNECT and (2) IP proxying. Server-initiated services are out of scope. The working group will first deliver a protcol solution for UDP CONNECT and a requirements document for IP proxying. Once both are complete, the working group will focus on a protocol solution for IP proxying.

The working group will consider fallback to versions of HTTP that operate over TCP as a mitigation to UDP or HTTP/3 blocking. Moreover, the working group will consider 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 may be found here:

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

Thanks again to everyone who's helped clarify, refine, and improve this text!

Best,
Chris

On Mon, May 4, 2020, at 7:11 PM, Spencer Dawkins at IETF wrote:
> I think that's "sufficiently chartered for IP", and chairs can 
> certainly prioritize the work among deliverables.
>

---

From: Martin Duke <[email-masked]>
Date: Tue, 5 May 2020 14:10:04 -0700

Once again, I'll leave the rest of the week for any other significant
concerns before I ship the charter to the IESG.

On Tue, May 5, 2020 at 1:51 PM Christopher Wood <[email-masked]> wrote:

> Thanks, all! Here's an updated snippet of the charter that includes this
> feedback (as well as other comments from Mark):
>
> ~~~
> The primary goal of this working group is to develop mechanisms that allow
> configuring and concurrently running multiple proxied stream- and
> datagram-based flows inside an HTTP connection. The group will specify HTTP
> and/or HTTP/3 extensions to enable this functionality. The group will focus
> on a limited set of client-initiated services: (1) UDP CONNECT and (2) IP
> proxying. Server-initiated services are out of scope. The working group
> will first deliver a protcol solution for UDP CONNECT and a requirements
> document for IP proxying. Once both are complete, the working group will
> focus on a protocol solution for IP proxying.
>
> The working group will consider fallback to versions of HTTP that operate
> over TCP as a mitigation to UDP or HTTP/3 blocking. Moreover, the working
> group will consider 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.
> ~~~
>

---

From: Eric Rescorla <[email-masked]>
Date: Tue, 5 May 2020 14:35:51 -0700

On Tue, May 5, 2020 at 1:51 PM Christopher Wood <[email-masked]> wrote:

> over TCP as a mitigation to UDP or HTTP/3 blocking.

This seems pretty soft. Why isn't this a requirement?

-Ekr

Moreover, the working group will consider implications of tunneling
> algorithms are out of scope.
> ~~~
>