Re: Proposed Charter Text

[Ian Swett <[e-mail]>]

On Tue, Jan 28, 2020 at 2:04 PM Roberto Peon <[e-mail]> 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.
>
> 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.
>

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" <[e-mail]>
> 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 <[e-mail]> on behalf of Mike Bishop <
>     > [e-mail]>
>     > Date: Monday, January 27, 2020 at 10:06 AM
>     > To: Ian Swett <ianswett=[e-mail]>, Magnus
> Westerlund <
>     > magnus.westerlund=[e-mail]>
>     > Cc: "[e-mail]" <[e-mail]>
>     > 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 <[e-mail]> On Behalf Of Ian Swett
>     > Sent: Monday, January 27, 2020 9:25 AM
>     > To: Magnus Westerlund <magnus.westerlund=
> [e-mail]>
>     > Cc: [e-mail]
>     > 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
>     > 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=[e-mail]> wrote:
>     > > 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
>     > >
>     > > On Mon, 2020-01-27 at 12:22 +0000, Magnus Westerlund 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.
>     > > > Additionally, the Working Group will delivery a mechanism to
> assist load
>     > > > balancers in their handling of QUIC.
>     >
>     >
>     > delivery -> deliver
>     > > >
>     > > > 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.
>     >
>     >
>     > I think the above paragraph should now be removed.
>     >
>     > > >
>     > > > 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]
> <+46%2010%20714%2082%2087>
>     Torshamnsgatan 23           | Mobile [phone]
> <+46%2073%20094%2090%2079>
>     SE-164 80 Stockholm, Sweden | mailto: [e-mail]
>     ----------------------------------------------------------------------
>
>
>
>
>