Subject: Proposed Charter Text

From: Magnus Westerlund <[email-masked]>
Date: Mon, 27 Jan 2020 12:22:07 +0000

WG,

Below you will find the draft charter text proposed by ADs and WG chairs. I
intended to have the IESG agree to send this out for External Review at the next
IESG meeting (2020-02-06). So if you have any comments and proposal for changes
now is a good time. 

Below is a copy of the current draft in the datatracker:
https://datatracker.ietf.org/doc/charter-ietf-quic/

Diff: 
https://www.ietf.org/rfcdiff?url1=https%3A%2F%2Fdatatracker.ietf.org%2Fdoc%2Fcharter-ietf-quic%2Fwithmilestones-01.txt&url2=https%3A%2F%2Fdatatracker.ietf.org%2Fdoc%2Fcharter-ietf-quic%2Fwithmilestones-01-00.txt

QUIC WG Draft Charter (01-00)

The QUIC working group will provide standards-track specifications for a
UDP-
based, stream-multiplexing, encrypted transport protocol, based on
pre-
standardization implementation and deployment experience.

Key goals for QUIC are:

- Minimizing connection establishment and overall transport latency for
applications, starting with HTTP/2; - Providing multiplexing without
head-of-line blocking; - Requiring only changes to path endpoints to enable
deployment; - Enabling multipath and forward error correction extensions; and -
Providing always-secure transport, using TLS 1.3 by default.

The work of the group will have five main focus areas, corresponding to five
core deliverables.

The first of these is the core transport work, which will describe the wire
format, along with the mechanisms for connection establishment, stream
multiplexing, data reliability, loss detection and recovery, congestion
control, and options negotiation. Work on congestion control will describe use
of a standardized congestion controller as a default scheme for QUIC. Defining
new congestion control schemes is explicitly out of scope for this group. QUIC
is expected to support rapid, distributed development and testing of features.

The second of these focus areas is security. This work will describe how the
protocol uses TLS 1.3 for key negotiation and will also describe how those keys
are used to provide confidentiality and integrity protection of both
application data and QUIC headers. This work will ensure that QUIC has security
and privacy properties that are at least as good as a stack composed of TLS 1.3
using TCP (or MPTCP when using multipath).

The third focus area will describe mappings between specific application
protocols and the transport facilities of QUIC. The first mapping will be a
description of HTTP/2 semantics using QUIC, specifically with the goal of
minimizing web latency using QUIC. This mapping will accommodate the extension
mechanisms defined in the HTTP/2 specification. Upon completion of that
mapping, additional protocols may be added by updating this charter to include
them, or working elsewhere.

The fourth focus area will be on extensions to core protocol facilities, to
enable datagram delivery, version negotiation, and multipath capabilities.
Other extensions are out of the scope of this charter.

The fifth focus area will provide an Applicability and Manageability Statement,
describing how, and under what circumstances, QUIC may be safely used, and
describing deployment and manageability implications of the protocol.
Additionally, the Working Group will delivery a mechanism to assist load
balancers in their handling of QUIC.

Current practices for network management of transport protocols include the
ability to apply access control lists (ACLs), hashing of flows for equal-cost
multipath routing (ECMP), directional signaling of flows, signaling of flow
setup and teardown, and the ability to export information about flows for
accounting purposes. The QUIC protocol need not be defined to enable each of
these abilities, or enable them in the same way as they are enabled by TCP when
used with TLS 1.3, but the working group must consider the impact of the
protocol on network management practices, reflecting the tensions described in
RFC 7258.

Note that consensus is required both for changes to the current protocol
mechanisms and retention of current mechanisms. In particular, because
something is in the initial document set does not imply that there is consensus
around the feature or around how it is specified.

The QUIC working group will work closely with the HTTPbis working group,
especially on the QUIC mapping for HTTP/2.

-- 
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: Magnus Westerlund <[email-masked]>
Date: Mon, 27 Jan 2020 14:07:41 +0000

Hi,

Due to the reshuffeling it may be hard to see exactly what is changing. So to
clarify in text what is being changed. 

The big change is to allow work on three "extension": Version Negotiation,
datagram (these two are listed under fourth focus area) and how to better
support load balancers (fifth focus area). 

Otherwise the changes are:
- removal of the initial input drafts to base the work on in first paragraph.
- Reshuffling of the paragraphs, the one "current practices for network
management ..." is moved down. 
- Removal of pragaraph regarding interim during first year. 
- Removal of stand alone paragraph preventing extension work. The no other
extensions is now baked into paragraph on fourth focus area. 
- Clarification that mapping work may also be done outside of QUIC WG. 

Cheers

Magnus Westerlund

-- 
Cheers

Magnus Westerlund

---

From: Ian Swett <[email-masked]>
Date: Mon, 27 Jan 2020 09:24:34 -0500

Thanks for the update.  The original charter mentions HTTP/2 multiple
times, but except for when it's in reference to extensions, I think it
would be preferable to use HTTP instead of HTTP/2.  For example, "The first
mapping will be a
description of HTTP/2 semantics using QUIC," and  "especially on the QUIC
mapping for HTTP/2" are quite odd now that HTTP/3 is it's own thing which
shares very little with HTTP/2.

And two small comments below.

Ian

On Mon, Jan 27, 2020 at 9:07 AM Magnus Westerlund <magnus.westerlund=
[email-masked]> wrote:

> > intended to have the IESG agree to send this out for External Review at
> the
> > next
> > deployment; - Enabling multipath and forward error correction
> extensions; and
> > -
> > protocol uses TLS 1.3 for key negotiation and will also describe how
> those
> > keys
> > and privacy properties that are at least as good as a stack composed of
> TLS
> > 1.3
> > enable datagram delivery, version negotiation, and multipath
> capabilities..

delivery -> deliver

> > these abilities, or enable them in the same way as they are enabled by
> TCP
> > when

I think the above paragraph should now be removed.

> <+46%2010%20714%2082%2087>
> <+46%2073%20094%2090%2079>

---

From: Roberto Peon <[email-masked]>
Date: Tue, 28 Jan 2020 19:04:15 +0000

Pretty sure I've been a strong cheerleader for avoiding distractions to V1, so you won't hear disagreements there. 
Since we want to make V1 happen, we haven't been discussing V2 stuff.
Datagrams aren't V1 stuff. Worse, datagrams are certainly in the same sphere of stuff as is partial reliability, and so having it now as a 'QUIC' wg draft is going to make the V2 stuff harder in several ways.

This is the root of my concern. 

We're too early to adopt Datagrams as an official document, imho, even as an extension, because doing so makes it more difficult to get the more complete thing done, which we've been avoiding solely to get V1 done.

-=R

On 1/28/20, 2:32 AM, "Magnus Westerlund" <[email-masked]> wrote:

    Roberto,
    
    On Mon, 2020-01-27 at 21:28 +0000, Roberto Peon wrote:
    > Quite frankly, if we’re proposing to allow extensions for datagrams, but not
    > partial reliability, I don’t understand the motivation and I won’t support it.
    > Is that the case here, ‘cause we’re not explicitly talking about it at all
    > with the proposed change?
    
    To my understanding partial reliability for datagrams do not require
    standardization on protocol level. This is a feature that given datagram frames
    in QUIC packets that has PSN that will be acknowledged can be implemented sender
    side with the appropriate API. If the WG think there are aspect of this that
    would benefit from description and alignment on API semnatics then we can
    include that later. However, I don't see it as anyway necessary in this small
    update. And if you think this is something that requires actual specification
    then I would encourage you to ensure that those pieces are written up as a draft
    for discussion. 
    
    And as Mike already stated there will be a bigger rechartering later when the v1
    specifications are done. 
    
    Cheers
    
    Magnus
    
    > -=R
    >  
    > From: QUIC <[email-masked]> on behalf of Mike Bishop <
    > [email-masked]>
    > Date: Monday, January 27, 2020 at 10:06 AM
    > To: Ian Swett <ianswett=[email-masked]>, Magnus Westerlund <
    > magnus.westerlund=[email-masked]>
    > Cc: "[email-masked]" <[email-masked]>
    > Subject: RE: Proposed Charter Text
    >  
    > This is true, but has also been a useful guide to our work on HTTP/3.  As you
    > note, “HTTP/2 semantics” isn’t really a thing – HTTP/2 is a mapping of HTTP
    > semantics over TCP – but we’ve interpreted this as saying that HTTP/3 by
    > default has the same feature set as HTTP/2.  We’ve required consensus in both
    > QUIC and HTTP working groups to deviate from that (e.g. priorities). 
    > Clarifying that language wouldn’t be inappropriate, but also isn’t closely
    > bound to the point of this update.
    >  
    > Depends how much we want to fix existing text, just like any other PR, I
    > suppose.  😊
    >  
    > Other feedback:
    > Formatting nit:  Your “key goals” bullet points are folded into a single
    > mishmash paragraph
    > With the removal of the mention of the initial documents, do we need the
    > discussion about how we decide what to keep/change from those initial
    > documents?
    >  
    > From: QUIC <[email-masked]> On Behalf Of Ian Swett
    > Sent: Monday, January 27, 2020 9:25 AM
    > To: Magnus Westerlund <magnus.westerlund=[email-masked]>
    > Cc: [email-masked]
    > Subject: Re: Proposed Charter Text
    >  
    > Thanks for the update.  The original charter mentions HTTP/2 multiple times,
    > but except for when it's in reference to extensions, I think it would be
    > preferable to use HTTP instead of HTTP/2.  For example, "The first mapping
    > will be a
    > On Mon, Jan 27, 2020 at 9:07 AM Magnus Westerlund <
    > magnus.westerlund=[email-masked]> wrote:
    > > Hi,
    > > 
    > > > deployment; - Enabling multipath and forward error correction extensions;
    > > and
    > > > -
    -- 
    Cheers
    
    Magnus Westerlund

---

From: Ian Swett <[email-masked]>
Date: Tue, 28 Jan 2020 14:49:31 -0500

On Tue, Jan 28, 2020 at 2:04 PM Roberto Peon <[email-masked]> wrote:

> Pretty sure I've been a strong cheerleader for avoiding distractions to
> V1, so you won't hear disagreements there.
> Datagrams aren't V1 stuff. Worse, datagrams are certainly in the same
> sphere of stuff as is partial reliability, and so having it now as a 'QUIC'
> wg draft is going to make the V2 stuff harder in several ways.
>
> We're too early to adopt Datagrams as an official document, imho, even as
> an extension, because doing so makes it more difficult to get the more
> complete thing done, which we've been avoiding solely to get V1 done.
>

I'm unclear on why you think Datagrams make it more difficult to complete
v1?   Aside from a few people writing the draft and this charter
conversation, the working group has spent almost no time on them.  I also
don't believe they add complication to the core spec.

>     > > Due to the reshuffeling it may be hard to see exactly what is
> changing. So
>     > > to
>     > > > Below you will find the draft charter text proposed by ADs and
> WG chairs.
>     > > I
>     > > > IESG meeting (2020-02-06). So if you have any comments and
> proposal for
>     > > > changes
>     > > > now is a good time.
>     > > >
>     > > > head-of-line blocking; - Requiring only changes to path
> endpoints to
>     > > enable
> extensions;
>     > > > The work of the group will have five main focus areas,
> corresponding to
>     > > five
>     > > > core deliverables.
>     > > >
>     > > > The first of these is the core transport work, which will
> describe the
>     > > wire
>     > > > control, and options negotiation. Work on congestion control
> will describe
>     > > use
>     > > > of a standardized congestion controller as a default scheme for
> QUIC.
>     > > Defining
>     > > > new congestion control schemes is explicitly out of scope for
> this group.
>     > > QUIC
>     > > > is expected to support rapid, distributed development and
> testing of
>     > > features.
>     > > >
>     > > > The second of these focus areas is security. This work will
> describe how
>     > > the
>     > > > protocol uses TLS 1.3 for key negotiation and will also describe
> how those
>     > > > keys
>     > > > application data and QUIC headers. This work will ensure that
> QUIC has
>     > > > security
>     > > > protocols and the transport facilities of QUIC. The first
> mapping will be
>     > > a
>     > > > minimizing web latency using QUIC. This mapping will accommodate
> the
>     > > extension
>     > > > mapping, additional protocols may be added by updating this
> charter to
>     > > include
>     > > > The fourth focus area will be on extensions to core protocol
> facilities,
>     > > to
>     > > > The fifth focus area will provide an Applicability and
> Manageability
>     > > > Statement,
>     > > > Current practices for network management of transport protocols
> include
>     > > the
>     > > > ability to apply access control lists (ACLs), hashing of flows
> for equal-
>     > > cost
>     > > > multipath routing (ECMP), directional signaling of flows,
> signaling of
>     > > flow
>     > > > accounting purposes. The QUIC protocol need not be defined to
> enable each
>     > > of
>     > > > these abilities, or enable them in the same way as they are
> enabled by TCP
>     > > > when
>     > > > something is in the initial document set does not imply that
> there is
>     > > > consensus

---

From: Ryan Hamilton <[email-masked]>
Date: Tue, 28 Jan 2020 15:26:39 -0800

> don't believe they add complication to the core spec.

Completely agree. The spec and the mechanism are quite simple. I have a
hard time understanding how they would cause the core spec to be delayed.

---

From: Roberto Peon <[email-masked]>
Date: Wed, 29 Jan 2020 01:49:26 +0000

I mean it makes it more difficult to get V2 stuff done, not that it makes V1 more difficult.
-=R

From: Ian Swett <[email-masked]>
Date: Tuesday, January 28, 2020 at 11:49 AM
To: Roberto Peon <[email-masked]>
Cc: Magnus Westerlund <[email-masked]>, "[email-masked]" <[email-masked]>, "[email-masked]" <[email-masked]>
Subject: Re: Proposed Charter Text

On Tue, Jan 28, 2020 at 2:04 PM Roberto Peon <[email-masked]<mailto:[email-masked]>> wrote:
Pretty sure I've been a strong cheerleader for avoiding distractions to V1, so you won't hear disagreements there.
Since we want to make V1 happen, we haven't been discussing V2 stuff.
Datagrams aren't V1 stuff. Worse, datagrams are certainly in the same sphere of stuff as is partial reliability, and so having it now as a 'QUIC' wg draft is going to make the V2 stuff harder in several ways.

I'm unclear on why you think Datagrams make it more difficult to complete v1?   Aside from a few people writing the draft and this charter conversation, the working group has spent almost no time on them.  I also don't believe they add complication to the core spec.

-=R

On 1/28/20, 2:32 AM, "Magnus Westerlund" <[email-masked]<mailto:[email-masked]>> wrote:

    Roberto,

    Cheers

    Magnus

    > -=R
    >
    > From: QUIC <[email-masked]<mailto:[email-masked]>> on behalf of Mike Bishop <
    > [email-masked]<mailto:[email-masked]>>
    > To: Ian Swett <ianswett=[email-masked]<mailto:[email-masked]>>, Magnus Westerlund <
    > magnus.westerlund=[email-masked]<mailto:[email-masked]>>
    > Cc: "[email-masked]<mailto:[email-masked]>" <[email-masked]<mailto:[email-masked]>>
    > From: QUIC <[email-masked]<mailto:[email-masked]>> On Behalf Of Ian Swett
    > To: Magnus Westerlund <magnus.westerlund=[email-masked]<mailto:[email-masked]>>
    > Cc: [email-masked]<mailto:[email-masked]>
    > magnus.westerlund=[email-masked]<mailto:[email-masked]>> wrote:
    > > Hi,
    > >
    > > > https://datatracker.ietf.org/doc/charter-ietf-quic/<https://urldefense.proofpoint.com/v2/url?u=https-3A__datatracker.ietf.org_doc_charter-2Dietf-2Dquic_&d=DwMFaQ&c=5VD0RTtNlTh3ycd41b3MUw&r=C0sUo-LFNBaYfyoaCsf6TA&m=pPfphhim1HfZkc3J2bYYdLDJ3KGtSxcpRybBhbWHSFI&s=Ut7iDEe1zTeoffbP4IucZr095wXpJq9D0dTC1cCV21s&e=>
    > > >
    > > > Diff:
    > > >
    > >
    https://www.ietf.org/rfcdiff?url1=https%3A%2F%2Fdatatracker.ietf.org%2Fdoc%2Fcharter-ietf-quic%2Fwithmilestones-01.txt&url2=https%3A%2F%2Fdatatracker.ietf.org%2Fdoc%2Fcharter-ietf-quic%2Fwithmilestones-01-00.txt<https://urldefense.proofpoint.com/v2/url?u=https-3A__www.ietf.org_rfcdiff-3Furl1-3Dhttps-253A-252F-252Fdatatracker.ietf.org-252Fdoc-252Fcharter-2Dietf-2Dquic-252Fwithmilestones-2D01.txt-26url2-3Dhttps-253A-252F-252Fdatatracker.ietf.org-252Fdoc-252Fcharter-2Dietf-2Dquic-252Fwithmilestones-2D01-2D00.txt&d=DwMFaQ&c=5VD0RTtNlTh3ycd41b3MUw&r=C0sUo-LFNBaYfyoaCsf6TA&m=pPfphhim1HfZkc3J2bYYdLDJ3KGtSxcpRybBhbWHSFI&s=LbYnQPy_pLgn-aYtM0WgNsQhfEf1Wiocb3v9xuNPu94&e=>
    --
    Cheers

    Magnus Westerlund

    ----------------------------------------------------------------------
    Networks, Ericsson Research
    ----------------------------------------------------------------------
    Ericsson AB                 | Phone  +46 10 7148287<tel:+46%2010%20714%2082%2087>
    Torshamnsgatan 23           | Mobile +46 73 0949079<tel:+46%2073%20094%2090%2079>
    SE-164 80 Stockholm, Sweden | mailto: [email-masked]<mailto:[email-masked]>
    ----------------------------------------------------------------------

---

From: Magnus Westerlund <[email-masked]>
Date: Wed, 29 Jan 2020 12:20:34 +0000

> bound to the point of this update.

I agree that the HTTP/2 looks a bit strange. However, I think I will leave it in
place as there quite a bit to reword. Lets deal this in the next recharter when
maybe some of this text may not even be needed. 

> Formatting nit:  Your “key goals” bullet points are folded into a single

In the editing view in the datatracker they are nice individual lines. So I
think it is some output reflowing that occurs. Will attempt to add some white
spaces to see if it looks better. 

> discussion about how we decide what to keep/change from those initial

So when initially chartered it was an indication of the starting point. However,
three years down the line I would think all decision has been made about what to
keep and not from the input. And any change to the drafts today should not be
based on the argument, this was part of the individual drafts and therefore
should be added/changed. 

Cheers

Magnus

-- 
Cheers

Magnus Westerlund

---

From: Magnus Westerlund <[email-masked]>
Date: Wed, 29 Jan 2020 14:07:33 +0000

On Mon, 2020-01-27 at 16:28 -0800, Jana Iyengar wrote:
> Looks fine. 
> 
> Since you've made broader changes, some nits on the rest of the text:
> 
> - "Upon completion of that	mapping, additional protocols may be added by
> updating this charter to include	them, or working elsewhere." This
> sentence does not make sense anymore. What is that "or working elsewhere"
> supposed to be adding? Should this phrase be dropped?

"working elsewhere" as in other WGs. I still think it is correct, but lets
clarify that other WGs may work on such mappings.

> 
> - The fifth focus area should be described _after_ the paragraph starting with
> "Current network management practices", since that para is related to the
> fourth focus area.

It was Mark that drafted this change. But, I don't understand why that paragraph
should have specific relationship with the 4th focus area of extensions or even
multipaht specifically. I see it as a general requirement for the protocol to
consider hwat is mentioned here. Thus, I think the move is a good oen. 

> - In the fifth focus area, "the Working Group will delivery a mechanism to
> assist load balancers in their handling of QUIC."
>   First, a nit: "delivery" --> "deliver".

Will fix. 

>   Second, perhaps I'm wrong, but I don't remember that we agreed to deliver a
> "mechanism" for this. A more inclusive phrasing here might be "will deliver
> solutions for load balancers to handle QUIC traffic."

I would appreciate more feedback on this. Yes, a solution may not require a
mechanism. I guess you envision simply that some guidance on how a load balancer
can use what already exists rather than charter a requirement for something that
is a protocol change? 

> 
> - Final nit that has already been noted, "the QUIC mapping for HTTP/2". If we
> are going to touch that text, let's change it to "the QUIC mapping for HTTP".
> I agree with Mike that we've used HTTP/2 as the effective API that we're
> building to, but I think that purpose has been served. I don't we're in danger
> of veering way off-course on the HTTP mapping from HTTP/2, if only for
> pragmatic reasons.

I am fine with just writing HTTP in first bullet and in that last paragraph.
However, I like to avoid having to rewrite the whole third focus area paragraph.

Cheers

Magnus Westerlund

---

From: Lucas Pardue <[email-masked]>
Date: Wed, 29 Jan 2020 14:46:46 +0000

Since we have only one mapping, is it fine to talk more solidly about it in
the third focus area? For example, the paragraph could be rewritten as such:

The third focus area describes the mapping between the HTTP application
protocol and the transport facilities of QUIC. This mapping will have
performance characteristics comparable with HTTP/2, and provide extension
mechanisms similar to HTTP/2. Upon completion of this
mapping, work to define additional mappings may be included by updates to
this charter, or may be worked on by other working groups.

---

From: Ian Swett <[email-masked]>
Date: Wed, 29 Jan 2020 10:17:08 -0500

I like Lucas suggestion.

On Wed, Jan 29, 2020 at 9:46 AM Lucas Pardue <[email-masked]>
wrote:

> Since we have only one mapping, is it fine to talk more solidly about it
> in the third focus area? For example, the paragraph could be rewritten as
> such:
>

---

From: Magnus Westerlund <[email-masked]>
Date: Thu, 30 Jan 2020 09:07:57 +0000

Thanks Lucas,

Yes, I will update the draft charter with this proposal. 

Cheers

Magnus

-- 
Cheers

Magnus Westerlund

---

From: Magnus Westerlund <[email-masked]>
Date: Thu, 30 Jan 2020 09:19:55 +0000

> can use what already exists rather than charter a requirement for something

What does the group say about: 

Additionally, the Working Group will deliver solutions that can improve load
balancers handling of QUIC traffic. 

I have included this is the latest version saved in the datatracker. 

Cheers

Magnus Westerlund

---

From: Mirja Kuehlewind <[email-masked]>
Date: Thu, 30 Jan 2020 09:25:11 +0000

Hi all,

I'm not sure if solution is much better than mechanism. I believe what we agreed to is to provide guidance. Maybe we can just write that in the charter:

 Additionally, the Working Group will provide guidance to support load balancers in handling of QUIC traffic.

?

Mirja

On 30.01.20, 10:20, "QUIC on behalf of Magnus Westerlund" <[email-masked] on behalf of magnus.westerlund=[email-masked]> wrote:

    

    Cheers
    
    Magnus Westerlund

---

From: Spencer Dawkins at IETF <[email-masked]>
Date: Thu, 30 Jan 2020 15:17:53 -0600

Hi, Magnus,

I have one question.

On Mon, Jan 27, 2020 at 6:22 AM Magnus Westerlund <magnus.westerlund=
[email-masked]> wrote:

> the next
> and -
> TLS 1.3

When Mark was talking about QUIC futures in TSVAREA at IETF 106, I asked
about this focus area.

Mirja and Brian have faithfully kept this work going from the early days of
the working group (timeline is at
https://datatracker.ietf.org/doc/draft-ietf-quic-manageability/), but it's
not moving very fast (
https://tools.ietf.org/rfcdiff?url2=draft-ietf-quic-manageability-06.txt is
a six-month diff), and I noted that MOPS had a QUIC troubleshooting
discussion at IETF 106 (in their first meeting after being chartered) (
https://datatracker.ietf.org/meeting/106/materials/slides-106-mops-quic-and-streaming-00
).

I pointed out that this work was in QUIC because there was no other place
to put it when QUIC was chartered, but now that MOPS was chartered, and
seems to have such topics in scope, there was an opportunity to move it
into MOPS and let the operator types chew on it. (My experience as "Spin
Bit AD" was that operators do show up in QUIC when management topics are on
the agenda, but I don't think they've engaged much on this draft).

Actual minutes from TSVAREA 106:

Spencer: Operations/mgmt draft isn't on the list. Huh?

mnot: Yes, they're important, but not getting enough attention right now.

Mirja: Those are WG items.

Spencer: We had QUIC ops/mgmt considerations in the QUIC working group charter
because there was nowhere else to put it. Now that Media Operations (MOPS) has
been chartered, they're already talking about measuring
troubleshooting QUIC from
an operator perspective in their first working group session. Maybe
this document
should go into MOPS?

I understood Mark to say "interesting idea, we'll think about it".

Is that still on the table someplace?

Best,

Spencer

---

From: Jana Iyengar <[email-masked]>
Date: Thu, 30 Jan 2020 14:23:42 -0800

>
> I'm not sure if solution is much better than mechanism. I believe what we
> agreed to is to provide guidance. Maybe we can just write that in the
> charter:
>

Sounds good to me.

---

From: Magnus Westerlund <[email-masked]>
Date: Fri, 31 Jan 2020 15:35:48 +0000

Hi Spencer,

See below,

On Thu, 2020-01-30 at 15:17 -0600, Spencer Dawkins at IETF wrote:
> Hi, Magnus, 
> 
> I have one question. 
> 
> On Mon, Jan 27, 2020 at 6:22 AM Magnus Westerlund <
[SNIP]

> When Mark was talking about QUIC futures in TSVAREA at IETF 106, I asked about
> this focus area.
> 
> https://datatracker.ietf.org/doc/draft-ietf-quic-manageability/), but it's not
> moving very fast (
> https://tools.ietf.org/rfcdiff?url2=draft-ietf-quic-manageability-06..txt is a
> six-month diff), and I noted that MOPS had a QUIC troubleshooting discussion
> at IETF 106 (in their first meeting after being chartered) (
> I pointed out that this work was in QUIC because there was no other place to
> put it when QUIC was chartered, but now that MOPS was chartered, and seems to
> have such topics in scope, there was an opportunity to move it into MOPS and
> let the operator types chew on it. (My experience as "Spin Bit AD" was that
> operators do show up in QUIC when management topics are on the agenda, but I
> don't think they've engaged much on this draft). 
> 
> been chartered, they're already talking about measuring troubleshooting QUIC
> from 
> an operator perspective in their first working group session. Maybe this
> document 
> should go into MOPS?

So I think this do require more thought and can be considered for the next
recharter that will be more substantial. However, from my perspective I would be
careful to move to much of the management parts out the QUIC WG. The protocol
defining part do need to consider its impact on managing the protocol. That
can't simply be ignored. However, if there are certain aspects of the management
and operational part that make sense to move then I think that is a reasonable
option. 
 
Cheers

Magnus Westerlund

---

From: Magnus Westerlund <[email-masked]>
Date: Fri, 31 Jan 2020 15:43:45 +0000

> > balancers in handling of QUIC traffic.

I find the english a bit strange. Wouldn't this be better from an english
perspective? 

Additionally, the Working Group will provide guidance on how to enable load
balancers to handle QUIC traffic.

This is actually based on that the document proposals scheme defines how
endpoints should generate and structure CIDs to enable the load balancers to
route based on the CID. 

Any additional feedback on this? 

Cheers

Magnus Westerlund

---

From: Martin Duke <[email-masked]>
Date: Fri, 31 Jan 2020 09:51:20 -0800

(speaking as the draft author) In my opinion, the QUIC-LB work is a natural
extension of the ops and manageability draft rather than a genuine
extension of the WG scope. Nevertheless I have no objection to adding the
text to the charter.

---

From: Spencer Dawkins at IETF <[email-masked]>
Date: Fri, 31 Jan 2020 12:59:39 -0600

Hi, Magnus,

On Fri, Jan 31, 2020 at 9:35 AM Magnus Westerlund <
[email-masked]> wrote:

> about
> > because there was nowhere else to put it. Now that Media Operations
> (MOPS)
> > has

Well, sure. That's why I agreed to add the management and applicability
work to the QUIC charter when we approved the working group. :-)

I was mostly thinking about ways to move the work forward a bit more
quickly, potentially with more operator input. And there may be other ways.

And I agree that this requires thought, especially with two ART AD slots, a
TSV slot, and one OPS AD slot turning over in March, as of yesterday's
Nomcom announcement (only one ART AD will be replaced, of course), so
thinking between IETF 106 and 107 would likely have been premature.

I just wanted to make sure it hadn't slid off the table, for when it's not
premature.

Best,

Spencer

---

From: Jana Iyengar <[email-masked]>
Date: Fri, 31 Jan 2020 18:18:27 -0800

> balancers to handle QUIC traffic.

SGTM. A minor rephrase: "Additionally, the Working Group will provide
guidance on how load balancers can be enabled to handle QUIC traffic."