Subject: Re-chartering for extension work

From: Mark Nottingham <[email-masked]>
Date: Thu, 12 Dec 2019 08:38:27 +1100

We've just put out Calls for Adoption for extensions to QUICv1, as we believe that the group has some capacity to discuss them as it finishes work on the core protocol.

However, our charter [1] precludes work on at least some extensions. The specific text in question is:

"""
Extensions that will support partial reliability, and negotiation and use of Forward Error Correction schemes, are out of scope in this version of the working group charter.
"""

*If* we do decide we'd like to adopt, we'll need to update it to something like:

"""
Additionally, the Working Group will deliver [ adopted extensions ]. The Working Group may consider other extension work, but adopting further extensions requires updating this charter.
"""

Please take a look and discuss any concerns; we'll be asking our ADs for such a modification (with appropriate changes to the list of extensions adopted) once our Calls for Adoption complete.

Cheers,

1. https://datatracker.ietf.org/wg/quic/about/

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

---

From: Jana Iyengar <[email-masked]>
Date: Wed, 11 Dec 2019 14:35:51 -0800

Mark,

I'm supportive of changing the language in the charter.

When we wrote the charter, the intent was to preclude work that might have
interfered with getting the important work of the core protocol done, and
the things we could think of at the time were partial reliability and FEC.
That's clearly an incomplete list, as we can see with the extensions that
are being proposed.

I am supportive of the new language you propose.

That said, I'd like to tease something out. If I understand this correctly,
the charter as it is allows for at least one of the currently proposed
extensions to be adopted -- the version negotiation extension. Under the
proposed language, we couldn't have adopted this extension since it
wouldn't have been on a list of extensions. The rest of the charter talks
about focus areas, not about specific documents and extensibility
mechanisms. The proposed text lists extensions, which means that any
extensions, even minor ones, will require a recharter. This is a tightening
of the charter, which I support.

If my understanding is correct, I would hope that we remain open to
rechartering as and when the wg agrees on adoption of new extensions.

- jana

On Wed, Dec 11, 2019 at 1:38 PM Mark Nottingham <[email-masked]> wrote:

> We've just put out Calls for Adoption for extensions to QUICv1, as we
> believe that the group has some capacity to discuss them as it finishes
> work on the core protocol.
>
> Extensions that will support partial reliability, and negotiation and use
> of Forward Error Correction schemes, are out of scope in this version of
> the working group charter.
> """
>
> Additionally, the Working Group will deliver [ adopted extensions ]. The
> Working Group may consider other extension work, but adopting further
> extensions requires updating this charter.
> """
>
> Please take a look and discuss any concerns; we'll be asking our ADs for
> such a modification (with appropriate changes to the list of extensions
> adopted) once our Calls for Adoption complete.
>
> Cheers,
>

---

From: "Lubashev, Igor" <[email-masked]>
Date: Thu, 12 Dec 2019 01:14:53 +0000

Mark,

How would the WG operate with the proposed charter?  If there is a proposed extension work that is not already named in the charter, it is out-of-scope and cannot be adopted (and hence a Call for Adoption cannot be made).  But updating the charter would require naming the proposed extension that has not, yet, been adopted.  Would we be replacing a Call for Adoption with a Call for Charter Update?  This seems to invite a confusion in the process.

I understand that we want to protect our ability to deliver QUIC v1 ASAP.  Would it work to state explicitly in the charter that QUIC v1 (and HTTP binding) work will always have a priority over extensions in allocating WG meeting time at IETF meetings and interims?

  *   Igor

On Wed, Dec 100 at 2019 5:36 PM, Jana Iyengar <[email-masked]> wrote:
Mark,

When we wrote the charter, the intent was to preclude work that might have interfered with getting the important work of the core protocol done, and the things we could think of at the time were partial reliability and FEC. That's clearly an incomplete list, as we can see with the extensions that are being proposed.

That said, I'd like to tease something out.. If I understand this correctly, the charter as it is allows for at least one of the currently proposed extensions to be adopted -- the version negotiation extension. Under the proposed language, we couldn't have adopted this extension since it wouldn't have been on a list of extensions. The rest of the charter talks about focus areas, not about specific documents and extensibility mechanisms. The proposed text lists extensions, which means that any extensions, even minor ones, will require a recharter. This is a tightening of the charter, which I support.

If my understanding is correct, I would hope that we remain open to rechartering as and when the wg agrees on adoption of new extensions.

- jana

On Wed, Dec 11, 2019 at 1:38 PM Mark Nottingham <[email-masked]<mailto:[email-masked]>> wrote:
We've just put out Calls for Adoption for extensions to QUICv1, as we believe that the group has some capacity to discuss them as it finishes work on the core protocol.

"""

"""

Cheers,

1. https://datatracker.ietf.org/wg/quic/about/<https://urldefense.proofpoint.com/v2/url?u=https-3A__datatracker.ietf.org_wg_quic_about_&d=DwMFaQ&c=96ZbZZcaMF4w0F4jpN6LZg&r=Djn3bQ5uNJDPM_2skfL3rW1tzcIxyjUZdn_m55KPmlo&m=rk0iVRG56sOYkHN38optDbyqD46-Xipkv0G_Fq5xzXg&s=MoD-CaRMGGLqvBj7zU7nMUSRSK25lnl3xR6jMFXtGgg&e=>

--
Mark Nottingham   https://www.mnot.net/<https://urldefense.proofpoint.com/v2/url?u=https-3A__www.mnot.net_&d=DwMFaQ&c=96ZbZZcaMF4w0F4jpN6LZg&r=Djn3bQ5uNJDPM_2skfL3rW1tzcIxyjUZdn_m55KPmlo&m=rk0iVRG56sOYkHN38optDbyqD46-Xipkv0G_Fq5xzXg&s=FI__zKN--MpO5urwCLnWVnP16lhh3L5cWMY2QWHYou4&e=>

---

From: "Martin Thomson" <[email-masked]>
Date: Thu, 12 Dec 2019 12:28:44 +1100

On Thu, Dec 12, 2019, at 08:38, Mark Nottingham wrote:
> """
> Additionally, the Working Group will deliver [ adopted extensions ]. 
> The Working Group may consider other extension work, but adopting 
> further extensions requires updating this charter.
> """

The way I read this is that this working group is saying that we believe this set of extensions is important.  And we are proposing a charter to the IETF as a whole that recognizes that.  I expect IETF last call to ratify that view, but I might be surprised and learn something.

That's good, because it means that the scope of the work we undertake is not entirely in our control.  We don't get to work on "any extension".  At least not just yet.  If we were having this same conversation after there was a suite of QUIC RFCs, I might suggest that this be more loose.  For instance, the TLS working group is able to adopt extensions at their sole discretion.  But we can leave that discussion for later.  Right now, we still haven't shipped the core protocol.  Until we do, it's entirely appropriate to have a tightly constrained set of topics to work on.  And to require IETF review for any changes to that scope.

I know that the chairs are highly focused on getting that core protocol done and won't allow us to get distracted from that task, but even this change adds some risk.  We need to remember that until we are done with a version 1, that risk remains.  I think that the risk is manageable with this expansion to the scope, but it will require some discipline.

FWIW, I don't think we need to recharter to do the version negotiation thing on the basis that providing for a protocol's eventual replacement is just part of defining a good protocol, but I'm happy including it in this set for the sake of simplicity.

---

From: "Roni Even (A)" <[email-masked]>
Date: Thu, 12 Dec 2019 06:49:30 +0000

Hi Mark,
I am not sure why you need to name extensions in the charter. I think that the extension work in the charter should be general and the discussion about specific ones would be about creating a new milestone.

BTW: maybe it will be good to update the milestones

Roni Even

> -----Original Message-----
> From: QUIC [mailto:[email-masked]] On Behalf Of Mark Nottingham
> Sent: Wednesday, December 11, 2019 11:38 PM
> To: IETF QUIC WG
> Cc: Lars Eggert
> Subject: Re-chartering for extension work
> 
> We've just put out Calls for Adoption for extensions to QUICv1, as we believe
> that the group has some capacity to discuss them as it finishes work on the
> core protocol.
> 
> Extensions that will support partial reliability, and negotiation and use of
> Forward Error Correction schemes, are out of scope in this version of the
> working group charter.
> """
> 
> Please take a look and discuss any concerns; we'll be asking our ADs for such
> a modification (with appropriate changes to the list of extensions adopted)
> once our Calls for Adoption complete.
> 
> Cheers,
>

---

From: Mark Nottingham <[email-masked]>
Date: Thu, 12 Dec 2019 17:57:59 +1100

> On 12 Dec 2019, at 9:35 am, Jana Iyengar <[email-masked]> wrote:
> 
> Mark,
> 
> That said, I'd like to tease something out. If I understand this correctly, the charter as it is allows for at least one of the currently proposed extensions to be adopted -- the version negotiation extension. Under the proposed language, we couldn't have adopted this extension since it wouldn't have been on a list of extensions. The rest of the charter talks about focus areas, not about specific documents and extensibility mechanisms. The proposed text lists extensions, which means that any extensions, even minor ones, will require a recharter. This is a tightening of the charter, which I support.
> 

That's the intent, yes; while eventually we might open up, we want to be deliberate about adding new work items while we're still focused on QUICv1.

Cheers,

---

From: Mark Nottingham <[email-masked]>
Date: Thu, 12 Dec 2019 17:59:32 +1100

Igor,

> On 12 Dec 2019, at 12:14 pm, Lubashev, Igor <[email-masked]> wrote:
> 
> Mark,
>  

Luckily, we haven't yet automated WG processes to that degree yet; we're working with the AD to make sure that our charter is updated at the correct time.
> I understand that we want to protect our ability to deliver QUIC v1 ASAP.  Would it work to state explicitly in the charter that QUIC v1 (and HTTP binding) work will always have a priority over ext…

I don't think it's necessary to micro-manage the Chairs' work in the charter to that degree, but if the AD feels otherwise, they can reflect this in the update.

Cheers,

> 	• Igor

---

From: Mark Nottingham <[email-masked]>
Date: Thu, 12 Dec 2019 18:00:05 +1100

Hi Roni,

See my response to Jana regarding naming of extensions.

Regarding milestones - yes, we'll do that when the rest of the changes go through. Thanks for the reminder.

Cheers,

> On 12 Dec 2019, at 5:49 pm, Roni Even (A) <[email-masked]> wrote:
> 
> Hi Mark,

---

From: "Roni Even (A)" <[email-masked]>
Date: Thu, 12 Dec 2019 07:13:53 +0000

HI Mark,
I looked at your response to Jana, I do not have a better text suggestion but I think that adding specific extensions can be discussed by asking the WG to create a new milestone. Yet I understand that the charter should be clear about what is in scope for the WG. I think that maybe the charter should also say that the WG can direct proposal for new work to another WG (sort of dispatch for QUIC).

One other thing, I think that when asking for adoption of a document you are asking to create a milestone and adopt the document as the initial document to address the milestone. 
Sorry for sounding like someone whose focus is on the process and not the content.

Roni

> From: Mark Nottingham [mailto:[email-masked]]
> Sent: Thursday, December 12, 2019 9:00 AM
> To: Roni Even (A)
> Cc: IETF QUIC WG; Lars Eggert
> Subject: Re: Re-chartering for extension work
> 
> Hi Roni,
> 
> > I am not sure why you need to name extensions in the charter. I think that
> the extension work in the charter should be general and the discussion about
> specific ones would be about creating a new milestone.
> >
> >> believe that the group has some capacity to discuss them as it
> >> finishes work on the core protocol.
> >>
> >> Extensions that will support partial reliability, and negotiation and
> >> use of Forward Error Correction schemes, are out of scope in this
> >> version of the working group charter.
> >> """
> >>
> >> *If* we do decide we'd like to adopt, we'll need to update it to
> >> something
> >> like:
> >>
> >> """
> >> Please take a look and discuss any concerns; we'll be asking our ADs
> >> for such a modification (with appropriate changes to the list of
> >> extensions adopted) once our Calls for Adoption complete.
> >>
> >> Cheers,
> >>

---

From: Mark Nottingham <[email-masked]>
Date: Thu, 12 Dec 2019 18:15:26 +1100

> On 12 Dec 2019, at 6:13 pm, Roni Even (A) <[email-masked]> wrote:
> 
> HI Mark,

That's been discussed (at the Transport Area meeting in Singapore); we might try an experiment where we do something like that in Vancouver, but it's not clear that *this* WG should be the locus of quic-dispatchy things quite yet.

Cheers,

---

From: "Roni Even (A)" <[email-masked]>
Date: Thu, 12 Dec 2019 07:41:50 +0000

Hi Mark,
I know that it was discussed in tsvarea session. I noticed that are currently 19 individual drafts in QUIC. I am not sure that all of them should be adopted as chartered work in QUIC. My view is that the WG should at least say so and propose to the authors to take it to a named WG ( probably need recommendation from the Ads) instead of keeping them alive in the QUIC as related IDs. Currently the authors can ask to add these documents to the charter based on the proposed charter change

" The Working Group may consider other extension work, but adopting further extensions requires updating this charter."

This is like a new call for adoption process, instead for asking for adoption the question will be call for re-charter.

Roni

> Sent: Thursday, December 12, 2019 9:15 AM
> To: Roni Even (A)
> > I looked at your response to Jana, I do not have a better text suggestion
> but I think that adding specific extensions can be discussed by asking the WG
> to create a new milestone. Yet I understand that the charter should be clear
> about what is in scope for the WG. I think that maybe the charter should also
> say that the WG can direct proposal for new work to another WG (sort of
> dispatch for QUIC).
> 
> That's been discussed (at the Transport Area meeting in Singapore); we
> might try an experiment where we do something like that in Vancouver, but
> it's not clear that *this* WG should be the locus of quic-dispatchy things
> quite yet.
> 
> Cheers,
> 
> 
> > One other thing, I think that when asking for adoption of a document you
> are asking to create a milestone and adopt the document as the initial
> document to address the milestone.
> >> Regarding milestones - yes, we'll do that when the rest of the
> >> changes go through. Thanks for the reminder.
> >>
> >> Cheers,
> >>
> >>
> >> the extension work in the charter should be general and the
> >> discussion about specific ones would be about creating a new milestone.
> >>>
> >>>> We've just put out Calls for Adoption for extensions to QUICv1, as
> >>>> we believe that the group has some capacity to discuss them as it
> >>>> Extensions that will support partial reliability, and negotiation
> >>>> and use of Forward Error Correction schemes, are out of scope in
> >>>> this version of the working group charter.
> >>>> """
> >>>>
> >>>> Please take a look and discuss any concerns; we'll be asking our
> >>>> ADs for such a modification (with appropriate changes to the list
> >>>> of extensions adopted) once our Calls for Adoption complete.
> >>>>
> >>>> Cheers,
> >>>>

---

From: Magnus Westerlund <[email-masked]>
Date: Thu, 12 Dec 2019 09:07:43 +0000

Hi,

I want to give my input as AD into this process. We are intentionally keeping
this rechartering very narrow in scope and do not intended to open up for
general extension adoption in the WG at this moment. The extensions currently on
call for adoption is selected set which appears important, tractable and with
clear scope. However, the primary focus will remain on finishing the core
specification of version 1 of QUIC. The chairs have my full confidence in
managing the process and are communicating with us ADs regularly. 

As Mark stated before discussion of future extensions can occurr if time
permits, we will also consider other ways of enabling the discussion like a QUIC
dispatch session. However, as v1 finish we will take a new look at the QUIC WG
charter and do a more thourgh recharter at that stage. That discussion will then
happen in the context of the discussion that will have occurred between now and
then. However, starting v2, how to handle both bigger and smaller extensions to
the protocol and any additional guidance documents needed will clearly need
changes to the charter. 

I hope that clarifies the road forward. 

Cheers

Magnus Westerlund

On Thu, 2019-12-12 at 07:41 +0000, Roni Even (A) wrote:
> Hi Mark,
> I know that it was discussed in tsvarea session. I noticed that are currently
> 19 individual drafts in QUIC. I am not sure that all of them should be adopted
> as chartered work in QUIC. My view is that the WG should at least say so and
> propose to the authors to take it to a named WG ( probably need recommendation
> from the Ads) instead of keeping them alive in the QUIC as related IDs.
> Currently the authors can ask to add these documents to the charter based on
> the proposed charter change
> 
> " The Working Group may consider other extension work, but adopting further
> extensions requires updating this charter."
> 
> This is like a new call for adoption process, instead for asking for adoption
> the question will be call for re-charter.
> 
> Roni
> 
> 
> > > On 12 Dec 2019, at 6:13 pm, Roni Even (A) <[email-masked]>
> > 
> > wrote:
> > > 
> > > HI Mark,
> > > Sorry for sounding like someone whose focus is on the process and not the
> > 
> > content.
> > > 
> > > Roni
> > > 
> > > > > On 12 Dec 2019, at 5:49 pm, Roni Even (A) <[email-masked]>
> > > > 
> > > > wrote:
> > > > > 
> > > > > Hi Mark,
> > > > discussion about specific ones would be about creating a new milestone..
> > > > > 
> > > > > > Mark Nottingham   
> > > > > > https://protect2.fireeye.com/v1/url?k=2f5948b0-73cb45af-2f59082b-0cc47ad93db4-7b6490019ba3569f&q=1&e=4eadb99e-52e4-49b3-adef-683bb7f58fea&u=https%3A%2F%2Fwww.mnot.net%2F
> > > > 
> > > > --
> > > > Mark Nottingham   
> > > > https://protect2.fireeye.com/v1/url?k=bc29a42a-e0bba935-bc29e4b1-0cc47ad93db4-eaf17369ba9839a7&q=1&e=4eadb99e-52e4-49b3-adef-683bb7f58fea&u=https%3A%2F%2Fwww.mnot.net%2F
> > 
> > --
> > Mark Nottingham   
> > https://protect2.fireeye.com/v1/url?k=21be3936-7d2c3429-21be79ad-0cc47ad93db4-613c07cadcb96094&q=1&e=4eadb99e-52e4-49b3-adef-683bb7f58fea&u=https%3A%2F%2Fwww.mnot.net%2F
> 
> 
-- 
Cheers

Magnus Westerlund 

----------------------------------------------------------------------
Networks, Ericsson Research
----------------------------------------------------------------------
Ericsson AB                 | Phone  +46 10 7148287
Torshamnsgatan 23           | Mobile +46 73 0949079
SE-164 80 Stockholm, Sweden | mailto: [email-masked]
----------------------------------------------------------------------

---

From: "Roni Even (A)" <[email-masked]>
Date: Thu, 12 Dec 2019 09:51:33 +0000

Hi
This clarifies the proposed charter and the priority of the V1 document  but as for future extensions the text from the meeting notes says

"Mnot: If you do think you have an extension which is generic enough, we will reserve time for it during the quiet for disucssion on the list. For this, we will need a charter change for that, but we've been talking to the ADs about that, and we'll put a proposal out for comment."

How is this reflected in the charter, which extensions will be considered "generic enough" and appear by name in it. There are three extensions for adoption and they look generic enough more (version negotiation, datagrams)   or less (LBs), so why not lossbit, for example or any other from the related I-Ds that are "generic enough". The problem in my view is that if all these drafts are not in the proposed charter, they cannot be discussed at all during the "quiet" .  I would prefer to allow in the charter and decide if to create a milestone. 

Roni 

> From: Magnus Westerlund [mailto:[email-masked]]
> Sent: Thursday, December 12, 2019 11:08 AM
> To: Roni Even (A); [email-masked]
> Cc: [email-masked]; [email-masked]
> > > > > > > However, our charter [1] precludes work on at least some
> extensions.
> > > > > > > The specific text in question is:
> > > > > > >
> > > > > > > """
> > > > > > > https://protect2.fireeye.com/v1/url?k=2f5948b0-73cb45af-
> 2f59082b-0cc47ad93db4-7b6490019ba3569f&q=1&e=4eadb99e-52e4-49b3-
> adef-683bb7f58fea&u=https%3A%2F%2Fwww.mnot.net%2F
> > > > >
> > > > > --
> > > > > Mark Nottingham
> > > > > https://protect2.fireeye.com/v1/url?k=bc29a42a-e0bba935-
> bc29e4b1-0cc47ad93db4-eaf17369ba9839a7&q=1&e=4eadb99e-52e4-49b3-
> adef-683bb7f58fea&u=https%3A%2F%2Fwww.mnot.net%2F
> > >
> > > --
> > > Mark Nottingham
> > > https://protect2.fireeye.com/v1/url?k=21be3936-7d2c3429-21be79ad-
> 0cc47ad93db4-613c07cadcb96094&q=1&e=4eadb99e-52e4-49b3-adef-
> 683bb7f58fea&u=https%3A%2F%2Fwww.mnot.net%2F
> >
> >
> --
> Cheers
> 
> Magnus Westerlund
> 
>

---

From: "Salz, Rich" <[email-masked]>
Date: Thu, 12 Dec 2019 14:35:04 +0000

>    That's the intent, yes; while eventually we might open up, we want to be deliberate about adding new work items while we're still focused on QUICv1.

Other groups have worked this way as well.  LAMPS, for example, just rechartered to bring two docs into scope so we could adopt them. The main difference here is that QUIC expects to do this again :)

---

From: "Lubashev, Igor" <[email-masked]>
Date: Thu, 12 Dec 2019 16:14:44 +0000

Mark,

Speaking of lossbits, the work has been discussed at several meetings and there was a significant show of willingness of work on lossbits at the mic line in Singapore, on the condition that the work is (a) a negotiated extension, (b) the use of the bits is strictly specified, and (c) it is not blocking for QUIC v1.

We were planning to present the draft of lossbits as a negotiated extension in Zurich, but given that the time for the inclusion in the Charter is now, we can get the draft out next week.  Given the prior discussion and expressed willingness of at least a part of the WG to work on this, would you include that extension draft in the WG adoption call prior to the charter update?  (As usual, adoption != publication, which is subject to the deliberations of the WG, including a positive privacy/security analysis.)

- Igor

> On Thu, Dec 12, 2019 at 4:52 AM, Roni Even (A) <[email-masked]> wrote:
> 
> Hi
> This clarifies the proposed charter and the priority of the V1 document  but
> as for future extensions the text from the meeting notes says
> 
> "Mnot: If you do think you have an extension which is generic enough, we
> will reserve time for it during the quiet for disucssion on the list. For this, we
> will need a charter change for that, but we've been talking to the ADs about
> that, and we'll put a proposal out for comment."
> 
> How is this reflected in the charter, which extensions will be considered
> "generic enough" and appear by name in it. There are three extensions for
> adoption and they look generic enough more (version negotiation,
> datagrams)   or less (LBs), so why not lossbit, for example or any other from
> the related I-Ds that are "generic enough". The problem in my view is that if
> all these drafts are not in the proposed charter, they cannot be discussed at
> all during the "quiet" .  I would prefer to allow in the charter and decide if to
> create a milestone.
> 
> Roni
> 
> > I want to give my input as AD into this process. We are intentionally
> > keeping this rechartering very narrow in scope and do not intended to
> > open up for general extension adoption in the WG at this moment. The
> > extensions currently on call for adoption is selected set which
> > appears important, tractable and with clear scope. However, the
> > primary focus will remain on finishing the core specification of
> > version 1 of QUIC. The chairs have my full confidence in managing the
> > process and are communicating with us ADs regularly.
> >
> > As Mark stated before discussion of future extensions can occurr if
> > time permits, we will also consider other ways of enabling the
> > discussion like a QUIC dispatch session. However, as v1 finish we will
> > take a new look at the QUIC WG charter and do a more thourgh recharter
> > at that stage. That discussion will then happen in the context of the
> > discussion that will have occurred between now and then. However,
> > starting v2, how to handle both bigger and smaller extensions to the
> > protocol and any additional guidance documents needed will clearly
> > need changes to the charter.
> >
> > > 19 individual drafts in QUIC. I am not sure that all of them should
> > > be
> > adopted
> > > as chartered work in QUIC. My view is that the WG should at least
> > > say so
> > and
> > > Currently the authors can ask to add these documents to the charter
> > > based
> > on
> > > This is like a new call for adoption process, instead for asking for
> > > adoption the question will be call for re-charter.
> > >
> > > Roni
> > >
> > >
> > > > but I think that adding specific extensions can be discussed by
> > > > asking the WG to create a new milestone. Yet I understand that the
> > > > charter should be
> > clear
> > > > about what is in scope for the WG. I think that maybe the charter
> > > > should also say that the WG can direct proposal for new work to
> > > > another WG (sort of dispatch for QUIC).
> > > >
> > > > That's been discussed (at the Transport Area meeting in
> > > > Singapore); we might try an experiment where we do something like
> > > > that in Vancouver,
> > but
> > > > it's not clear that *this* WG should be the locus of
> > > > quic-dispatchy things quite yet.
> > > >
> > > > Cheers,
> > > >
> > > >
> > > > > One other thing, I think that when asking for adoption of a
> > > > > document
> > you
> > > >
> > > > are asking to create a milestone and adopt the document as the
> > > > initial document to address the milestone.
> > > > > Sorry for sounding like someone whose focus is on the process
> > > > > and not
> > the
> > > >
> > > > content.
> > > > >
> > > > > Roni
> > > > >
> > > > > > > > We've just put out Calls for Adoption for extensions to
> > > > > > > > QUICv1, as we believe that the group has some capacity to
> > > > > > > > discuss them as it finishes work on the core protocol.
> > > > > > > >
> > > > > > > > Extensions that will support partial reliability, and
> > > > > > > > negotiation and use of Forward Error Correction schemes,
> > > > > > > > are out of scope in this version of the working group charter.
> > > > > > > > """
> > > > > > > >
> > > > > > > > *If* we do decide we'd like to adopt, we'll need to update
> > > > > > > > it to something
> > > > > > > > like:
> > > > > > > >
> > > > > > > > """
> > > > > > > > Additionally, the Working Group will deliver [ adopted
> > > > > > > > extensions
> > ].
> > > > > > > > Please take a look and discuss any concerns; we'll be
> > > > > > > > asking our ADs for such a modification (with appropriate
> > > > > > > > changes to the list of extensions adopted) once our Calls for
> Adoption complete.
> > > > > > > >
> > > > > > > > Cheers,
> > > > > > > >

---

From: David Schinazi <[email-masked]>
Date: Thu, 12 Dec 2019 12:50:32 -0800

In general, I'm very supportive of rechartering to allow these new
extensions.

I'd prefer to have the charter just allow all extensions, and then use the
WG call for adoption consensus process to decide whether extensions are
in-scope at a given moment in time or not. But if the chairs/ADs think that
is too broad I can live with only opening up for specific topics.

One important problem though, is in the DATAGRAM case, the topic of flow
identifiers. Earlier, draft-pauly-quic-datagram-03 contained flow
identifiers. Based on community feedback, the authors removed them from
-04, and moved them to a separate draft-schinazi-quic-h3-datagram. I'll
admit that draft-schinazi-quic-h3-datagram is still very immature, but with
the new charter, I want to make sure we don't end up in a state where we
can discuss draft-pauly-quic-datagram but
not draft-schinazi-quic-h3-datagram. Some folks feel strongly that flow
identifiers should exist, and if we tell them that they're not in scope of
the WG they might be sad.

Because of this, I think the new charter should discuss topics as opposed
to specific draft names (which is what I assume Mark meant by [ adopted
extensions ] )

David

On Thu, Dec 12, 2019 at 8:15 AM Lubashev, Igor <[email-masked]> wrote:

> Mark,
>
> Speaking of lossbits, the work has been discussed at several meetings and
> there was a significant show of willingness of work on lossbits at the mic
> line in Singapore, on the condition that the work is (a) a negotiated
> extension, (b) the use of the bits is strictly specified, and (c) it is not
> blocking for QUIC v1.
>
> We were planning to present the draft of lossbits as a negotiated
> extension in Zurich, but given that the time for the inclusion in the
> Charter is now, we can get the draft out next week.  Given the prior
> discussion and expressed willingness of at least a part of the WG to work
> on this, would you include that extension draft in the WG adoption call
> prior to the charter update?  (As usual, adoption != publication, which is
> subject to the deliberations of the WG, including a positive
> privacy/security analysis.)
>
> - Igor
>
>

---

From: Mark Nottingham <[email-masked]>
Date: Fri, 13 Dec 2019 10:16:45 +1100

Hello Igor,

> On 13 Dec 2019, at 3:14 am, Lubashev, Igor <[email-masked]> wrote:
> 
> Mark,
> 

Yes, with the proviso that the willingness shown in Singapore was to do a privacy and security evaluation of the draft.

> We were planning to present the draft of lossbits as a negotiated extension in Zurich, but given that the time for the inclusion in the Charter is now, we can get the draft out next week.  Given th…

If we performed a Call for Adoption now, I strongly suspect it would fail, because the privacy and security evaluation hasn't been performed; we went through the same process for the spin bit.

Please don't think that just because we're talking about adopting a few extensions now, it somehow makes it easier to adopt others at the same time. 

Cheers,

---

From: Mark Nottingham <[email-masked]>
Date: Fri, 13 Dec 2019 10:19:05 +1100

> On 13 Dec 2019, at 7:50 am, David Schinazi <[email-masked]> wrote:
> 
> In general, I'm very supportive of rechartering to allow these new extensions.
> 
> I'd prefer to have the charter just allow all extensions, and then use the WG call for adoption consensus process to decide whether extensions are in-scope at a given moment in time or not. But if the chairs/ADs think that is too broad I can live with only opening up for specific topics.
> 
> One important problem though, is in the DATAGRAM case, the topic of flow identifiers. Earlier, draft-pauly-quic-datagram-03 contained flow identifiers. Based on community feedback, the authors removed them from -04, and moved them to a separate draft-schinazi-quic-h3-datagram. I'll admit that draft-schinazi-quic-h3-datagram is still very immature, but with the new charter, I want to make sure we don't end up in a state where we can discuss draft-pauly-quic-datagram but not draft-schinazi-quic-h3-datagram. Some folks feel strongly that flow identifiers should exist, and if we tell them that they're not in scope of the WG they might be sad.

It's good to know about these requirements, and of course once the document is adopted, we can discuss issues against it. However, if you want to discuss datagrams in HTTP/3, we need to have a discussion about whether it'd be more appropriate to do that in this WG or in the HTTP WG -- remembering that once HTTP/3 ships, it takes over maintenance of that spec.

Cheers,

> 
> Because of this, I think the new charter should discuss topics as opposed to specific draft names (which is what I assume Mark meant by [ adopted extensions ] )
> 
> David
>

---

From: David Schinazi <[email-masked]>
Date: Thu, 12 Dec 2019 16:10:32 -0800

On Thu, Dec 12, 2019 at 3:19 PM Mark Nottingham <[email-masked]> wrote:

> > I'd prefer to have the charter just allow all extensions, and then use
> the WG call for adoption consensus process to decide whether extensions are
> can discuss draft-pauly-quic-datagram but not
> draft-schinazi-quic-h3-datagram. Some folks feel strongly that flow
> It's good to know about these requirements, and of course once the
> document is adopted, we can discuss issues against it. However, if you want
> to discuss datagrams in HTTP/3, we need to have a discussion about whether
> it'd be more appropriate to do that in this WG or in the HTTP WG --
> remembering that once HTTP/3 ships, it takes over maintenance of that spec.
>

Thanks, that makes sense to me. Happy to take
draft-schinazi-quic-h3-datagram to HTTPBIS (or will it be HTTPTER ?). Just
wanted to make sure that discussing it in context
of draft-pauly-quic-datagram is OK.

David

Cheers,
>
> >
> > Because of this, I think the new charter should discuss topics as
> opposed to specific draft names (which is what I assume Mark meant by [
> adopted extensions ] )
> >
> > David
> >
> > Speaking of lossbits, the work has been discussed at several meetings
> and there was a significant show of willingness of work on lossbits at the
> mic line in Singapore, on the condition that the work is (a) a negotiated

---

From: Olivier Bonaventure <[email-masked]>
Date: Fri, 13 Dec 2019 19:05:50 +0100

Mark, Lars,

> On 11 Dec 2019, at 22:38, Mark Nottingham <[email-masked]> wrote:
> 

The QUIC charter mentioned a fourth focus on multipath :

"The fourth focus area will extend core protocol facilities to enable 
multipath capabilities for connection migration between paths and load 
sharing across multiple paths.”

I was wondering when the working group plans to start working on this focus area that is part of the charter. As the working group focused on v1, we did not request any presentation slot for draft-deconinck-quic-multipath, but this draft has been updated several times to reflect the evolution of the other QUIC drafts.

According to the charter, the following milestones were defined for multipath :

May 2020	Multipath extension document to IESG
Dec 2019	        Working group adoption of Multipath extension document

Do you have any specific plans for the multipath work ?

Best regards,

Olivier Bonaventure
-- 

Disclaimer: https://www.tessares.net/mail-disclaimer/ 
<https://www.tessares.net/mail-disclaimer/>

---

From: "Roni Even (A)" <[email-masked]>
Date: Sun, 15 Dec 2019 07:53:36 +0000

Hi Mark,
Here is when I see the difference between charter and creating a milestone and adoption. I do not think that we need to adopt the loss bit work now but it should be in the charter so it can be discussed without getting voices that it is not in the charter. Adoption and milestone can happen later. 
This is my general comment about not having specific extensions in the charter but have general statement about extension and let the WG decide if the work should be in QUIC and if to set a milestone.

Roni Even

> Sent: Friday, December 13, 2019 1:17 AM
> To: Lubashev, Igor
> Cc: Roni Even (A); Magnus Westerlund; Lars Eggert; [email-masked]
> there was a significant show of willingness of work on lossbits at the mic line
> in Singapore, on the condition that the work is (a) a negotiated extension, (b)
> the use of the bits is strictly specified, and (c) it is not blocking for QUIC v1.
> 
> Yes, with the proviso that the willingness shown in Singapore was to do a
> privacy and security evaluation of the draft.
> 
> > discussion and expressed willingness of at least a part of the WG to
> > work on this, would you include that extension draft in the WG
> > adoption call prior to the charter update?  (As usual, adoption !=
> > publication, which is subject to the deliberations of the WG,
> > including a positive privacy/security analysis.)
> 
> If we performed a Call for Adoption now, I strongly suspect it would fail,
> because the privacy and security evaluation hasn't been performed; we
> went through the same process for the spin bit.
> 
> Please don't think that just because we're talking about adopting a few
> extensions now, it somehow makes it easier to adopt others at the same
> time.
> 
> Cheers,
> 
> 
> >
> > - Igor
> >
> >
> >> This clarifies the proposed charter and the priority of the V1
> >> document  but as for future extensions the text from the meeting
> >> notes says
> >>
> >> "Mnot: If you do think you have an extension which is generic enough,
> >> we will reserve time for it during the quiet for disucssion on the
> >> list. For this, we will need a charter change for that, but we've
> >> been talking to the ADs about that, and we'll put a proposal out for
> comment."
> >>
> >> How is this reflected in the charter, which extensions will be
> >> considered "generic enough" and appear by name in it. There are three
> >> extensions for adoption and they look generic enough more (version
> negotiation,
> >> the related I-Ds that are "generic enough". The problem in my view is
> >> that if all these drafts are not in the proposed charter, they cannot
> >> be discussed at all during the "quiet" .  I would prefer to allow in
> >> the charter and decide if to create a milestone.
> >>
> >> Roni
> >>
> >>> I want to give my input as AD into this process. We are
> >>> intentionally keeping this rechartering very narrow in scope and do
> >>> not intended to open up for general extension adoption in the WG at
> >>> this moment. The extensions currently on call for adoption is
> >>> selected set which appears important, tractable and with clear
> >>> scope. However, the primary focus will remain on finishing the core
> >>> specification of version 1 of QUIC. The chairs have my full
> >>> confidence in managing the process and are communicating with us ADs
> regularly.
> >>>
> >>> discussion like a QUIC dispatch session. However, as v1 finish we
> >>> will take a new look at the QUIC WG charter and do a more thourgh
> >>> recharter at that stage. That discussion will then happen in the
> >>> context of the discussion that will have occurred between now and
> >>> then. However, starting v2, how to handle both bigger and smaller
> >>> extensions to the protocol and any additional guidance documents
> >>> needed will clearly need changes to the charter.
> >>>
> >>>> This is like a new call for adoption process, instead for asking
> >>>> for adoption the question will be call for re-charter.
> >>>>
> >>>> Roni
> >>>>
> >>>>
> >>>>>> Sorry for sounding like someone whose focus is on the process and
> >>>>>> not
> >>> the
> >>>>>
> >>>>> content.
> >>>>>>
> >>>>>> Roni
> >>>>>>
> >>>>>>>>> negotiation and use of Forward Error Correction schemes, are
> >>>>>>>>> out of scope in this version of the working group charter.
> >>>>>>>>> """
> >>>>>>>>>
> >>>>>>>>> *If* we do decide we'd like to adopt, we'll need to update it
> >>>>>>>>> to something
> >>>>>>>>> like:
> >>>>>>>>>
> >>>>>>>>> """
> >>>>>>>>> Please take a look and discuss any concerns; we'll be asking
> >>>>>>>>> our ADs for such a modification (with appropriate changes to
> >>>>>>>>> the list of extensions adopted) once our Calls for
> >> Adoption complete.
> >>>>>>>>>
> >>>>>>>>> Cheers,
> >>>>>>>>>

---

From: Lars Eggert <[email-masked]>
Date: Mon, 16 Dec 2019 09:09:37 +0200

> Regarding milestones - yes, we'll do that when the rest of the changes go through. Thanks for the reminder.

FWIW, we didn't update the milestones because were were told in the past that the IESG was debating to do away with them (for all WGs). I haven't heard more about this recently, however.

Lars

---

From: Lars Eggert <[email-masked]>
Date: Mon, 16 Dec 2019 09:18:52 +0200

Hi,

> Do you have any specific plans for the multipath work ?

thanks for reminding us about that! There is of course no intention of dropping the multipath work item from the charter. It's already in the charter and will remain there, so it's not affected by this rechartering.

(One could call multipath an extension and mention it alongside the others in the modification that Mark posted in the first message of this thread. Personally, I see it as a much more fundamental - and difficult - update to the base protocol, and therefore would keep it highlighted in the way it currently is in the charter.)

I think we'll be ready to start having discussions on multipath in parallel to working on these new extensions; I do expect the multipath work to progress at a slower pace, however. While we don't have to start at zero thanks to MPTCP, hard challenges remain (e.g., when pooling capacity, can we do it in a way that doesn't leave us operating near the max. RTT of the paths?)

Lars

---

From: Olivier Bonaventure <[email-masked]>
Date: Mon, 16 Dec 2019 13:13:32 +0100

Lars,

> I think we'll be ready to start having discussions on multipath in parallel to working on these new extensions; I do expect the multipath work to progress at a slower pace, however. While we don't have to start at zero thanks to MPTCP, 

We can leverage many of the lessons learned from the design and the deployment of Multipath TCP into MPQUIC. 

When Multipath TCP started, multipath congestion control was a challenge, this problem has been solved with different coupled congestion control schemes. 

With Multipath TCP, we had to struggle a lot with middleboxes and how they interfere with TCP and Multipath TCP. QUIC avoids these problems and makes the design more simple and more flexible. There are many problems that exist in MPTCP that disappear in MPQUIC. For example, in MPTCP, data sent over a subflow must still be retransmitted over this subflow even if it has already been acknowledged over another subflow at the data level. With MPQUIC, once data has been acknowledged on a path, it never needs to be retransmitted again. Another example are the selective acknowledgements. In TCP, the length of the (MP)TCP header restrict the number of blocks that they cover. In MPQUIC, we do not need to deal with this problem...

> hard challenges remain (e.g., when pooling capacity, can we do it in a way that doesn't leave us operating near the max. RTT of the paths?)

With MPQUIC, we are not as constrained as with MPTCP for the transmission of acknowledgements. This means that when pooling capacity it is possible to send acknowledgements on a different path than the one used for the data. This would be difficult in an MPTCP implementation but is easy in MPQUIC. 

As QUICv1 is now getting stable, it makes sense for the working group to adopt an initial design for multipath QUIC and then improve it.

Olivier

--

---

From: Mikkel Fahnøe Jørgensen <[email-masked]>
Date: Mon, 16 Dec 2019 10:42:23 -0500

ACK across paths could lead to privacy leaks, no?

Mikkel

On 16 December 2019 at 13.13.47, Olivier Bonaventure (
[email-masked]) wrote:

Lars,

> thanks for reminding us about that! There is of course no intention of
dropping the multipath work item from the charter. It's already in the
charter and will remain there, so it's not affected by this rechartering.
>
> (One could call multipath an extension and mention it alongside the
others in the modification that Mark posted in the first message of this
thread. Personally, I see it as a much more fundamental - and difficult -
update to the base protocol, and therefore would keep it highlighted in the
way it currently is in the charter.)
>
> I think we'll be ready to start having discussions on multipath in
parallel to working on these new extensions; I do expect the multipath work
to progress at a slower pace, however. While we don't have to start at zero
thanks to MPTCP,

We can leverage many of the lessons learned from the design and the
deployment of Multipath TCP into MPQUIC.

When Multipath TCP started, multipath congestion control was a challenge,
this problem has been solved with different coupled congestion control
schemes.

With Multipath TCP, we had to struggle a lot with middleboxes and how they
interfere with TCP and Multipath TCP. QUIC avoids these problems and makes
the design more simple and more flexible. There are many problems that
exist in MPTCP that disappear in MPQUIC. For example, in MPTCP, data sent
over a subflow must still be retransmitted over this subflow even if it has
already been acknowledged over another subflow at the data level. With
MPQUIC, once data has been acknowledged on a path, it never needs to be
retransmitted again. Another example are the selective acknowledgements. In
TCP, the length of the (MP)TCP header restrict the number of blocks that
they cover. In MPQUIC, we do not need to deal with this problem...

> hard challenges remain (e.g., when pooling capacity, can we do it in a
way that doesn't leave us operating near the max. RTT of the paths?)

With MPQUIC, we are not as constrained as with MPTCP for the transmission
of acknowledgements. This means that when pooling capacity it is possible
to send acknowledgements on a different path than the one used for the
data. This would be difficult in an MPTCP implementation but is easy in
MPQUIC.

As QUICv1 is now getting stable, it makes sense for the working group to
adopt an initial design for multipath QUIC and then improve it.

Olivier

--

---

From: Olivier Bonaventure <[email-masked]>
Date: Mon, 16 Dec 2019 18:29:26 +0100

Mikkel,

> On 16 Dec 2019, at 16:42, Mikkel Fahnøe Jørgensen <[email-masked]> wrote:
> 

Since all QUIC packets are encrypted, a passive observer cannot easily determine that acks are exchanged over a specific path. If the size of the acks is a concern, then it is possible to pad QUIC frames to hide the fact that such acks are exchanged.

Olivier

--

---

From: Mikkel Fahnøe Jørgensen <[email-masked]>
Date: Mon, 16 Dec 2019 14:20:17 -0500

If you can observe encrypted traffic on both paths you have an opportunity
to correlate traffic if an endpoint consistently acks on one path and sends
on another. On path has small packets a fixed interval after larger packets
on the other paths. That could happen in a migration scenario where one
path is not yet fully committed so ACKs stay on the main path.

I don’t recall how it works today with single path migration, but I think
that it is required that ACKs happen on the same path as the packets on
which they are sent.

Mikkel

On 16 December 2019 at 18.29.29, Olivier Bonaventure (
[email-masked]) wrote:

Mikkel,

On 16 Dec 2019, at 16:42, Mikkel Fahnøe Jørgensen <[email-masked]>
wrote:

Since all QUIC packets are encrypted, a passive observer cannot easily
determine that acks are exchanged over a specific path. If the size of the
acks is a concern, then it is possible to pad QUIC frames to hide the fact
that such acks are exchanged.

Olivier

------------------------------

---

From: Christian Huitema <[email-masked]>
Date: Mon, 16 Dec 2019 10:52:35 -1000

On 12/16/2019 9:20 AM, Mikkel Fahnøe Jørgensen wrote:
> If you can observe encrypted traffic on both paths you have an
> opportunity to correlate traffic if an endpoint consistently acks on
> one path and sends on another. On path has small packets a fixed
> interval after larger packets on the other paths. That could happen in
> a migration scenario where one path is not yet fully committed so ACKs
> stay on the main path.
>
> I don’t recall how it works today with single path migration, but I
> think that it is required that ACKs happen on the same path as the
> packets on which they are sent.

No, that's not required. In fact it cannot be required, because one of
the scenarios is "transmit some data on path X, then migrate to path Y".
If you don't ack on path Y for packets sent on path X, you end up having
to repeat these packets on path Y.

But your general point is correct, Mikkel. If application traffic is
spread over multiple paths, it is probably hard to hide the correlation
between these multiple paths. Not necessarily impossible, but if this is
a goal we have better design for it.

-- Christian Huitema

---

From: Mike Bishop <[email-masked]>
Date: Tue, 17 Dec 2019 17:11:36 +0000

I think I would approach this a little differently.  I understand the desire for caution about letting extensions derail the core documents, but I'm hesitant to require another recharter to adopt more extensions.  Perhaps we could consider something more like HTTP/2 did, permitting us to work on extensions only to the extent that they don't delay our work on the core documents.  Or explicitly list the extensions we're allowed to adopt before RFC publication.

I understand the current plan is for two recharters, and maybe they're lightweight enough that that's fine.  I'm just unenthusiastic about having to agree on the exact set of extensions we're allowed to discuss before we can formally discuss any of them.

-----Original Message-----
From: QUIC <[email-masked]> On Behalf Of Mark Nottingham
Sent: Thursday, December 12, 2019 1:58 AM
To: Jana Iyengar <[email-masked]>
Cc: Lars Eggert <[email-masked]>; IETF QUIC WG <[email-masked]>
Subject: Re: Re-chartering for extension work

Cheers,

---

From: Kuhn Nicolas <[email-masked]>
Date: Tue, 17 Dec 2019 17:27:49 +0000

Hi Mark, Lars,

Many meetings discussed the impacts of QUIC encryption on satellite Performance-enhancing proxy (PEP) and the benefit of exchanging additional transport parameters.
draft-kuhn-quic-0rtt-bdp was mentioned as a possible extension during « Quick QUIC Update » presentation.

We have updated draft-kuhn-quic-0rtt-bdp-05 as an extension of QUIC.
We propose to include it in the re-chartering discussion.

Regards,
Nicolas, Emile and Gorry

https://datatracker.ietf.org/meeting/106/materials/slides-106-tsvarea-quick-quic-update-mark-nottingham-00.pdf 
https://tools.ietf.org/html/draft-kuhn-quic-0rtt-bdp-05 

-----Message d'origine-----
De : QUIC <[email-masked]> De la part de Mark Nottingham
Envoyé : mercredi 11 décembre 2019 22:38
À : IETF QUIC WG <[email-masked]>
Cc : Lars Eggert <[email-masked]>
Objet : Re-chartering for extension work

"""

"""

Cheers,

---

From: Ian Swett <[email-masked]>
Date: Tue, 17 Dec 2019 12:37:07 -0500

I think the satellite use case is an important one, but I have a number of
concerns with the approach in that draft, so I don't believe it's ready for
adoption.

On Tue, Dec 17, 2019 at 12:29 PM Kuhn Nicolas <[email-masked]> wrote:

> Hi Mark, Lars,
>
> Many meetings discussed the impacts of QUIC encryption on satellite
> Performance-enhancing proxy (PEP) and the benefit of exchanging additional
> transport parameters.

---

From: Christian Huitema <[email-masked]>
Date: Tue, 17 Dec 2019 09:48:47 -1000

The 0RTT draft is a simple extension defining new transport parameters.
It is a fine draft, but it is only part of the solution, and I don't
know whether we need to engage the charter extension process just for
that. IMHO if we start adopting "satellite" work in QUIC, we should
start by the problem statement rather than the proposed solution.
Nicolas, you have a draft in progress defining "satellite scenarios". I
think that would be a very good starting point.

I am half way through the work to make the picoquic implementation work
well on satellite, and I found the scenario definitions very useful. I
did find the issue mentioned by you, Emile, John and Gorry in your
presentations, but I also found a bunch of other ones. The high BDP
tests stress parts of the code that are not exercised in the other
scenarios, such as reordering out of sequence arrival of frame data in a
very long list of buffers, managing ACK-of-ACK when the SACK list is
long and full of holes, or performing spurious loss detection when the
list of repeated packets is much longer than usual. These are of course
purely implementation issues. Of course, other implementations may or
may not have these specific issues. Maybe they will find different
issues. But the point remains that having a good set of well defined
tests will advance support for the satellite scenarios.

Another issue that I found was dealing with high variance of RTT
measurements induced by asymmetry between the upload and download
capacity. Gorry presented the issue in terms of "load on the ACK path"
and suggested reducing the ACK rate, which should definitely be part of
the recommended solution. But this is not just a load issue, it also
impacts RTT measurements which in turn impact a variety of algorithms --
especially if the implementation relies on delay based congestion
control to be robust in the presence of random packet losses. I dealt
with the RTT measurement issue by defining a one way delay measurement
extension, which has other usages than satellite and might also be a
candidate for WG adoption -- once I manage to actually write it in a
draft of course. There may be more work required to deal with the asymmetry.

-- Christian Huitema

On 12/17/2019 7:37 AM, Ian Swett wrote:
> I think the satellite use case is an important one, but I have a
> number of concerns with the approach in that draft, so I don't believe
> it's ready for adoption.
>
> On Tue, Dec 17, 2019 at 12:29 PM Kuhn Nicolas <[email-masked]
> <mailto:[email-masked]>> wrote:
>
>     Hi Mark, Lars,
>
>     Many meetings discussed the impacts of QUIC encryption on
>     satellite Performance-enhancing proxy (PEP) and the benefit of
>     exchanging additional transport parameters.
>     draft-kuhn-quic-0rtt-bdp was mentioned as a possible extension
>     during « Quick QUIC Update » presentation.
>
>     De : QUIC <[email-masked] <mailto:[email-masked]>>
>     De la part de Mark Nottingham
>     À : IETF QUIC WG <[email-masked] <mailto:[email-masked]>>
>     Cc : Lars Eggert <[email-masked] <mailto:[email-masked]>>
>     extensions. The specific text in question is:
>
>     """
>     something like:
>     Additionally, the Working Group will deliver [ adopted extensions
>     ]. The Working Group may consider other extension work, but
>     adopting further extensions requires updating this charter.
>     """
>
> _______________________________________________
> EToSat mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/etosat

---

From: Jana Iyengar <[email-masked]>
Date: Tue, 17 Dec 2019 22:26:10 -0800

I'm not sure that this is the time for this conversation, but I'll share my
thoughts since the question has been raised.

There will be quite some heavy lifting to do if we go down the path of
designing a multipath extension for QUIC. We've seen this before. I worked
on multipath for SCTP, which was quite some work. I remember when we
started work on MPTCP at the IETF in 2009, and it was a lot more effort
than most people anticipated. When we started work on connection migration
for QUIC, we thought it might get done relatively quickly, but it was a
feature that kept on giving.

None of this is to say that we shouldn't take on a hard problem, but before
we start sliding into it, I would like to be convinced of its importance.
We already have connection migration in the core drafts, and I'd like to
see an articulation of the problems that multipath would solve in addition
to basic migration. I would also like to see implementations that are keen
to build it if an extension were to be developed, and applications that
will use it. Without those, we would be putting the cart before the horse.

- jana

On Mon, Dec 16, 2019 at 12:52 PM Christian Huitema <[email-masked]>
wrote:

> No, that's not required. In fact it cannot be required, because one of the
> scenarios is "transmit some data on path X, then migrate to path Y". If you
> don't ack on path Y for packets sent on path X, you end up having to repeat
> these packets on path Y.
>
> between these multiple paths. Not necessarily impossible, but if this is a
> goal we have better design for it.
>
> -- Christian Huitema
>

---

From: Lars Eggert <[email-masked]>
Date: Wed, 18 Dec 2019 08:32:40 +0200

Hi,

> We propose to include it in the re-chartering discussion.

all the extensions included in the recharter we are discussing here have been reviewed by the WG and are actually under adoption at the moment.

I agree that the satellite use case is important, but neither the problem nor the proposed solution is at the same stage, so I wouldn't want to include it in the current recharter.

(Same goes for pretty much *any* other extension, FWIW.)

Lars

---

From: Magnus Westerlund <[email-masked]>
Date: Wed, 18 Dec 2019 09:54:18 +0000

Hi Mike, 

So an important aspect of rechartering is to actually make the rest of the IETF
aware of the changes in what the WG is working on. For a WG that is as high
profile as QUIC the changes in scope do matter well beyond those that will
bother to actively read the mailing list. Therefore a recharter lets these
people to be aware of the changes. 

In addition, from my perspective the WG chairs have the freedom to schedule
discussion of potential future extension in the meetings as well as having
discussion on the mailing list. However adopting them as WG items will require a
recharter. 

A reason for the two step rechartering is that I think we will need to have a
serious discussion of how to work on v2 and extensions more generally. I think
going into these details now is premature. But we will need to come back to this
later. 

Cheers

Magnus Westerlund
TSV AD

On Tue, 2019-12-17 at 17:11 +0000, Mike Bishop wrote:
> I think I would approach this a little differently.  I understand the desire
> for caution about letting extensions derail the core documents, but I'm
> hesitant to require another recharter to adopt more extensions.  Perhaps we
> could consider something more like HTTP/2 did, permitting us to work on
> extensions only to the extent that they don't delay our work on the core
> documents.  Or explicitly list the extensions we're allowed to adopt before
> RFC publication.
> 
> I understand the current plan is for two recharters, and maybe they're
> lightweight enough that that's fine.  I'm just unenthusiastic about having to
> agree on the exact set of extensions we're allowed to discuss before we can
> formally discuss any of them.
> 
> > proposed language, we couldn't have adopted this extension since it wouldn't
> > have been on a list of extensions. The rest of the charter talks about focus
> > areas, not about specific documents and extensibility mechanisms. The
> > proposed text lists extensions, which means that any extensions, even minor
> > ones, will require a recharter. This is a tightening of the charter, which I
> > support.
> > 
> That's the intent, yes; while eventually we might open up, we want to be
> deliberate about adding new work items while we're still focused on QUICv1.
> 
> Cheers,
> 
> 
> > 
> > - jana
> > 
> > believe that the group has some capacity to discuss them as it finishes work
> > on the core protocol.
> > 
> > https://protect2.fireeye.com/v1/url?k=f85c6569-a4886937-f85c25f2-8691959ed9b7-69b8740865eddccb&q=1&e=7516b3d9-fa19-4a17-ade3-86747f2949d2&u=https%3A%2F%2Fwww.mnot.net%2F
> > 
> 
> --
> Mark Nottingham   
> https://protect2.fireeye.com/v1/url?k=410fda54-1ddbd60a-410f9acf-8691959ed9b7-8547d07a1f3546f1&q=1&e=7516b3d9-fa19-4a17-ade3-86747f2949d2&u=https%3A%2F%2Fwww.mnot.net%2F
> 
-- 
Cheers

Magnus Westerlund

---

From: Magnus Westerlund <[email-masked]>
Date: Wed, 18 Dec 2019 14:49:03 +0000

Hi Igor and Roni,

The three work items being proposed for adoption and recharter are seen as
highly relevant, constrained, and likely to make good progress and have limited
impact on the v1 work. I think the call for adoption is good indicator of  the
support for these items.  

The Loss bits even if there is significant interest in them I don't expect to
make rapid progress and likely to require much discussion. Those the potential
for causing impact on the v1 work is significant even if it is not a direct
dependency. That alone is enough from my perspective to not include this in this
step of adopting things. 

It is good that you continue to work on it and progress important aspects, like
privacy and security considerations. 

Hope that clarifies the reasoning. 

Cheers

Magnus

On Thu, 2019-12-12 at 16:14 +0000, Lubashev, Igor wrote:
> We were planning to present the draft of lossbits as a negotiated extension in
> Zurich, but given that the time for the inclusion in the Charter is now, we
> can get the draft out next week.  Given the prior discussion and expressed
> willingness of at least a part of the WG to work on this, would you include
> that extension draft in the WG adoption call prior to the charter update?  (As
> usual, adoption != publication, which is subject to the deliberations of the
> WG, including a positive privacy/security analysis.)
> 
> - Igor
> 
> 
> > > > propose to the authors to take it to a named WG ( probably need
> > > 
> > > recommendation
> > > > " The Working Group may consider other extension work, but adopting
> > > 
> > > further
> > > > > > > > On 12 Dec 2019, at 5:49 pm, Roni Even (A)
> > > 
> > > <[email-masked]>
> > > > > > > 
> > > > > > > wrote:
> > > > > > > > 
> > > > > > > > Hi Mark,
> > > > > > > discussion about specific ones would be about creating a new
> > > 
> > > milestone..
> > > > > > > > 
> > > > > > > > > The Working Group may consider other extension work, but
> > > 
> > > adopting
-- 
Cheers

Magnus Westerlund

---

From: Florin Baboescu <[email-masked]>
Date: Wed, 18 Dec 2019 09:55:28 -0800

Dear all,

I would like to support Olivier’s request that “as QUICv1 is now getting
stable, it makes sense for the working group to adopt an initial design for
multipath QUIC and then improve it”.

While it is easy to agree with Jana’s comment that “There will be quite
some heavy lifting to do if we go down the path of designing a multipath
extension for QUIC” one can definitely not ignore 1) the experience gained
through the MPTCP work as well as 2) the fact that QUIC simplifies the
design and makes it more flexible than in the case of MPTCP.

With regard to Jana’s comment that “I would also like to see
implementations that are keen to build it if an extension were to be
developed, and applications that will use it” I would like to point out the
followings:

1.       In 3GPP Release 16, MPTCP has been adopted as a solution for
Access Traffic Steering, Switching and Splitting(ATSSS) support in the 5G
System architecture.

2.       In 3GPP Release 17 (to be completed by December 2020) a large
number of companies would like to be able to complement the solutions
adopted in Release 16 with a MPQUIC based solution if available. These
companies represent handset vendors, operators and network vendors.

This is why it is easy to say that we do see a very strong need and
interest in this work and we would like to support it.

Thank you.

-Florin

*From:* QUIC [mailto:[email-masked]] *On Behalf Of *Jana Iyengar
*Sent:* Tuesday, December 17, 2019 10:26 PM
*To:* Christian Huitema <[email-masked]>
*Cc:* Olivier Bonaventure <[email-masked]>; Quentin De
Coninck <[email-masked]>; Mark Nottingham <[email-masked]>;
Lars Eggert <[email-masked]>; Mikkel Fahnøe Jørgensen <[email-masked]>;
IETF QUIC WG <[email-masked]>
*Subject:* Re: Multipath (was: Re: Re-chartering for extension work)

- jana

But your general point is correct, Mikkel. If application traffic is spread
over multiple paths, it is probably hard to hide the correlation between
these multiple paths. Not necessarily impossible, but if this is a goal we
have better design for it.

-- Christian Huitema

---

From: Olivier Bonaventure <[email-masked]>
Date: Wed, 18 Dec 2019 19:39:56 +0100

Jana,

> On 18 Dec 2019, at 07:26, Jana Iyengar <[email-masked]> wrote:
> 
> 
> I'm not sure that this is the time for this conversation, but I'll share my thoughts since the question has been raised.
> 
> There will be quite some heavy lifting to do if we go down the path of designing a multipath extension for QUIC. We've seen this before. I worked on multipath for SCTP, which was quite some work. I remember when we started work on MPTCP at the IETF in 2009, and it was a lot more effort than most people anticipated. When we started work on connection migration for QUIC, we thought it might get done relatively quickly, but it was a feature that kept on giving.

For Multipath TCP, I would argue that most of the difficulty was caused by middleboxes.
> 
> None of this is to say that we shouldn't take on a hard problem, but before we start sliding into it, I would like to be convinced of its importance. We already have connection migration in the core drafts, and I'd like to see an articulation of the problems that multipath would solve in addition to basic migration. I would also like to see implementations that are keen to build it if an extension were to be developed, and applications that will use it. Without those, we would be putting the cart before the horse.
> 

I think that there are two clear use cases for a multipath transport. The first use case is ressource pooling as already mentioned by Lars. There are various situations where being able to use different paths simultaneously gives improved performance, in terms of delay or throughput. A common scenario is a dual-stack IPv4/IPv6 client that interacts with a dual-stack server through paths of different qualities. 

A second use case is for mobile devices that need to preserve connectivity while switching from one wireless network to another. When such a device detects another wireless network, it needs to bet whether migrating the connection to the new network would improve performance. With a multipath transport, there is no need to bet as the transport will automatically select the best performing network. Apple’s deployment of Multipath TCP is a good example of the benefits of such a multipath strategy.

Multipath was included in the QUIC charter to address such use cases.

Olivier

--

---

From: "Roni Even (A)" <[email-masked]>
Date: Wed, 18 Dec 2019 19:33:54 +0000

Magnus,
I am confused, I was not asking for adoption of the work but to have it in the charter so it can be discussed on the list and worked upon without being contested as non-chartered work. This is at least my understanding about the difference between the charter and adoption

Roni

> Sent: Wednesday, December 18, 2019 4:49 PM
> To: Roni Even (A); [email-masked]; [email-masked]
> we
> that
> > > if

---

From: Ryan Hamilton <[email-masked]>
Date: Wed, 18 Dec 2019 14:42:53 -0800

On Wed, Dec 18, 2019 at 10:40 AM Olivier Bonaventure <
[email-masked]> wrote:

> [snip]
>
> A second use case is for mobile devices that need to preserve connectivity
> while switching from one wireless network to another. When such a device
> detects another wireless network, it needs to bet whether migrating the
> connection to the new network would improve performance. With a multipath
> transport, there is no need to bet as the transport will automatically
> select the best performing network. Apple’s deployment of Multipath TCP is
> a good example of the benefits of such a multipath strategy.
>

FWIW, QUIC connection migration was designed to do explicitly this and has
been very successful in Google's deployment. I don't think this is a good
justification for multipath QUIC.

Cheers,

Ryan

---

From: "Lubashev, Igor" <[email-masked]>
Date: Wed, 18 Dec 2019 23:38:57 +0000

Magnus,

I support considering WG Charter as a "promise to IETF" as to the scope of work the group will and will not do.  As such, re-chartering frequently is the same as changing your promises frequently.  Not good.  If a re-charter is needed, I'd rather it be honest and complete and not to contain an expectation that there may be another re-charter "soon".

- Igor

P.S.
  When I hear that lossbits "likely to require much discussion" as a reason for exclusion from the charter, I am not sure about the criteria used here. Several of the about-to-do-adopted/in-the-proposed-charter works are likely to generate a significant discussion and a significant rework (more so for the loadbal work, less so for datagrams).  If the concern is about the limited group meeting time, chars indicated that they are very capable of managing meeting time productively.  (I'd note that the entire lossbits discussion in Singapore took less mic time than Retry checksum bikeshed(?), and a good number of people indicated willingness to work on lossbits, including to participate in privacy analysis.)

> From: Roni Even (A) <[email-masked]>
> 
> Magnus,
> I am confused, I was not asking for adoption of the work but to have it in the
> charter so it can be discussed on the list and worked upon without being
> contested as non-chartered work. This is at least my understanding about
> the difference between the charter and adoption
> 
> Roni
> 
> > The three work items being proposed for adoption and recharter are
> > seen as highly relevant, constrained, and likely to make good progress
> > and have limited impact on the v1 work. I think the call for adoption
> > is good indicator of  the support for these items.
> >
> > The Loss bits even if there is significant interest in them I don't
> > expect to make rapid progress and likely to require much discussion.
> > Those the potential for causing impact on the v1 work is significant
> > even if it is not a direct dependency. That alone is enough from my
> > perspective to not include this in this step of adopting things.
> >
> > It is good that you continue to work on it and progress important
> > aspects, like privacy and security considerations.
> >
> > > Speaking of lossbits, the work has been discussed at several
> > > meetings and there was a significant show of willingness of work on
> > > lossbits at the mic line in Singapore, on the condition that the
> > > work is (a) a negotiated extension, (b) the use of the bits is
> > > strictly specified, and (c) it is not blocking for QUIC v1.
> > >
> > > extension
> > in
> > > Zurich, but given that the time for the inclusion in the Charter is
> > > now, we can get the draft out next week.  Given the prior discussion
> > > and expressed willingness of at least a part of the WG to work on
> > > this, would you include that extension draft in the WG adoption call
> prior to the charter update?
> > (As
> > > usual, adoption != publication, which is subject to the
> > > deliberations of the WG, including a positive privacy/security
> > > analysis.)
> > >
> > > - Igor
> > >
> > >
> > > > will reserve time for it during the quiet for disucssion on the
> > > > been talking to the ADs
> > about
> > > > considered "generic enough" and appear by name in it. There are
> > > > three extensions
> > for
> > > > all these drafts are not in the proposed charter, they cannot be
> > > > discussed at all during the "quiet" .  I would prefer to allow in
> > > > > intentionally keeping this rechartering very narrow in scope and
> > > > > do not intended to open up for general extension adoption in the
> > > > > WG at this moment. The extensions currently on call for adoption
> > > > > is selected set which appears important, tractable and with
> > > > > clear scope. However, the primary focus will remain on finishing
> > > > > the core specification of version 1 of QUIC. The chairs have my
> > > > > full confidence in managing the process and are communicating with
> us ADs regularly.
> > > > >
> > > > > As Mark stated before discussion of future extensions can occurr
> > > > > if time permits, we will also consider other ways of enabling
> > > > > the discussion like a QUIC dispatch session. However, as v1
> > > > > finish we will take a new look at the QUIC WG charter and do a
> > > > > more thourgh
> > recharter
> > > > > at that stage. That discussion will then happen in the context
> > > > > of the discussion that will have occurred between now and then.
> > > > > However, starting v2, how to handle both bigger and smaller
> > > > > > 19 individual drafts in QUIC. I am not sure that all of them
> > > > > > should be
> > > > >
> > > > > adopted
> > > > > > as chartered work in QUIC. My view is that the WG should at
> > > > > > least say so
> > > > >
> > > > > and
> > > > > > from the Ads) instead of keeping them alive in the QUIC as
> > > > > > related
> > IDs.
> > > > > > Currently the authors can ask to add these documents to the
> > > > > > charter based
> > > > >
> > > > > on
> > > > > > This is like a new call for adoption process, instead for
> > > > > > asking for adoption the question will be call for re-charter.
> > > > > >
> > > > > > Roni
> > > > > >
> > > > > >
> > > > > > > but I think that adding specific extensions can be discussed
> > > > > > > by asking the WG to create a new milestone. Yet I understand
> > > > > > > that the charter should be
> > > > >
> > > > > clear
> > > > > > > about what is in scope for the WG. I think that maybe the
> > > > > > > charter should also say that the WG can direct proposal for
> > > > > > > new work to another WG (sort of dispatch for QUIC).
> > > > > > >
> > > > > > > > One other thing, I think that when asking for adoption of
> > > > > > > > a document
> > > > >
> > > > > you
> > > > > > >
> > > > > > > are asking to create a milestone and adopt the document as
> > > > > > > the initial document to address the milestone.
> > > > > > > > Sorry for sounding like someone whose focus is on the
> > > > > > > > process and not
> > > > >
> > > > > the
> > > > > > >
> > > > > > > content.
> > > > > > > >
> > > > > > > > Roni
> > > > > > > >
> > > > > > > > > Regarding milestones - yes, we'll do that when the rest
> > > > > > > > > of the changes go through. Thanks for the reminder.
> > > > > > > > >
> > > > > > > > > Cheers,
> > > > > > > > >
> > > > > > > > >
> > > > > > > > > the extension work in the charter should be general and
> > > > > > > > > the discussion about specific ones would be about
> > > > > > > > > creating a new
> > > > >
> > > > > milestone..
> > > > > > > > > >
> > > > > > > > > > > We've just put out Calls for Adoption for extensions
> > > > > > > > > > > to QUICv1, as we believe that the group has some
> > > > > > > > > > > capacity to discuss them as it finishes work on the core
> protocol.
> > > > > > > > > > >
> > > > > > > > > > > Extensions that will support partial reliability,
> > > > > > > > > > > and negotiation and use of Forward Error Correction
> > > > > > > > > > > schemes, are out of scope in this version of the working
> group charter.
> > > > > > > > > > > """
> > > > > > > > > > >
> > > > > > > > > > > *If* we do decide we'd like to adopt, we'll need to
> > > > > > > > > > > update it to something
> > > > > > > > > > > like:
> > > > > > > > > > >
> > > > > > > > > > > """
> > > > > > > > > > > Please take a look and discuss any concerns; we'll
> > > > > > > > > > > be asking our ADs for such a modification (with
> > > > > > > > > > > appropriate changes to the list of extensions
> > > > > > > > > > > adopted) once our Calls for
> > > >
> > > > Adoption complete.
> > > > > > > > > > >
> > > > > > > > > > > Cheers,
> > > > > > > > > > >

---

From: Jana Iyengar <[email-masked]>
Date: Wed, 18 Dec 2019 20:08:18 -0800

Roni,

The charter will retain the part that allowed discussion of this work in
the working group so far:
"the working group must consider the impact of the protocol on network
management practices, reflecting the tensions described in RFC 7258"

Work obviously does not need to be adopted for it to be discussed. It needs
to be covered in the charter, which this is.

- jana

On Wed, Dec 18, 2019 at 11:34 AM Roni Even (A) <[email-masked]> wrote:

> Magnus,
> I am confused, I was not asking for adoption of the work but to have it in
> the charter so it can be discussed on the list and worked upon without
> being contested as non-chartered work. This is at least my understanding
> about the difference between the charter and adoption
>
> Roni
>
> expect to
> > dependency. That alone is enough from my perspective to not include this
> in
> > this
> > step of adopting things.
> >
> now, we
> > > that extension draft in the WG adoption call prior to the charter
> update?
> > (As
> list. For
> > > > this, we
> > > > will need a charter change for that, but we've been talking to the
> ADs
> > about
> considered
> > > > datagrams)   or less (LBs), so why not lossbit, for example or any
> other
> > > > from
> discussed
> > > > at
> > > > all during the "quiet" .  I would prefer to allow in the charter and
> decide
> > > > if to
> > > > create a milestone.
> > > >
> > > > Roni
> > > >
> intentionally
> will
> > > > > > I know that it was discussed in tsvarea session. I noticed that
> are
> > > > > > currently
> should
> charter
> > > > > > > > I looked at your response to Jana, I do not have a better
> text
> > > > > > > > suggestion
> > > > > > >
> charter
> update

---

From: Madhan Raj Kanagarathinam <[email-masked]>
Date: Thu, 19 Dec 2019 12:01:00 +0530

I Second that. Multipathing in QUIC would be of greater advantage. Mainly for wireless mobile devices and 5G ecosystem.

Multipath TCP had quite a few hiccups and short comes. However, (MP)QUIC, by its design overcomes, the common disadvantages of (MP)TCP.

Regards,

Madhan Raj K

Chief Engineer - Samsung R&D Institute India Bangalore.

--------- Original Message ---------

Sender : Olivier Bonaventure <[email-masked]>

Date : 2019-12-19 00:10 (GMT+5:30)

Title : Re: Multipath (was: Re: Re-chartering for extension work)

Jana,

>
> None of this is to say that we shouldn't take on a hard problem, but before we start sliding into it, I would like to be convinced of its importance.. We already have connection migration in the core drafts, and I'd like to see an articulation of the problems that multipath would solve in addition to basic migration. I would also like to see implementations that are keen to build it if an extension were to be developed, and applications that will use it. Without those, we would be putting the cart before the horse.
>

Olivier

--

Disclaimer: https://protect2.fireeye.com/url?k=83af02c2-de7f0a2a-83ae898d-000babff32e3-8591a0f3b881b715&u=https://www.tessares.net/mail-disclaimer/
<https://protect2.fireeye.com/url?k=321689df-6fc68137-32170290-000babff32e3-5dfb79915dc81fa4&u=https://www.tessares.net/mail-disclaimer/>

---

From: Lars Eggert <[email-masked]>
Date: Thu, 19 Dec 2019 08:41:47 +0200

Hi,

> I am confused, I was not asking for adoption of the work but to have it in the charter so it can be discussed on the list and worked upon without being contested as non-chartered work. This is at l…

only work items that the WG has consensus in terms of eventually shipping them go into the charter. We then usually can adopt individual drafts as starting points for those chartered items.

We're parallelizing things at the moment to some degree, by running the adoption calls in parallel to the recharter, since we're on an accelerated timeline. I'm sorry if this is confusing.

Lars

---

From: Lars Eggert <[email-masked]>
Date: Thu, 19 Dec 2019 08:45:34 +0200

Hi,

> I support considering WG Charter as a "promise to IETF" as to the scope of work the group will and will not do.  As such, re-chartering frequently is the same as changing your promises frequently.…

there is no expectation that charters need to remain stable over long periods of time, esp. for busy WGs. And the current recharter as well as the future ones I can see are very minimal in scope (see the diff that Mark posted.)

Lars

---

From: "Roni Even (A)" <[email-masked]>
Date: Thu, 19 Dec 2019 07:11:21 +0000

Hi Jana,
The loss bit is an example, there are multiple individual drafts in the QUIC document list and I think that naming extensions in the charter is not the right direction.
As for the management, not being a lawyer, the charter text say consider the impact not about addressing the impacts or extending the protocol.

Roni

From: Jana Iyengar [mailto:[email-masked]]
Sent: Thursday, December 19, 2019 6:08 AM
To: Roni Even (A)
Cc: Magnus Westerlund; [email-masked]; [email-masked]; [email-masked]; [email-masked]
Subject: Re: Re-chartering for extension work

Roni,

The charter will retain the part that allowed discussion of this work in the working group so far:
"the working group must consider the impact of the protocol on network management practices, reflecting the tensions described in RFC 7258"

Work obviously does not need to be adopted for it to be discussed. It needs to be covered in the charter, which this is.

- jana

On Wed, Dec 18, 2019 at 11:34 AM Roni Even (A) <[email-masked]<mailto:[email-masked]>> wrote:
Magnus,
I am confused, I was not asking for adoption of the work but to have it in the charter so it can be discussed on the list and worked upon without being contested as non-chartered work. This is at least my understanding about the difference between the charter and adoption

Roni

> From: Magnus Westerlund [mailto:[email-masked]<mailto:[email-masked]>]
> To: Roni Even (A); [email-masked]<mailto:[email-masked]>; [email-masked]<mailto:[email-masked]>
> Cc: [email-masked]<mailto:[email-masked]>; [email-masked]<mailto:[email-masked]>
> > > On Thu, Dec 12, 2019 at 4:52 AM, Roni Even (A)
> <[email-masked]<mailto:[email-masked]>> wrote:
> > >
> > > Hi
> > > > From: Magnus Westerlund [mailto:[email-masked]<mailto:[email-masked]>]
> > > > To: Roni Even (A); [email-masked]<mailto:[email-masked]>
> > > > Cc: [email-masked]<mailto:[email-masked]>; [email-masked]<mailto:[email-masked]>
> > > > > > From: Mark Nottingham [mailto:[email-masked]<mailto:[email-masked]>]
> > > > > > > On 12 Dec 2019, at 6:13 pm, Roni Even (A)
> <[email-masked]<mailto:[email-masked]>>
> > > > > >
> > > > > > wrote:
> > > > > > >
> > > > > > > HI Mark,
> > > > > > > > From: Mark Nottingham [mailto:[email-masked]<mailto:[email-masked]>]
> > > > <[email-masked]<mailto:[email-masked]>>
> > > > > > > >
> > > > > > > > wrote:
> > > > > > > > >
> > > > > > > > > Hi Mark,
> > > > > > > > > > From: QUIC [mailto:[email-masked]<mailto:[email-masked]>] On Behalf Of
> > > > > > > > > > Mark Nottingham
> > > > adef-683bb7f58fea&u=https%3A%2F%2Fwww.mnot.net<http://2Fwww.mnot.net>%2F
> > > > > > > >
> > > > > > > > --
> > > > > > > > Mark Nottingham
> > > > adef-683bb7f58fea&u=https%3A%2F%2Fwww.mnot.net<http://2Fwww.mnot.net>%2F
> > > > > >
> > > > > > --
> > > > > > Mark Nottingham
> > > > 683bb7f58fea&u=https%3A%2F%2Fwww.mnot.net<http://2Fwww.mnot.net>%2F
> > > > >
> > > > >
> > > >
> > > > --
> > > > Cheers
> > > >
> > > > Magnus Westerlund
> >
> >
> --
> Cheers
>
> Magnus Westerlund
>
>
> SE-164 80 Stockholm, Sweden | mailto: [email-masked]<mailto:[email-masked]>

---

From: "Roni Even (A)" <[email-masked]>
Date: Thu, 19 Dec 2019 07:25:03 +0000

Hi Lars,
I am probably having problem with understanding the difference between milestones and charter.

My understanding is the you adopt a draft to serve as the initial document addressing a milestone. The WG decides to create a milestone based on the charter, the charter provides general goals.  I would prefer if the charter will say that the WG will work on extending the QUIC protocol to address the applicability and manageability of the QUIC protocol as a general transport protocol.

Roni

> From: Lars Eggert [mailto:[email-masked]]
> Sent: Thursday, December 19, 2019 8:42 AM
> To: Roni Even (A)
> Cc: Magnus Westerlund; Mark Nottingham; [email-masked];
> [email-masked]
> the charter so it can be discussed on the list and worked upon without being
> only work items that the WG has consensus in terms of eventually shipping
> them go into the charter. We then usually can adopt individual drafts as
> starting points for those chartered items.
> 
> We're parallelizing things at the moment to some degree, by running the
> adoption calls in parallel to the recharter, since we're on an accelerated
> timeline. I'm sorry if this is confusing.
> 
> Lars

---

From: Lars Eggert <[email-masked]>
Date: Thu, 19 Dec 2019 09:48:02 +0200

Hi,

On 2019-12-19, at 9:25, Roni Even (A) <[email-masked]> wrote:
> I would prefer if the charter will say that the WG will work on extending the QUIC protocol to address the applicability and manageability of the QUIC protocol as a general transport protocol.

right. That is a separate recharter discussion, because you would like to change the applicability-and-manageability related text from what it currently is. We can certainly have that discussion, but lumping it in with the current recharter effort is IMO not helpful.

Lars

---

From: Magnus Westerlund <[email-masked]>
Date: Thu, 19 Dec 2019 09:16:14 +0000

Roni,

The current charter does not allow us to do some of the proposed near term
additional work, especially datagrams. Thus, we need to do something about the
charter if we are going to do that work at all. At the same time it does not
appear to be the right time either to have the bigger discussion of how the next
longer term charter should look like. 

I understand you are arguing for that it should be in the WGs discression to
adopt extensions to QUIC. From my perspective it is not that simple, as we need
to put wording in to delimit that work in a reasonable way. As AD I need to
understand how we handle work that have sufficient interest but may not fit the
next steps of QUIC WG. This requires some though and coordination with other
areas also, especially ART. It is also only since Singapore we gave the message
that extensions and other new work will be possible to consider going forward.
Thus, I also want to give people some time to make their proposals if they
haven't already due to we having said not yet, please wait. I do expect us all
to have a firmer understanding of the situation at the next meeting. We will
hoepfully also know better how much work remains on QUIC v1. 

It is my decision as the responsible AD to do this in two steps. First a minimal
recharter to allow for the work that the adoption call is done for. Later next
year we will have the bigger recharter discussion. 

And yes the current set of three work items being proposed for adoption and
rechartering have been picked by the chairs and the ADs based on relevance,
interest in the work from the WG, expectations on how it can be completed, and
that it will not significantly impact the QUIC v1 progression. Yes, this may not
be the most open process, but the alternative from our side is to delay adopting
any additional work until we can fit that bigger discussion. I at least don't
see that as good either. If the WG participants would prefer such a process you
are welcome to speak up and object to the recharter. 

Cheers

Magnus Westerlund
TSV AD

On Thu, 2019-12-19 at 07:11 +0000, Roni Even (A) wrote:
> Hi Jana,
> The loss bit is an example, there are multiple individual drafts in the QUIC
> document list and I think that naming extensions in the charter is not the
> right direction.
> As for the management, not being a lawyer, the charter text say consider the
> impact not about addressing the impacts or extending the protocol.
>  
> Roni
>  
> Work obviously does not need to be adopted for it to be discussed. It needs to
> be covered in the charter, which this is.
>  
> - jana
>  
> > contested as non-chartered work. This is at least my understanding about the
> > difference between the charter and adoption
> > 
> > Roni
> > 
> > > <[email-masked]> wrote:
> > > > >
> > > > > Hi
> > > > > will reserve time for it during the quiet for disucssion on the list.
> > For
> > > > > this, we
-- 
Cheers

Magnus Westerlund

---

From: Kuhn Nicolas <[email-masked]>
Date: Thu, 19 Dec 2019 09:33:13 +0000

Hi, 

> (Same goes for pretty much *any* other extension, FWIW.)

Thank you for your answer. 
We understand that the proposal is not at the same stage as others and understand the decision.
We mostly wanted to share with the group that we are working to improve the current version of the proposal and are happy to have feedback. 

Kind regards, 

Nicolas 

-----Message d'origine-----
De : Lars Eggert <[email-masked]> 
Envoyé : mercredi 18 décembre 2019 07:33
À : Kuhn Nicolas <[email-masked]>
Cc : Mark Nottingham <[email-masked]>; Gorry Fairhust <[email-masked]>; [email-masked]; IETF QUIC WG <[email-masked]>; [email-masked]
Objet : Re: Re-chartering for extension work

Hi,

Lars

---

From: Kuhn Nicolas <[email-masked]>
Date: Thu, 19 Dec 2019 10:39:40 +0000

Hi,

Thanks for your feedback – it helps us very much.
See inline for some comments to your email.

Cheers,

Nico

De : Christian Huitema <[email-masked]>
Envoyé : mardi 17 décembre 2019 20:49
À : Ian Swett <ianswett=[email-masked]>; Kuhn Nicolas <[email-masked]>
Cc : Gorry (erg) <[email-masked]>; [email-masked]; Mark Nottingham <[email-masked]>; [email-masked]; Lars Eggert <[email-masked]>; IETF QUIC WG <[email-masked]>
Objet : Re: [EToSat] Re-chartering for extension work

The 0RTT draft is a simple extension defining new transport parameters. It is a fine draft, but it is only part of the solution, and I don't know whether we need to engage the charter extension process just for that.

[NK] I think that 0RTT document is not focusing particularly on satellite (even if it was driven by a satellite use case at the beginning). If QUIC is used as a tunneling solution, there may be a large BDP and a connection would be bi-directional transmission of data. In this case, sharing information from the client and the server could be beneficial. Another thing is the optimization of asymmetric links that is not specific to satellite – see my comment below.

IMHO if we start adopting "satellite" work in QUIC, we should start by the problem statement rather than the proposed solution. Nicolas, you have a draft in progress defining "satellite scenarios". I think that would be a very good starting point.

I am half way through the work to make the picoquic implementation work well on satellite, and I found the scenario definitions very useful. I did find the issue mentioned by you, Emile, John and Gorry in your presentations, but I also found a bunch of other ones. The high BDP tests stress parts of the code that are not exercised in the other scenarios, such as reordering out of sequence arrival of frame data in a very long list of buffers, managing ACK-of-ACK when the SACK list is long and full of holes, or performing spurious loss detection when the list of repeated packets is much longer than usual. These are of course purely implementation issues. Of course, other implementations may or may not have these specific issues. Maybe they will find different issues. But the point remains that having a good set of well defined tests will advance support for the satellite scenarios.

[NK] Thank you for these feedback. We have indeed provided regression tests in the QUIC 4 SAT document. We plan on showing some results at next IETF. We also plan to provide referenced values for each test.

Another issue that I found was dealing with high variance of RTT measurements induced by asymmetry between the upload and download capacity. Gorry presented the issue in terms of "load on the ACK path" and suggested reducing the ACK rate, which should definitely be part of the recommended solution. But this is not just a load issue, it also impacts RTT measurements which in turn impact a variety of algorithms -- especially if the implementation relies on delay based congestion control to be robust in the presence of random packet losses. I dealt with the RTT measurement issue by defining a one way delay measurement extension, which has other usages than satellite and might also be a candidate for WG adoption -- once I manage to actually write it in a draft of course. There may be more work required to deal with the asymmetry.

[NK] One thing that is not particularly related to satellite but to asymmetry in general could be done through the 0-RTT proposed extension – such as we proposed in the section 5 of the current version https://tools.ietf.org/html/draft-kuhn-quic-0rtt-bdp-05#section-5 .

-- Christian Huitema
On 12/17/2019 7:37 AM, Ian Swett wrote:
I think the satellite use case is an important one, but I have a number of concerns with the approach in that draft, so I don't believe it's ready for adoption.

On Tue, Dec 17, 2019 at 12:29 PM Kuhn Nicolas <[email-masked]<mailto:[email-masked]>> wrote:
Hi Mark, Lars,

Regards,
Nicolas, Emile and Gorry

-----Message d'origine-----
De : QUIC <[email-masked]<mailto:[email-masked]>> De la part de Mark Nottingham
Envoyé : mercredi 11 décembre 2019 22:38
À : IETF QUIC WG <[email-masked]<mailto:[email-masked]>>
Cc : Lars Eggert <[email-masked]<mailto:[email-masked]>>
Objet : Re-chartering for extension work

"""

"""

Cheers,

EToSat mailing list

[email-masked]<mailto:[email-masked]>

---

From: Gorry Fairhurst <[email-masked]>
Date: Thu, 19 Dec 2019 13:32:56 +0000

On 18/12/2019 22:42, Ryan Hamilton wrote:
>
>
> On Wed, Dec 18, 2019 at 10:40 AM Olivier Bonaventure 
> <[email-masked] 
> <mailto:[email-masked]>> wrote:
>
>     [snip]
>
>     A second use case is for mobile devices that need to preserve
>     connectivity while switching from one wireless network to another.
>     When such a device detects another wireless network, it needs to
>     bet whether migrating the connection to the new network would
>     improve performance. With a multipath transport, there is no need
>     to bet as the transport will automatically select the best
>     performing network. Apple’s deployment of Multipath TCP is a good
>     example of the benefits of such a multipath strategy.
>
>
> FWIW, QUIC connection migration was designed to do explicitly this and 
> has been very successful in Google's deployment. I don't think this is 
> a good justification for multipath QUIC.
>
> Cheers,
>
> Ryan

Just as an observation - It seems you can design connections:

(1) to survive rebinding here you expect normally the same path (or set 
of devices on path),

(2) to fail-over between different paths where you expect diverse 
characteristics -  SCTP separated path fail-over (a standardised feature)

and (3) to do multi-path sharing (not currently in the RFC series) - 
where you may wish to schedule to minimise delay; maximise throughput; 
optimise for some other metric.

I can see merit in acquiring experience that migration works well in the 
first and second case before starting on scheduling/cross path sharing.

gorry

---

From: Olivier Bonaventure <[email-masked]>
Date: Fri, 20 Dec 2019 09:40:33 +0100

Magnus,

> managing the process and are communicating with us ADs regularly. 

I agree, the working group should focus its energy on the charter items and minor additions.

> the protocol and any additional guidance documents needed will clearly need

The QUIC design brings a lot of flexibility that could enable the definition of a wide range of very useful extensions in many different scenarios. Several drafts have been proposed in this direction, but it is possible to be more generic as described in the Pluginized QUIC paper that was presented at SIGCOMM’20 (see https://www.pquic.org <https://www.pquic.org/>)

I think that it could be useful for the evolution of QUIC to encourage the exploration of new extensions and organise a process where there extensions that would be scheduled for v2 or beyond could be discussed. This could be an informal mailing list, side meetings well announced in advance with a call for contributions, … There is energy in the community to also work on extending and we should try to encourage that without interfering with the QUIC WG charter.

Best regards,

Olivier

--

---

From: Olivier Bonaventure <[email-masked]>
Date: Fri, 20 Dec 2019 14:30:24 +0100

Ryan,

> On Wed, Dec 18, 2019 at 10:40 AM Olivier Bonaventure <[email-masked] <mailto:[email-masked]>> wrote:
> [snip]
> 
> FWIW, QUIC connection migration was designed to do explicitly this and has been very successful in Google's deployment. I don't think this is a good justification for multipath QUIC.
> 

Connection migration works well when there is a clear indication that one path is clearly broken. Unfortunately, there are many practical situations where paths are partially broken or experience high packet losses and this is where multipath really brings benefits.

Olivier
--

---

From: Olivier Bonaventure <[email-masked]>
Date: Fri, 20 Dec 2019 14:36:23 +0100

Gorry,
> (1) to survive rebinding here you expect normally the same path (or set of devices on path),
> 
> (2) to fail-over between different paths where you expect diverse characteristics -  SCTP separated path fail-over (a standardised feature)
> 
> and (3) to do multi-path sharing (not currently in the RFC series) - where you may wish to schedule to minimise delay; maximise throughput; optimise for some other metric.
> 
> 
> I can see merit in acquiring experience that migration works well in the first and second case before starting on scheduling/cross path sharing.

The MPTCP deployments on various smartphones bring lot of operational experience on the benefits of using multipath transport to support (1) and (2). The  hybrid access networks that use MPTCP to combine xDSL and cellular to provide fast broadband services also provide a lot of operational experience with (3). These lessons can be leveraged in multipath QUIC as well.

Olivier
--

---

From: Tommy Pauly <[email-masked]>
Date: Fri, 20 Dec 2019 05:52:29 -0800

> On Dec 20, 2019, at 5:30 AM, Olivier Bonaventure <[email-masked]> wrote:
> 
> Ryan,
> 
>>> On Wed, Dec 18, 2019 at 10:40 AM Olivier Bonaventure <[email-masked]> wrote:
>>> [snip]
>>> 

This depends on how migration is implemented, I expect. If an implementation only sends probes or migrates when it encounters significant loss or delay (or a loss of connectivity) on one path, then it can be too slow to react. The same goes for very conservative modes of MPTCP. 

However, with path probing, a QUIC migration implementation can track and monitor multiple paths, and can switch between them quickly if it wants. It can do this for any reason, either indication of slight degradation of loss, or just because the probes on one path seem to return fastest at the moment.

Fundamentally, the capabilities that “full” multipath enable on top of migration are:
- Bandwidth aggregation
- Separated congestion control
- The ability to split traffic (such as on a stream basis) across paths to take advantage of different link characteristics

These are all good to enable, but these are not the core benefits that devices right now are gaining from multipath, as much as the ability to migrate with agility. We should absolutely work on multipath, but it may be good to see how shipping migration (the first half of multipath) goes first. 

Best,
Tommy

---

From: Jana Iyengar <[email-masked]>
Date: Fri, 20 Dec 2019 17:48:44 -0800

> - The ability to split traffic (such as on a stream basis) across paths to
> take advantage of different link characteristics
>
> These are all good to enable, but these are not the core benefits that
> devices right now are gaining from multipath, as much as the ability to
> migrate with agility. We should absolutely work on multipath, but it may be
> good to see how shipping migration (the first half of multipath) goes
> first.
>

Yep. This has been my experience as well.

I appreciate that there are some cases where simple bandwidth aggregation
is useful, but there is a real question about the amount of effort required
to not just standardize but also build a multipath extension for those
specific use cases.

The relevant question I would be looking for answers to is how many
implementers will commit to implementing a multipath extension if one were
to be standardized.

FWIW: I also don't believe MPTCP has solved all multipath problems, not in
the general case anyways. There are real ones that make actual deployment
super difficult. Specifically, scheduling is a real issue. Deciding when to
use multiple paths and how to use them remains an open question. The answer
in my experience ends up being very application-dependent, which means that
you need an application to buy in before you develop a scheduler. And
without this buy-in, I couldn't justify spending the time and energy to
spend time on building multipath into our implementation at least.