Subject: WG Review: QUIC (quic)

From: The IESG <[email-masked]>
Date: Fri, 07 Feb 2020 09:15:58 -0800

The QUIC (quic) WG in the Transport Area of the IETF is undergoing
rechartering. The IESG has not made any determination yet. The following
draft charter was submitted, and is provided for informational purposes only.
Please send your comments to the IESG mailing list ([email-masked]) by
2020-02-17.

QUIC (quic)
-----------------------------------------------------------------------
Current status: Active WG

Chairs:
  Mark Nottingham <[email-masked]>
  Lars Eggert <[email-masked]>
  Lucas Pardue <[email-masked]>

Assigned Area Director:
  Magnus Westerlund <[email-masked]>

Transport Area Directors:
  Mirja Kühlewind <[email-masked]>
  Magnus Westerlund <[email-masked]>

Mailing list:
  Address: [email-masked]
  To subscribe: https://www.ietf.org/mailman/listinfo/quic
  Archive: https://mailarchive.ietf.org/arch/browse/quic/

Group page: https://datatracker.ietf.org/group/quic/

Charter: https://datatracker.ietf.org/doc/charter-ietf-quic/

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;

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

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 provide guidance on how to
handle QUIC traffic in load balancers.

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.

Milestones:

  Jul 2020 - Core Protocol document to IESG

  Jul 2020 - Loss detection and Congestion Control document to IESG

  Jul 2020 - TLS 1.3 Mapping document to IESG

  Jul 2020 - HTTP/2 mapping document to IESG

  Jul 2020 - QUIC Applicability and Manageability Statement to IESG

  Jul 2020 - Version-Independent Properties of QUIC to IESG

  Jul 2020 - QPACK: Header Compression for HTTP over QUIC to IESG

  Dec 2020 - Working group adoption of Multipath extension document

  Mar 2021 - Datagram Extension to IESG

  Mar 2021 - Version Negotiation Extension to IESG

  Dec 2021 - Multipath extension document to IESG

---

From: Spencer Dawkins at IETF <[email-masked]>
Date: Mon, 10 Feb 2020 15:35:30 -0600

Dear IESG,

I don't have any concerns about the direction for this charter, but I do
have some suggestions on wording.

Best,

Spencer

> Please send your comments to the IESG mailing list ([email-masked]) by

I'm wondering when these change from goals to attributes, but maybe the
next major revision is the right time ...

> The first of these is the core transport work, which will describe the wire

I wonder when the charter moves from future tense (which was accurate in
2016) to present tense, but perhaps after version 1 is complete would be a
good time.

> worked on by other working groups.

When QUIC was chartered, my hope (and I don't think I was the only one) was
that we would end up with HTTP/2 over QUIC. For good reasons, we ended up
with HTTP/3 over QUIC, and it seems odd that there's no mention of HTTP/3
in the 2020 QUIC charter, but it IS mentioned in
https://datatracker.ietf.org/doc/charter-ietf-httpbis/.

> consensus around the feature or around how it is specified.

This paragraph ^ was inserted to say "the way Google QUIC happens to work
in 2016" (which was the only QUIC we had) "isn't binding on the working
group producing IETF QUIC". That was worth saying in 2016 - and we might
have said it more clearly - but in 2020, the obvious meaning of "current
protocol mechanisms" is IETF QUICv1. I don't think this paragraph means
anything helpful now, and anyone who tries to be guided by it, is probably
headed into the weeds. I'd delete it.

>   Jul 2020 - QUIC Applicability and Manageability Statement to IESG

Just making sure I understand - the load balancing advice would be included
in this statement, is that right?

> _______________________________________________
> IETF-Announce mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/ietf-announce
>

---

From: Giorgio Zoppi <[email-masked]>
Date: Mon, 10 Feb 2020 22:40:07 +0100

Dear all,
when will be the next meeting? I know that the last was in Zurich.
BR,
Giorgio

El lun., 10 feb. 2020 a las 22:36, Spencer Dawkins at IETF (<
[email-masked]>) escribió:

> When QUIC was chartered, my hope (and I don't think I was the only one)
> was that we would end up with HTTP/2 over QUIC. For good reasons, we ended
> up with HTTP/3 over QUIC, and it seems odd that there's no mention of
> HTTP/3 in the 2020 QUIC charter, but it IS mentioned in
> Just making sure I understand - the load balancing advice would be
> included in this statement, is that right?
>

-- 
Life is a chess game - Anonymous.

---

From: Spencer Dawkins at IETF <[email-masked]>
Date: Mon, 10 Feb 2020 21:04:30 -0600

Dear IESG,

I sent this to IESG-Secretary, which is where replies to announcements from
the datatracker go, and Cindy asked me to send it to you, so that someone
besides Cindy would see it :-)

Best,

Spencer

---------- Forwarded message ---------
From: Spencer Dawkins at IETF <[email-masked]>
Date: Mon, Feb 10, 2020 at 3:35 PM
Subject: Re: WG Review: QUIC (quic)
To: The IESG <[email-masked]>
Cc: IETF QUIC WG <[email-masked]>

Dear IESG,

Best,

Spencer

---

From: Martin Duke <[email-masked]>
Date: Tue, 11 Feb 2020 18:30:49 +0100

Giorgio, at this time there is no plan for an additional interim. QUIC
business will be conducted at regular IETF meetings until further notice.

---

From: Magnus Westerlund <[email-masked]>
Date: Wed, 12 Feb 2020 10:03:09 +0000

Hi Spencer,

Thanks for the comments. Please see inline. 

QUIC (quic)
> I'm wondering when these change from goals to attributes, but maybe the next
> major revision is the right time ...

Yes, I think the next version is the time to rework the whole charter. 

> I wonder when the charter moves from future tense (which was accurate in 2016)
> to present tense, but perhaps after version 1 is complete would be a good
> time. 

As the first version work still is ongoing I think the natural phase to change
the tempus will be in the next recharter when we actually have a first version
of the protocol. 

> that we would end up with HTTP/2 over QUIC. For good reasons, we ended up with
> HTTP/3 over QUIC, and it seems odd that there's no mention of HTTP/3 in the
> 2020 QUIC charter, but it IS mentioned in 

As you might have noticed there have been some changes to not be specific saying
HTTP/2 which is no longer correct with the choice to go on to define HTTP/3. The
easier fix rather than trying to define what HTTP/3 is in detail, instead we
have chosen to describe it simply as a mapping of the HTTP semantics onto the
QUIC protocol. This makes the ongoing work to be in charter. 

So are you primarily concerned that we are not explicitly saying that the HTTP
sematinc mapping on QUIC is called HTTP/3? Or is it that we don't define what
HTTP/3 is from a work scope perspective more detailed? 

> This paragraph ^ was inserted to say "the way Google QUIC happens to work in
> 2016" (which was the only QUIC we had) "isn't binding on the working group
> producing IETF QUIC". That was worth saying in 2016 - and we might have said
> it more clearly - but in 2020, the obvious meaning of "current protocol
> mechanisms" is IETF QUICv1. I don't think this paragraph means anything
> helpful now, and anyone who tries to be guided by it, is probably headed into
> the weeds. I'd delete it. 

Yes, I agree that it is reasonable to remove it without any impact to the WG way
of working. 

> Just making sure I understand - the load balancing advice would be included in
> this statement, is that right? 

Yes, or we add an additional milestone if this is a seperate document. It is not
100% clear, and I am happy to leave this to the WG. 

> >   Dec 2021 - Multipath extension document to IESG

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: Spencer Dawkins at IETF <[email-masked]>
Date: Wed, 12 Feb 2020 19:56:42 -0600

Hi, Magnus,

Thanks for the clues. Inline (and deleting stuff that makes sense to me
now).

On Wed, Feb 12, 2020 at 4:03 AM Magnus Westerlund <
[email-masked]> wrote:

> was

I'm primarily concerned that it's unnecessarily obscure, who's working on
HTTP/3. You might think that you'd know that from looking at the QUIC
charter :-)

But let me try this thinking on - it's only unnecessarily obscure for as
long as QUIC is operating on this charter. So, if (making this up) the next
charter happens in six months, well, that's not so bad ... and with the
next charter, HTTP/3 moves off to HTTPbis anyway.

Does that sound about right to you?

Best,

Spencer