Subject: [QUIC] Charter dates

From: Ted Hardie <[email-masked]>
Date: Fri, 3 Jun 2016 10:08:48 -0700

Howdy,

The ADs asked the proponents a questions about the values of N associated
with the various places in the charter where we have a chartering + N line
in the milestones.  Here's a strawman set of values; comments on whether it
is the right order are probably stage one.  They are a bit aggressive, but
then we're an optimistic bunch around here, right?

Ted

## Milestones

* Chartering + 3 Months: Working group adoption of Core Protocol document
* Chartering + 3 Months: Working group adoption of Loss detection and
Congestion Control document
* Chartering + 3 Months: Working group adoption of TLS 1.3 mapping document
* Chartering + 6 Months: Working group adoption of HTTP/2 mapping document
* Chartering + 6 Months: Working group adoption of Multipath extension
document
* Chartering + 12 Months: Core Protocol document to IESG
* Chartering + 12 Months: Loss detection and Congestion Control document to
IESG
* Chartering + 12 Months: TLS 1.3 Mapping document to IESG
* Chartering + 18 Months: HTTP/2 mapping document to IESG
* Chartering + 18 Months: Multipath extension document to IESG
* Rechartering + 3 Months: Working group adoption of FEC extension document
* Rechartering + 12 Months: FEC extension document to IESG

---

From: Göran Eriksson AP <[email-masked]>
Date: Fri, 3 Jun 2016 17:55:55 +0000

>* Chartering + 6 Months: Working group adoption of Multipath extension

Hi ted,

Which document addresses HTTP/2 mapping on Multipath? or is that
out-of-scope?

Regards
Göran

>* Chartering + 12 Months: Loss detection and Congestion Control document
>to IESG

---

From: Ted Hardie <[email-masked]>
Date: Fri, 3 Jun 2016 13:26:29 -0700

Hi Göran,

On Fri, Jun 3, 2016 at 10:55 AM, Göran Eriksson AP <
[email-masked]> wrote:

> I think that it is in scope, since we want a demonstration that the
multipath extension was useful. The reliability/mobility aspects of
multipath I would expect to be covered in the extensions document.  If
there were load-sharing optimizations that related to a specific
application, I would expect them to be the application's mapping doc.  I
could see adding a third doc, if the considerations got particularly large,
but I don't see a reason for that at the moment.

That's just my take on it, by the way, and if you have a different split in
mind, please feel free to bring it forward,

regards,

Ted

---

From: Göran Eriksson AP <[email-masked]>
Date: Fri, 3 Jun 2016 21:16:25 +0000

Hi Ted,

Inlne

regards
Göran

On 03/06/16 22:26, "Ted Hardie" <[email-masked]> wrote:

>multipath I would expect to be covered in the extensions document.

I interpret this to mean that reliability/mobility aspects of multi path
has no impact on HTTP/2 mapping. It would seem to me as if you have a
particular realization of multipath reliability/mobility in mind. I have
not reached that point yet. I could for instance see how the newly
proposed HTTP extension Client Hints, e.g. DL (Downlink rate/network
quality), could be used to convey client side information useful for
sender side selection of path (but that is just an example).

>If there were load-sharing optimizations that related
> to a specific application, I would expect them to be the application's
>mapping doc.  I could see adding a third doc, if the considerations got
>particularly large, but I don't see a reason for that at the moment.
>
>
>That's just my take on it, by the way, and if you have a different split
>in mind, please feel free to bring it forward,

Thanks. Having read your thinking I believe this is a good start. The
discussion until and at Berlin will I am sure clarify if there are
considerations enough, such as need for new or changed HTTP extensions,
for a specific HTTP/2 on multipath quic doc.

Best Regards
Göran

---

From: Jana Iyengar <[email-masked]>
Date: Fri, 3 Jun 2016 14:58:05 -0700

Göran,

> sender side selection of path (but that is just an example).

This extension is about defining the transport mechanisms necessary for
multipath in QUIC, which is entirely independent of path selection or
scheduling mechanisms. This is the equivalent of MPTCP's or SCTP's
definition of multipath; both of these describe protocol mechanisms to
enable use of multiple paths, but do not specify a path selection or
scheduling mechanism.

> for a specific HTTP/2 on multipath quic doc.

Right -- an HTTP/2 on QUIC multipath could be, in theory, an addition to
the QUIC multipath extension. I would argue against adding it now for the
early work, but that's just my thinking.

- jana

> _______________________________________________
> QUIC mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/quic
>

---

From: Göran Eriksson AP <[email-masked]>
Date: Sat, 4 Jun 2016 06:43:41 +0000

Hi Jana,

>early work, but that's just my thinking.

Yes, still too early to decide. And it may be that 3rd doc that is needed.
1 HTTP/2 on QUIC
2 QUIC Multipath extensions
3 HTTP/2 and MPQUIC extension

I think the HTTPBis group has some thinking to do here about the impact of
multipath, just as other ³application² groups and I guess(!) that will
be/is ongoing in parallel to the QUIC work, :-).

I am good for now and look forward to Berlin!

Regards
Göran

---

From: Mark Nottingham <[email-masked]>
Date: Sat, 4 Jun 2016 19:33:42 +1000

My .02 -

Do people really believe that the core document can be done in 9 months? H2 took two years, and that was a pretty aggressive schedule. 

I think it's important to have a set of deadlines that people can agree to as goals. If the milestones are widely viewed as unrealistic, there effectively isn't any pressure to finish, and it can easily blow out to endless discussion and iteration. 

OTOH if the WG can get consensus to meet its milestones, that can be effective in moving things forward; this is how we did H2. But, it requires achievable milestones.

Also, why "Chartering + 3 months" for adoption of the starting documents? What will the WG be doing for those three months?

Lastly for now, what are peoples' expectations for Interim meetings? Again drawing on the experience with H2, we held them pretty often (by IETF standards); seven of them in those two years. IMHO meeting an aggressive schedule like this requires a high frequency of F2F meeting (and I note the new IESG statements on this topic with a bit of concern).

Cheers,

> On 4 Jun 2016, at 3:08 AM, Ted Hardie <[email-masked]> wrote:
> 
> Howdy,
> 
> The ADs asked the proponents a questions about the values of N associated with the various places in the charter where we have a chartering + N line in the milestones.  Here's a strawman set of values; comments on whether it is the right order are probably stage one.  They are a bit aggressive, but then we're an optimistic bunch around here, right?
> 
> Ted
> 
> ## Milestones
> 
> * Chartering + 3 Months: Working group adoption of Loss detection and Congestion Control document
> * Chartering + 6 Months: Working group adoption of Multipath extension document
> * Chartering + 12 Months: Loss detection and Congestion Control document to IESG

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

---

From: Michael Tuexen <[email-masked]>
Date: Sat, 4 Jun 2016 14:04:08 +0200

> On 04 Jun 2016, at 11:33, Mark Nottingham <[email-masked]> wrote:
> 
> My .02 -
> 
Just another data pointer. When SIGTRAN developed SCTP, the first WG document was submitted on February 1, 1999:
https://tools.ietf.org/html/draft-ietf-sigtran-mdtp-00
It substantially changed to
https://tools.ietf.org/html/draft-ietf-sigtran-sctp-00
in September 23, 1999
The final ID was submitted on
July 11th, 2000
https://tools.ietf.org/html/draft-ietf-sigtran-sctp-13
and it became an RFC in
October 2000.
Please note that the protocol changed completely within this process. If you just consider the
time from September 1999 to July 2000, you might and up in the 9 month order.
However, this means that you don't expect substantial protocol changes.
> Also, why "Chartering + 3 months" for adoption of the starting documents? What will the WG be doing for those three months?
You either want to start with the existing QUIC ID, in which case you don't need 3 month, or you want
to pick a candidate from a pool. Then you might need some time doing so, based on some requirements
you have. This was done in the SIGTRAN case by looking at requirements first.

Best regards
Michael

---

From: "Salz, Rich" <[email-masked]>
Date: Mon, 6 Jun 2016 20:24:09 +0000

Mark brings up an interesting point that I had not realized:

> If the milestones are widely viewed as unrealistic, there effectively
> isn't any pressure to finish, and it can easily blow out to endless discussion
> and iteration.

If you try to be *too* aggressive it's worse than not putting any pressure at all.  That's counter-intuitive.  Call it the "freakonomics" insight on milestones.

I'd like to see some revisions based on that, and other parts of his feedback too.
--  
Senior Architect, Akamai Technologies
IM: [email-masked] Twitter: RichSalz

---

From: Ted Hardie <[email-masked]>
Date: Mon, 6 Jun 2016 15:17:19 -0700

A couple of replies, just my own opinion.

On Sat, Jun 4, 2016 at 2:33 AM, Mark Nottingham <[email-masked]> wrote:

> My .02 -
>
> Do people really believe that the core document can be done in 9 months?
> H2 took two years, and that was a pretty aggressive schedule.
>
> I think it's important to have a set of deadlines that people can agree to
> as goals. If the milestones are widely viewed as unrealistic, there
> effectively isn't any pressure to finish, and it can easily blow out to
> endless discussion and iteration.
>
> OTOH if the WG can get consensus to meet its milestones, that can be
> effective in moving things forward; this is how we did H2. But, it requires
> achievable milestones.
>
>
If I can ask you to focus on the H2 mapping document, if we were starting
from the current doc, what do you think an achievable milestone would be
from adoption of a split document to IESG submission?

> Also, why "Chartering + 3 months" for adoption of the starting documents?
> What will the WG be doing for those three months?
>
> Personally, I'm assuming that there will be some discussion of the
starting documents when they are still draft-individual-xx; that would
occur on the mailing list during/just after the IESG activity for
chartering.  I'd assume that folding any changes that come up during that
section of time would occur before the adoption of them as
draft-ietf-wg-xx.  Obviously, you could run this the other way and adopt
draft-individual as-is and republish as a draft-wg before the substantive
changes start; prior to the "replaces" function in the tracker, I would
have suggested that.  Having a three-month window allows you to do it
either way, but this is definitely one I see as "no later than".

> Lastly for now, what are peoples' expectations for Interim meetings?

Again drawing on the experience with H2, we held them pretty often (by IETF
> standards); seven of them in those two years. IMHO meeting an aggressive
> schedule like this requires a high frequency of F2F meeting (and I note the
> new IESG statements on this topic with a bit of concern).
>
> I think it requires a high frequency of interim meetings, but I personally
fall more on the "many virtuals, some F2F" side of the spectrum.  So it
might run to 7 in a single year, but only 1 additional face to face.  A lot
really depends on where the controversies lie and what needs to be done to
reach consensus; I don't think any one map is always right.

As I said, just my thinking,

Ted

> > The ADs asked the proponents a questions about the values of N
> associated with the various places in the charter where we have a
> chartering + N line in the milestones.  Here's a strawman set of values;
> comments on whether it is the right order are probably stage one.  They are
> a bit aggressive, but then we're an optimistic bunch around here, right?
> >
> > Ted
> >
> > ## Milestones
> >

---

From: Mark Nottingham <[email-masked]>
Date: Tue, 7 Jun 2016 12:02:55 +1000

> On 7 Jun 2016, at 8:17 AM, Ted Hardie <[email-masked]> wrote:
> 
[...]

> Personally, I'm assuming that there will be some discussion of the starting documents when they are still draft-individual-xx; that would occur on the mailing list during/just after the IESG activity for chartering.  I'd assume that folding any changes that come up during that section of time would occur before the adoption of them as draft-ietf-wg-xx.  Obviously, you could run this the other way and adopt draft-individual as-is and republish as a draft-wg before the substantive changes start; prior to the "replaces" function in the tracker, I would have suggested that.  Having a three-month window allows you to do it either way, but this is definitely one I see as "no later than".

OK. Personally, if the charter nominated a specific set of documents as a starting point, I'd make -00 a carbon copy of them on day 1, and immediately start gathering issues on them. I don't think "replaces" changes things that much.

[...]

> I think it requires a high frequency of interim meetings, but I personally fall more on the "many virtuals, some F2F" side of the spectrum.  So it might run to 7 in a single year, but only 1 additional face to face.  A lot really depends on where the controversies lie and what needs to be done to reach consensus; I don't think any one map is always right.

Generally agreed. Personally -- and I want to emphasise that -- I think that having good F2F meetings early in the process is critical when there are diverse communities and opposing viewpoints, because it helps socialise people and their perspectives. They need to be F2F and it's vastly preferable that they're interim, since IETF weeks have so many other distractions.

Cheers,

---

From: Ian Swett <[email-masked]>
Date: Mon, 6 Jun 2016 22:13:32 -0400

Thanks Mark, I support both of your suggestions and would be willing to
attend as many F2F meetings as we can organize.

On Mon, Jun 6, 2016 at 10:02 PM, Mark Nottingham <[email-masked]> wrote:

> OK. Personally, if the charter nominated a specific set of documents as a
> starting point, I'd make -00 a carbon copy of them on day 1, and
> immediately start gathering issues on them. I don't think "replaces"
> changes things that much.
>
> [...]
>
> > I think it requires a high frequency of interim meetings, but I
> personally fall more on the "many virtuals, some F2F" side of the
> spectrum.  So it might run to 7 in a single year, but only 1 additional
> face to face.  A lot really depends on where the controversies lie and what
> needs to be done to reach consensus; I don't think any one map is always
> right.
>
> Generally agreed. Personally -- and I want to emphasise that -- I think
> that having good F2F meetings early in the process is critical when there
> are diverse communities and opposing viewpoints, because it helps socialise
> people and their perspectives. They need to be F2F and it's vastly
> preferable that they're interim, since IETF weeks have so many other
> distractions.
>
> Cheers,
>
>
> --

---

From: Jana Iyengar <[email-masked]>
Date: Mon, 6 Jun 2016 23:59:03 -0700

A few thoughts, as I catch up on this thread:

- I do not have a strong opinion on the Charter + 3 months on adoption of
-00 documents. I can see that having a 3-month window allows for any
delays, just in case there is discussion, but if we adopt the feeder
individual documents as -00 on day 1, then we just met the deadline early.
I see the work on the documents as having starter as soon as the Charter is
adopted anyways.

- IMO, the document deadlines are a bit too aggressive. I'd love to get the
core documents done within 1 year, but going by our track-record with
HTTP/2, which took 2 years, and MPTCP, which took 5 years, the current
deadlines seem too aggressive.

- I'd like to suggest that we push the beginning of the multipath work to
later in the cycle, to allow for the core documents to make progress before
we add another document in the mix.

Based on these thoughts, I'll suggest the following changes:
* Chartering + 12 Months: Working group adoption of Multipath extension
document
* Chartering + 18 Months: Core Protocol document to IESG
* Chartering + 18 Months: Loss detection and Congestion Control document to
IESG
* Chartering + 18 Months: TLS 1.3 Mapping document to IESG
* Chartering + 24 Months: HTTP/2 mapping document to IESG
* Chartering + 30 Months: Multipath extension document to IESG

I agree that we should have more interims especially in the first year. I
also agree with Mark's sentiment that we should try to do more F2F meetings
in the first year as well.

- jana

---

From: Ted Hardie <[email-masked]>
Date: Tue, 7 Jun 2016 09:42:02 -0700

Jana, do you want to put this in a PR, so we can track this suggestion
against the current text?

I'd like to get a sense of what update to make prior to the BoF call on
Friday.  My current sense is that, while there is some discussion of the
chartering + 3 milestones, the basic conclusion is that this is
more-or-less a style issue.  I propose we leave the resolution to the ADs,
and adopt either approach they prefer.

For the other milestones, there are two basic suggestions:  move the dates
out in the strawman PR https://github.com/IETF-QUIC/Charter/pull/6/files by
6 to 12 months (but leave the ordering); re-order so that multipath shifts
later (as per Jana's message above).

It also seems like there is general agreement that virtual meetings will be
needed to make this pace work.  I think we should probably say that in the
charter, with something like "In order to achieve the milestones set out
below, the group expects to make extensive use of interim meetings,
especially in its first year".  Would that make sense to people, inserted
just above the milestones?

Ted

On Mon, Jun 6, 2016 at 11:59 PM, Jana Iyengar <[email-masked]> wrote:

> - IMO, the document deadlines are a bit too aggressive. I'd love to get
> the core documents done within 1 year, but going by our track-record with
> * Chartering + 18 Months: Loss detection and Congestion Control document
> to IESG
>>> OK. Personally, if the charter nominated a specific set of documents as
>>> a starting point, I'd make -00 a carbon copy of them on day 1, and

---

From: Jana Iyengar <[email-masked]>
Date: Tue, 7 Jun 2016 10:32:30 -0700

> against the current text?

Done. (https://github.com/IETF-QUIC/Charter/pull/7)

> out in the strawman PR https://github.com/IETF-QUIC/Charter/pull/6/files
> by 6 to 12 months (but leave the ordering); re-order so that multipath
> shifts later (as per Jana's message above).
>
> It also seems like there is general agreement that virtual meetings will
> be needed to make this pace work.  I think we should probably say that in
> the charter, with something like "In order to achieve the milestones set
> out below, the group expects to make extensive use of interim meetings,

Sounds good to me.

- jana