Subject: [QUIC] Does charter-ietf-quic-00-04 need to be on this week's telechat agenda?

From: Spencer Dawkins at IETF <[email-masked]>
Date: Wed, 14 Sep 2016 10:49:56 -0500

Dear IESG,

We've resolved Benoit's Block on sending the QUIC charter for External
Review, so it has enough positions to pass, but we've made quite a few
changes since most of you balloted Yes or No Objection.

Does anyone need this to come back as a returning item, or should I just
send an Approved for External Review e-mail to IESG Secretary and get this
out for community review?

Thanks,

Spencer

p.s. Just to summarize the changes I made for 00-04 (at
https://datatracker.ietf.org/doc/charter-ietf-quic/), they are:

I rearranged the contents of the first paragraph, which didn't seem like it
would age well (it described the situation before the BOF, which will be
less accurate every year that follows), but didn't change anything that
wasn't editorial.

I flipped the order of "testing and development" to "development and
testing" (I've worked on some "testing and development" projects, and they
weren't pretty).

I worked through the proposals several people made for Joel's definition of
manageability, and since that text was now longer than the text about the
core protocol itself, moved it down to the fifth focus area, where is where
it will appear in a document anyway.

I renamed the "Applicability Statement" to be "Applicability and
Manageability Statement", at Stephen's suggestion, and made the
corresponding changes in the milestones.

---

From: Stephen Farrell <[email-masked]>
Date: Wed, 14 Sep 2016 17:16:47 +0100

From my POV, that version is good.

I think it'd be fine to go now to external review, so
no need for it to come back to the IESG before that's
happened.

Thanks,
S.

---

From: "Eggert, Lars" <[email-masked]>
Date: Wed, 14 Sep 2016 16:24:32 +0000

Quick question on this sentence:
> The QUIC protocol need not be defined to
> enable each of these abilities in the same way they are presently enabled for
> TCP, but the working group must consider the tradeoffs between manageability and
> other goals.
I can understand "need not be defined in the same way" to mean "need not be defined *at all*" or "need not be defined in the same way *but* need to be defined".

Is the intent here the latter, i.e., are we requiring QUIC to support all management abilities currently possible with TCP (of which the charter text only hints at a few)?

If the intent is the former, it would be good to make it explicit that the group may decide to not support some currently possible management abilities.

In any case, the text should talk about what's enabled for *TLS over TCP*, because we surely don't want to require QUIC to support DPI-based abilities that are possible with unencrypted TCP?

Lars

---

From: Spencer Dawkins at IETF <[email-masked]>
Date: Wed, 14 Sep 2016 11:42:05 -0500

Hi, Lars,

On Wed, Sep 14, 2016 at 11:24 AM, Eggert, Lars <[email-masked]> wrote:

> I can understand "need not be defined in the same way" to mean "need not
> be defined *at all*" or "need not be defined in the same way *but* need to
> be defined".
>
> Is the intent here the latter, i.e., are we requiring QUIC to support all
> management abilities currently possible with TCP (of which the charter text
> only hints at a few)?
>

I'd bet that coming up with a complete list of what people do today would
be a challenge, all by itself.

> If the intent is the former, it would be good to make it explicit that the
> group may decide to not support some currently possible management
> abilities.

I read "must consider the tradeoffs" to not require that all management
abilities currently possible be supported (if that's not true, there is no
tradeoff to consider, right)?

But that wasn't clear to you. Can you propose text?

> In any case, the text should talk about what's enabled for *TLS over TCP*,
> because we surely don't want to require QUIC to support DPI-based abilities
> that are possible with unencrypted TCP?

You're on to something here, but trying to make that distinction during
External Review seems to me, to be falling down the rat-hole of people
doing DPI with unencrypted TCP who can't do DPI when endpoints turn on TLS,
or switch to SCTP/DTLS/UDP as in WebRTC, or end up with opportunistic
encryption as in TCPINC, or ... you see what I mean. See
https://datatracker.ietf.org/doc/draft-nrooney-marnew-report/ for the
two-day version ...

I'd be comfortable with "in the same way they are presently enabled"
dropping the mention of TCP, which might sidestep that particular rat-hole.

And to be blunt, we haven't come up with a good response to the concerns
GSMA expressed at the MaRNEW workshop, and I think we should try harder,
but I really don't want to import a PLUS discussion into QUIC charter
review.

But please let me know what you think.

Spencer

---

From: Mirja Kühlewind <[email-masked]>
Date: Wed, 14 Sep 2016 18:41:08 +0200

+1

---

From: "Ben Campbell" <[email-masked]>
Date: Wed, 14 Sep 2016 12:43:52 -0400

> no need for it to come back to the IESG before that's

I agree.

---

From: joel jaeggli <[email-masked]>
Date: Wed, 14 Sep 2016 11:44:26 -0700

On 9/14/16 9:42 AM, Spencer Dawkins at IETF wrote:
> Hi, Lars,
>
> On Wed, Sep 14, 2016 at 11:24 AM, Eggert, Lars <[email-masked]
> <mailto:[email-masked]>> wrote:
>
>     I can understand "need not be defined in the same way" to mean
>     "need not be defined *at all*" or "need not be defined in the same
>     way *but* need to be defined".
>
>     Is the intent here the latter, i.e., are we requiring QUIC to
>     support all management abilities currently possible with TCP (of
>     which the charter text only hints at a few)?
>
>
> I'd bet that coming up with a complete list of what people do today
> would be a challenge, all by itself.
>  
>
>     If the intent is the former, it would be good to make it explicit
>     that the group may decide to not support some currently possible
>     management abilities.
>
>
> I read "must consider the tradeoffs" to not require that all
> management abilities currently possible be supported (if that's not
> true, there is no tradeoff to consider, right)?
>
I think these are considerations not requirements. I'm unconvinced that
manageability considerations are trade-offs anymore than responsiveness
to congestion is a trade-off with being first in line.
>     In any case, the text should talk about what's enabled for *TLS
>     over TCP*, because we surely don't want to require QUIC to support
>     DPI-based abilities that are possible with unencrypted TCP?
>
As far as I'm concerned unecrypted tcp shouldn't really be a thing that
exists outside the confines of relatively narrow use cases. the cases
where it is generally appropriate for "web traffic" are  effectively
nonexistent.
> You're on to something here, but trying to make that distinction
> during External Review seems to me, to be falling down the rat-hole of
> people doing DPI with unencrypted TCP who can't do DPI when endpoints
> turn on TLS, or switch to SCTP/DTLS/UDP as in WebRTC, or end up with
> opportunistic encryption as in TCPINC, or ... you see what I mean. See
> And to be blunt, we haven't come up with a good response to the
> concerns GSMA expressed at the MaRNEW workshop, and I think we should
> try harder, but I really don't want to import a PLUS discussion into
> QUIC charter review.
>

---

From: Spencer Dawkins at IETF <[email-masked]>
Date: Wed, 14 Sep 2016 14:03:28 -0500

Hi, Joel,

> to congestion is a trade-off with being first in line.

Somethere among the 33 or so e-mails in the thread on Benoit's BLOCK, you
said

These consideration weren't actually requirements of the design of the
ip protocol stack though the ability to implement them at least
initially comes as a consequence of it's design. we're better off if as
the operators of end systems if we don't lose access to functions on
which we have come to depend without at least having a serious
discussion about them first.

I think that sounds about right.

I'll try to express that in a 00-05 revision (as soon as I ballot a few
more docs on tomorrow's telechat agenda), if I can figure out how do that
without having to precisely define "a serious discussion" :-)

> where it is generally appropriate for "web traffic" are  effectively

Thanks for this, too.

Spencer

---

From: Stephen Farrell <[email-masked]>
Date: Wed, 14 Sep 2016 22:21:40 +0100

> where it is generally appropriate for "web traffic" are  effectively

Excellent sentiment.

S.

---

From: Spencer Dawkins at IETF <[email-masked]>
Date: Wed, 14 Sep 2016 21:32:30 -0500

Dear All,

> > where it is generally appropriate for "web traffic" are  effectively

Joel, thanks for your help in working through this part of the charter.

I just submitted charter-ietf-quic-00-05, in which I'm trying to thread the
needle between tradeoffs and requirements, as considerations. The easiest
place to see these changes is using
https://datatracker.ietf.org/doc/charter-ietf-quic/history/.

I reworked the text we've been discussing, so that it now says

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 in the same way they are presently enabled for TLS 1.3, but
the working group must consider the impact of the protocol on network
management practices, in line with RFC 7258.

In related news, I continued to think about Lars' comment on "not TCP, but
TLS 1.3" for long enough to decide that he's right, so folks will notice
that's also reflected in the new text.

I also made a couple of formatting changes to fix unfortunate line breaks,
and rephrased the ordinal reference to "the third focus area", so that the
new text will survive additions and deletions of focus areas as the charter
is maintained.

I'm almost always eager to hear what people think, as usual :-)

Thanks,

Spencer

---

From: Eric Rescorla <[email-masked]>
Date: Wed, 14 Sep 2016 23:17:58 -0700

I don't feel strongly about this, but ISTM that this text about

"The QUIC protocol need not be defined to enable each of these abilities in
the same way they are presently enabled for TLS 1.3, "
isn't quite right because a lot of these capabilities are relevant at the
TCP layer, not the TLS layer, and as you probably know, TLS is not bound to
any particular transport protocol. I would think that "TLS over TCP" is the
right referent

-Ekr

On Wed, Sep 14, 2016 at 7:32 PM, Spencer Dawkins at IETF <
[email-masked]> wrote:

> Dear All,
>
> On Wed, Sep 14, 2016 at 4:21 PM, Stephen Farrell <
> [email-masked]> wrote:
>
>>
>>
> I just submitted charter-ietf-quic-00-05, in which I'm trying to thread
> the needle between tradeoffs and requirements, as considerations. The
> easiest place to see these changes is using https://datatracker.ietf.org/
> doc/charter-ietf-quic/history/.
>
> _______________________________________________
> QUIC mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/quic
>
>

---

From: Brian Trammell <[email-masked]>
Date: Thu, 15 Sep 2016 09:39:37 +0200

hi Ekr, all,

> On 15 Sep 2016, at 08:17, Eric Rescorla <[email-masked]> wrote:
> 
> "The QUIC protocol need not be defined to enable each of these abilities in the same way they are presently enabled for TLS 1.3, "
> isn't quite right because a lot of these capabilities are relevant at the TCP layer, not the TLS layer, and as you probably know, TLS is not bound to any particular transport protocol. I would think that "TLS over TCP" is the right referent

Agreed completely. (I'll point out that from the point of view of the management functions I think we should care about, the fact that it's TLS running over TCP is completely irrelevant. But yes, we should make sure that it's very clear to everyone we're not talking about supporting addiction-to-plaintext management functions in QUIC: DPI is and remains dead.)

So, rolling this in, and being explicit about Lars' concern, we have:

  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, in line with RFC 7258.

How's that?

Cheers,

Brian

> 
> -Ekr
> 
> 
> On Wed, Sep 14, 2016 at 7:32 PM, Spencer Dawkins at IETF <[email-masked]> wrote:
> Dear All,
> 
> On Wed, Sep 14, 2016 at 4:21 PM, Stephen Farrell <[email-masked]> wrote:
> 
> 
> I just submitted charter-ietf-quic-00-05, in which I'm trying to thread the needle between tradeoffs and requirements, as considerations. The easiest place to see these changes is using https://datatracker.ietf.org/doc/charter-ietf-quic/history/.
> 
> In related news, I continued to think about Lars' comment on "not TCP, but TLS 1.3" for long enough to decide that he's right, so folks will notice that's also reflected in the new text.
> 
> I also made a couple of formatting changes to fix unfortunate line breaks, and rephrased the ordinal reference to "the third focus area", so that the new text will survive additions and deletions of focus areas as the charter is maintained.
>

---

From: "Eggert, Lars" <[email-masked]>
Date: Thu, 15 Sep 2016 07:57:35 +0000

Ship it! Thanks for humoring my pet peeves :-)

---

From: Eliot Lear <[email-masked]>
Date: Thu, 15 Sep 2016 10:28:42 +0200

+1.

---

From: Benoit Claise <[email-masked]>
Date: Thu, 15 Sep 2016 12:10:05 +0200

On 9/15/2016 9:39 AM, Brian Trammell wrote:
>> "The QUIC protocol need not be defined to enable each of these abilities in the same way they are presently enabled for TLS 1.3,"

The latest charter text v5 already addressed my BLOCK concerns, thanks 
to Brian's initial proposal. The additional RFC 7258 is a plus (PLUS? :-) )
The new proposal from Brian is even better.

Regards, Benoit

---

From: Spencer Dawkins at IETF <[email-masked]>
Date: Thu, 15 Sep 2016 07:14:06 -0500

Dear All,

On Thu, Sep 15, 2016 at 5:10 AM, Benoit Claise <[email-masked]> wrote:

>>> "The QUIC protocol need not be defined to enable each of these abilities
>>> in the same way they are presently enabled for TLS 1.3,"
>>> isn't quite right because a lot of these capabilities are relevant at
>>> the TCP layer, not the TLS layer, and as you probably know, TLS is not
>>> bound to any particular transport protocol. I would think that "TLS over
>>> TCP" is the right referent
>>>
>>
Eric, I felt somewhat queasy about the previous text. That's an improvement.

When we start stacking transport protocols, it's harder to clearly refer to
a particular pancake in the stack of pancakes.

Thanks for bringing this up now.

> Agreed completely. (I'll point out that from the point of view of the
>> management functions I think we should care about, the fact that it's TLS
>> running over TCP is completely irrelevant. But yes, we should make sure
>> that it's very clear to everyone we're not talking about supporting
>> addiction-to-plaintext management functions in QUIC: DPI is and remains
>> dead.)
>>
Brian,

It works for me. Thanks for the suggestion.

00-06 is posted with this change. The easiest place for people to see the
changes is at https://datatracker.ietf.org/doc/charter-ietf-quic/history/.

>
> The latest charter text v5 already addressed my BLOCK concerns, thanks to
> Brian's initial proposal. The additional RFC 7258 is a plus (PLUS? :-) )

A chartered QUIC working group will appreciate the charter making that
clearer.

So, I'll likely send the "approved for external review" e-mail to the
secretariat after the IESG telechat today.

Thank you all for your help with this.

Spencer

>>> easiest place to see these changes is using
>>> In related news, I continued to think about Lars' comment on "not TCP,
>>> but TLS 1.3" for long enough to decide that he's right, so folks will
>>> notice that's also reflected in the new text.
>>>
>>> I also made a couple of formatting changes to fix unfortunate line
>>> breaks, and rephrased the ordinal reference to "the third focus area", so
>>> that the new text will survive additions and deletions of focus areas as
>>> the charter is maintained.
>>>

---

From: Jana Iyengar <[email-masked]>
Date: Thu, 15 Sep 2016 09:03:00 -0700

Looks good to me!

On 15-Sep-2016 5:14 AM, "Spencer Dawkins at IETF" <
[email-masked]> wrote:

>>>> "The QUIC protocol need not be defined to enable each of these
>>>> abilities in the same way they are presently enabled for TLS 1.3,"
> When we start stacking transport protocols, it's harder to clearly refer
> to a particular pancake in the stack of pancakes.
>