Subject: Adoption of the Applicability and Manageability Statements

From: Mark Nottingham <[email-masked]>
Date: Wed, 7 Jun 2017 13:50:21 +0200

In Chicago, we discussed these two documents:

  https://datatracker.ietf.org/doc/draft-kuehlewind-quic-applicability/
  https://datatracker.ietf.org/doc/draft-kuehlewind-quic-manageability/

... and there was general support in the room for adopting them to meet our chartered deliverable in this area.

Please comment on-list if you have concerns or wish to express further support; barring any showstoppers, we'll adopt them.

Regards,

--
Mark Nottingham   https://www.mnot.net/

---

From: Eliot Lear <[email-masked]>
Date: Wed, 7 Jun 2017 14:26:45 +0200

Hi Marc,

Referring just to this draft:

>   https://datatracker.ietf.org/doc/draft-kuehlewind-quic-applicability/

I'm fine with this as being adopted.

I would point out as a comment, however, that Section 4 is entitled
"Stream versus Flow Multicasting", where that is the first and last use
of the term "Flow".  The text that follows in Section 4 seems to compare
"Flow" to transport connections, and I suspect that a title change for
that section is in order, rather an an exploration into what a flow is
in this context.

Eliot

---

From: "Philipp S. Tiesel" <[email-masked]>
Date: Wed, 14 Jun 2017 11:41:06 +0200

> that section is in order, rather an an exploration into what a flow is

I think “Flow” makes sense in this context as it is more general and 
analogous to  the definition of IPv6 flow labels in RFC 6437 and
its discussion on flow vs. 5-tupel.

I see this uncertainty of flow vs. association vs. connection vs. 
stream arise in many contexts at the moment and try to put this into
a draft (not sure yet what the right for that one scope will be).

AVE!
  Philipp S. Tiesel / phils…

---

From: Eliot Lear <[email-masked]>
Date: Wed, 14 Jun 2017 09:50:18 -0700

Hi Philipp,

If that's what the document is intending it should say so, but I don't
think it is.  See below.  Also, I made a mistake down below.  Sorry I
was in a rush (I was also on a small interface), but I gleaned that what
was really being discussed was stream versus connection MULTIPLEXING
(good heavens, did I fat finger).

Section 4 reads:

>    QUIC's stream multiplexing feature allows applications to run
>    multiple streams over a single connection, without head-of-line
>    blocking between streams, associated at a point in time with a single
>    five-tuple.  Streams are meaningful only to the application; since
>    stream information is carried inside QUIC's encryption boundary, no
>    information about the stream(s) whose frames are carried by a given
>    packet is visible to the network.
>
>    Stream multiplexing is not intended to be used for differentiating
>    streams in terms of network treatment.  Application traffic requiring
>    different network treatment SHOULD therefore be carried over
>    different five-tuples (i.e.  multiple QUIC connections).  Given
>    QUIC's ability to send application data on the first packet of a
>    connection (if a previous connection to the same host has been
>    successfully established to provide the respective credentials), the
>    cost for establishing another connection are extremely low.

I think, and Mirja should really correct me if I'm wrong, that the point
if this text is this:

If you want differentiated treatment by the network, separate via
5-tuples and do not expect the network to tease out QUIC streams for
separate treatment.

That would be a statement with which I would strongly agree, as the
physics of the situation would tend to support it.

Eliot

---

From: "Philipp S. Tiesel" <[email-masked]>
Date: Wed, 14 Jun 2017 21:43:15 +0200

Hi Eliot,

I totally agree regarding the take away "If you want differentiated treatment by the network, separate via 5-tuples”.

For me the only dispute was wether “Flow” is the right term in the heading.
I think so as the network should forward all packet of one flow the same.
So if you want different handling for your streams, put streams in a different flow.
Different flow means different 5-tupel for UDP.

The complexity of the argumentation of Section 4 (as I read it) has the purpose
to make one thing clear: There is no need to expose anything about the streams to enable someone
to do something different on streams in some middelbox. If you want different treatment, use separate QUIC connections.

> On 14. Jun 2017, at 18:50, Eliot Lear <[email-masked]> wrote:
> 
> Hi Philipp,
> 
> If that's what the document is intending it should say so, but I don't think it is.  See below.  Also, I made a mistake down below.  Sorry I was in a rush (I was also on a small interface), but I gleaned that what was really being discussed was stream versus connection MULTIPLEXING (good heavens, did I fat finger).
> 
> Section 4 reads:
> 
> 
> I think, and Mirja should really correct me if I'm wrong, that the point if this text is this:
> 
> If you want differentiated treatment by the network, separate via 5-tuples and do not expect the network to tease out QUIC streams for separate treatment.
> 
> That would be a statement with which I would strongly agree, as the physics of the situation would tend to support it.
> 
> Eliot
> 

AVE!
  Philipp S. Tiesel / phils…
-- 
   {phils}--->---([email-masked])--->---(http://phils.in-panik.de)----,
      wenn w eine   aube ist dn      man au dran dre en                   |
           o     Schr        an muss     hc         h   (Kurt Schwitters) |
:wq!  <----(phone: +49-179-6737439)---<---(jabber: [email-masked])----'

---

From: Mark Nottingham <[email-masked]>
Date: Fri, 16 Jun 2017 16:14:35 +1000

Adopted.

> On 7 Jun 2017, at 9:50 pm, Mark Nottingham <[email-masked]> wrote:
>