Re: WG Review: QUIC (quic)

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.