Subject: [QUIC] Charter dates now in GitHub

From: Ted Hardie <[email-masked]>
Date: Thu, 9 Jun 2016 09:55:53 -0700

I merged Jana's version of the charter dates and added the text about
expecting to make extensive use of interim meetings to the charter here:

https://github.com/IETF-QUIC/Charter/blob/master/quic-charter.md

Obviously, this is subject to further discussion by the IESG, list, and
BoF, but I wanted the strawman discussed so far to be in the doc before
tomorrow's BoF call.

regards,

Ted

---

From: Martin Thomson <[email-masked]>
Date: Sun, 12 Jun 2016 22:59:20 +1000

> After the completion of the core protocol deliverable, the group will consider a recharter [...]

It doesn't need to include any of this stuff.  Part of the point of
leaving something to a recharter is that you don't have to write down
what it is.  That's the joy of it, we could decide to recharter to
compose new Morris dancing tunes.

On 10 June 2016 at 02:55, Ted Hardie <[email-masked]> wrote:
> Obviously, this is subject to further discussion by the IESG, list, and BoF,
> but I wanted the strawman discussed so far to be in the doc before
> tomorrow's BoF call.
>
> regards,
>
> Ted
>
> _______________________________________________
> QUIC mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/quic
>

---

From: Ted Hardie <[email-masked]>
Date: Mon, 13 Jun 2016 08:55:20 -0700

On Sun, Jun 12, 2016 at 5:59 AM, Martin Thomson <[email-masked]>
wrote:

> what it is.

I agree that you don't have to.  The utility in doing so, at least in my
opinion, is that it helps you avoid premature optimizations that might make
the later work harder.  If, for example, you presumed that QUIC would only
support fully reliable communications, you might make choices that would
preclude later work that had partial reliability as a goal.  Given that I
think partial reliability and FEC are real goals here, I'd hate to lose
that. Having them in the charter as goals, but with milestones to be set
"After the completion of the core protocol" would do the same thing, but
other folks hate goals without milestones, so you basically pick your
poison.

That's the joy of it, we could decide to recharter to
> compose new Morris dancing tunes.
http://www.mit.edu/~jcb/AntiMorris/pratchett.shtml

Since it won't be danced properly anyway, let's give that a miss, eh?

Ted

> BoF,

---

From: Martin Thomson <[email-masked]>
Date: Tue, 14 Jun 2016 08:55:56 +0100

On 13 June 2016 at 16:55, Ted Hardie <[email-masked]> wrote:
> The utility in doing so, at least in my opinion, is that it helps you avoid
> premature optimizations that might make the later work harder.  If, for
> example, you presumed that QUIC would only support fully reliable
> communications, you might make choices that would preclude later work that
> had partial reliability as a goal.  Given that I think partial reliability
> and FEC are real goals here, I'd hate to lose that.

If you have constraints on the design that are important, then I
expect you to remember these goals and remind us when we do things
that violate those constraints.  Having things in the charter that
aren't in the charter gives a license to argue about things in a very
non-concrete fashion, which at best is not especially productive, and
at worst can be used to be obstructionist.

Given the high expectations people have for this protocol, we're going
to have a hard enough time agreeing on things.

I actually disagree with you regarding your fears about these
features.  I think that we could very easily deploy a version of QUIC
that didn't have any allowance for partial reliability or FEC.  And I
think that we SHOULD do that.  The reason being is that it gives us a
good reason to have working version and feature negotiation much
earlier in the process.  This doesn't need to be a monolithic protocol
design and development process.  To me, lightweight version and
feature negotiation are more important properties to conserve than
some future feature.

---

From: Christian Huitema <[email-masked]>
Date: Tue, 14 Jun 2016 17:34:42 +0000

On Tuesday, June 14, 2016 12:56 AM, Martin Thomson wrote:
> 
> ...
> I actually disagree with you regarding your fears about these features.  I think
> that we could very easily deploy a version of QUIC that didn't have any
> allowance for partial reliability or FEC.  And I think that we SHOULD do that.
> The reason being is that it gives us a good reason to have working version and
> feature negotiation much earlier in the process.  This doesn't need to be a
> monolithic protocol design and development process.  To me, lightweight
> version and feature negotiation are more important properties to conserve
> than some future feature.

+1.

I think that FEC is an interesting source of thought experiments in that regard. Just saying FEC is nice, but FEC comes in multiple shades. We can have block codes or convolutional codes. In both cases, we can have variable redundancy ratios. We can have self-synchronizing schemes with constant block or cycle length, or we can have variable size blocks. When using more than trivial XOR, we need to negotiate among many formulas to compute the redundancy. I am not saying that we should have all that complexity in the original FEC options. I am just following Martin's suggestion that we want a light weight negotiation process that will enable these options in the future. And we can do the thought experiments at little cost.

By the way, the same is true of multipath. There are many variants. Do we use a single packet sequence number and spread the packets over multiple paths, or do we use a separate sequence number for error detection on each path? In the latter case, do we keep the "flow" space common across all paths? Do we follow the same strategies for load sharing and for reconnections? Again, the negotiation process should enable many options, even if the standard focuses on one.

-- Christian Huitema

---

From: Martin Thomson <[email-masked]>
Date: Fri, 17 Jun 2016 20:12:30 +0100

>> than some future feature.

FWIW, I have created a pull request against the proposed charter that
enacts my proposal.

https://github.com/IETF-QUIC/Charter/pull/10