Subject: New Second Implementation Draft

From: Martin Duke <[email-masked]>
Date: Thu, 20 Jul 2017 11:07:20 -0700

I believe I have distilled the feedback from today's meeting into an
all-new second implementation draft:

https://github.com/quicwg/base-drafts/wiki/Second-Implementation-Draft

Lars/Mark, do we want to discuss again Friday?

Assuming we do, the two pieces of immediate feedback I would like
(pre-meeting) are:
1) Are there any important protocol elements I have failed to mention at
all?
2) Does anyone violently disagree with the category in which I have placed
any of the listed components?

Final point: there is one place where I extrapolated a bit from the
comments in the room: flow/congestion control. I believe what I wrote there
avoids truly ridiculous bursts of data and exercises the flow control
mechanism without trapping us in tricky tuning exercises.

Martin D

---

From: Lucas Pardue <[email-masked]>
Date: Fri, 21 Jul 2017 00:40:28 +0000

Martin,

Thanks for taking the time to refine this, overall I think you’ve captured the mood well. The one bit I think could be improved on is:

> A simple multi-streamed application. This application would ideally leverage a very simple socket API and follow simple logic easily implementable on both client and server. For instance, the client could send data on one stream and the server could echo copies of that on multiple streams. Brian proposed "echo and amplify" and volunteered to write it up.

I appreciate the flexibility but have difficulty in seeing how this would flow through to interop testing, how do we measure success? One possible outcome is interop limited to self-test of “bespoke-simple-app” over QUIC, is that good enough? My preference is to pick a minimal baseline (“echo and amplify” or whatever else) and then additionals are a bonus that is up to external coordination. I think this common baseline could also help towards ongoing consideration for performance or benchmarking, over disparate implementations, as aspects of the protocol evolve or change.

Lucas

From: QUIC [mailto:[email-masked]] On Behalf Of Martin Duke
Sent: 20 July 2017 19:07
To: IETF QUIC WG <[email-masked]>
Subject: New Second Implementation Draft

I believe I have distilled the feedback from today's meeting into an all-new second implementation draft:

Assuming we do, the two pieces of immediate feedback I would like (pre-meeting) are:
1) Are there any important protocol elements I have failed to mention at all?
2) Does anyone violently disagree with the category in which I have placed any of the listed components?

Final point: there is one place where I extrapolated a bit from the comments in the room: flow/congestion control. I believe what I wrote there avoids truly ridiculous bursts of data and exercises the flow control mechanism without trapping us in tricky tuning exercises.

Martin D

---

From: Lucas Pardue <[email-masked]>
Date: Fri, 21 Jul 2017 08:00:50 +0000

The proposal to do HTTP 0.9 GET, discussed in Prague, addresses my concerns.

Lucas

---

From: Martin Thomson <[email-masked]>
Date: Fri, 21 Jul 2017 11:27:21 +0200

Do we need a permanent ALPN token for this?  It seems like a useful
facility to build into stacks that are transport-only.  Maybe "h09q".

On 21 July 2017 at 10:00, Lucas Pardue <[email-masked]> wrote:
> I appreciate the flexibility but have difficulty in seeing how this would
> flow through to interop testing, how do we measure success? One possible
> outcome is interop limited to self-test of “bespoke-simple-app” over QUIC,
> is that good enough? My preference is to pick a minimal baseline (“echo and
> amplify” or whatever else) and then additionals are a bonus that is up to
> external coordination. I think this common baseline could also help towards
> ongoing consideration for performance or benchmarking, over disparate
> implementations, as aspects of the protocol evolve or change.
>
>
>

---

From: Eric Rescorla <[email-masked]>
Date: Fri, 21 Jul 2017 03:47:30 -0700

h09q-05? :)

---

From: Patrick McManus <[email-masked]>
Date: Fri, 21 Jul 2017 12:52:59 +0200

its a good idea that needs a bikeshed. hq-nop would be my preference (stay
in the hq namespace)..

---

From: Mike Bishop <[email-masked]>
Date: Mon, 24 Jul 2017 05:20:50 +0000

I’d follow precedent – http/1.1 is already defined, so why not http/0.9?

I’d also like to mention that my wife is particularly fond of the paint color “Rhino” for the associated bikeshed.  😉

From: QUIC [mailto:[email-masked]] On Behalf Of Patrick McManus
Sent: Friday, July 21, 2017 3:53 AM
To: Eric Rescorla <[email-masked]>
Cc: Lucas Pardue <[email-masked]>; IETF QUIC WG <[email-masked]>; Martin Thomson <[email-masked]>; Martin Duke <[email-masked]>
Subject: Re: New Second Implementation Draft

its a good idea that needs a bikeshed. hq-nop would be my preference (stay in the hq namespace)..

On Fri, Jul 21, 2017 at 12:47 PM, Eric Rescorla <[email-masked]<mailto:[email-masked]>> wrote:
h09q-05? :)

On Fri, Jul 21, 2017 at 2:27 AM, Martin Thomson <[email-masked]<mailto:[email-masked]>> wrote:
Do we need a permanent ALPN token for this?  It seems like a useful
facility to build into stacks that are transport-only.  Maybe "h09q".

---

From: Mike Bishop <[email-masked]>
Date: Tue, 25 Jul 2017 20:03:23 +0000

Just so we’re on the same page – this set of “Second Implementation Draft” targets is for Seattle?  Or some future date?

From: QUIC [mailto:[email-masked]] On Behalf Of Mike Bishop
Sent: Sunday, July 23, 2017 10:21 PM
To: Patrick McManus <[email-masked]>; Eric Rescorla <[email-masked]>
Cc: Lucas Pardue <[email-masked]>; IETF QUIC WG <[email-masked]>; Martin Thomson <[email-masked]>; Martin Duke <[email-masked]>
Subject: RE: New Second Implementation Draft

From: QUIC [mailto:[email-masked]] On Behalf Of Patrick McManus
Sent: Friday, July 21, 2017 3:53 AM
To: Eric Rescorla <[email-masked]<mailto:[email-masked]>>
Cc: Lucas Pardue <[email-masked]<mailto:[email-masked]>>; IETF QUIC WG <[email-masked]<mailto:[email-masked]>>; Martin Thomson <[email-masked]<mailto:[email-masked]>>; Martin Duke <[email-masked]<mailto:[email-masked]>>
Subject: Re: New Second Implementation Draft

---

From: Eric Rescorla <[email-masked]>
Date: Tue, 25 Jul 2017 13:34:39 -0700

On Tue, Jul 25, 2017 at 1:03 PM, Mike Bishop <[email-masked]>
wrote:

> Just so we’re on the same page – this set of “Second Implementation Draft”
> targets is for Seattle?  Or some future date?
>

I had previously understood ID2 to be for Singapore. Given the somewhat
rickety state of the implementations I saw in PRG, I think it might be
better to get them solid in SEA rather than rickety but more full
featured...

-Ekr

>
> *From:* QUIC [mailto:[email-masked]] *On Behalf Of *Mike Bishop
> *Sent:* Sunday, July 23, 2017 10:21 PM
> *To:* Patrick McManus <[email-masked]>; Eric Rescorla <[email-masked]>
> *Cc:* Lucas Pardue <[email-masked]>; IETF QUIC WG <[email-masked]>;
> Martin Thomson <[email-masked]>; Martin Duke <
> [email-masked]>
> *Subject:* RE: New Second Implementation Draft
>
>
>
> I’d also like to mention that my wife is particularly fond of the paint
> color “Rhino” for the associated bikeshed.  😉
>
>
>
> *From:* QUIC [mailto:[email-masked] <[email-masked]>] *On
> Behalf Of *Patrick McManus
> *Sent:* Friday, July 21, 2017 3:53 AM
> *To:* Eric Rescorla <[email-masked]>
> *Cc:* Lucas Pardue <[email-masked]>; IETF QUIC WG <[email-masked]>;
> Martin Thomson <[email-masked]>; Martin Duke <
> [email-masked]>
> *Subject:* Re: New Second Implementation Draft
>
>
>

---

From: Martin Duke <[email-masked]>
Date: Tue, 25 Jul 2017 15:39:07 -0700

I think the ID1 group has to reach consensus they are at the point of
diminishing returns, whenever that may be. If anyone wants to get ahead,
this is the stuff to tackle.

On Tue, Jul 25, 2017 at 1:34 PM, Eric Rescorla <[email-masked]> wrote:

>
> On Tue, Jul 25, 2017 at 1:03 PM, Mike Bishop <[email-masked]
> > wrote:
>
>> Just so we’re on the same page – this set of “Second Implementation
>> Draft” targets is for Seattle?  Or some future date?
>>
>
>> *To:* Patrick McManus <[email-masked]>; Eric Rescorla <[email-masked]
>> >