Re: WG Review: QUIC (quic)

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

On Mon, Feb 10, 2020 at 10:40 PM Giorgio Zoppi <giorgio.zoppi@gmail.com>
wrote:

> 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 (<
> spencerdawkins.ietf@gmail.com>) escribió:
>
>> Dear IESG,
>>
>> I don't have any concerns about the direction for this charter, but I do
>> have some suggestions on wording.
>>
>> Best,
>>
>> Spencer
>>
>> On Fri, Feb 7, 2020 at 11:16 AM The IESG <iesg-secretary@ietf.org> wrote:
>>
>>> 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 (iesg@ietf.org) by
>>> 2020-02-17.
>>>
>>> QUIC (quic)
>>> -----------------------------------------------------------------------
>>> Current status: Active WG
>>>
>>> Chairs:
>>>   Mark Nottingham <mnot@mnot.net>
>>>   Lars Eggert <lars@eggert.org>
>>>   Lucas Pardue <lucaspardue.24.7@gmail.com>
>>>
>>> Assigned Area Director:
>>>   Magnus Westerlund <magnus.westerlund@ericsson.com>
>>>
>>> Transport Area Directors:
>>>   Mirja Kühlewind <ietf@kuehlewind.net>
>>>   Magnus Westerlund <magnus.westerlund@ericsson.com>
>>>
>>> Mailing list:
>>>   Address: quic@ietf.org
>>>   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:
>>>
>>
>> I'm wondering when these change from goals to attributes, but maybe the
>> next major revision is the right time ...
>>
>>
>>>  - 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
>>>
>>
>> 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.
>>
>>
>>> 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.
>>>
>>
>> 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/.
>>
>>
>>> 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.
>>>
>>
>> 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.
>>
>>
>>> 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
>>>
>>
>> Just making sure I understand - the load balancing advice would be
>> included in this statement, is that right?
>>
>>   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
>>>
>>>
>>> _______________________________________________
>>> IETF-Announce mailing list
>>> IETF-Announce@ietf.org
>>> https://www.ietf.org/mailman/listinfo/ietf-announce
>>>
>>
>
> --
> Life is a chess game - Anonymous.
>