Re: Proposed Charter Text

[Spencer Dawkins at IETF <[e-mail]>]

Hi, Magnus,

I have one question.

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

> 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.
>

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

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  [phone]
> Torshamnsgatan 23           | Mobile [phone]
> SE-164 80 Stockholm, Sweden | mailto: [e-mail]
> ----------------------------------------------------------------------
>
>