Subject: Third Implementation Draft Prototype

From: Eric Rescorla <[email-masked]>
Date: Mon, 4 Dec 2017 17:28:19 -0800

Here's my first cut:
https://github.com/quicwg/base-drafts/wiki/Third-Implementation-Draft

---

From: Ian Swett <[email-masked]>
Date: Mon, 4 Dec 2017 20:43:48 -0500

Possibly this is part of "Update to draft-08", but I'd like to explicitly
state we're moving to TLS 1.3 draft 22.

---

From: Marten Seemann <[email-masked]>
Date: Mon, 4 Dec 2017 17:50:29 -0800

How do we transfer the 1 MB file? Can we move away from HTTP 0.9?

On 5. December 2017 at 08:44:16, Ian Swett ([email-masked]) wrote:

---

From: Eric Rescorla <[email-masked]>
Date: Mon, 4 Dec 2017 17:57:56 -0800

Why would we move away from HTTP/0.9 for this.

---

From: Eric Rescorla <[email-masked]>
Date: Mon, 4 Dec 2017 17:59:16 -0800

It is done.

-Ekr

---

From: Martin Duke <[email-masked]>
Date: Tue, 5 Dec 2017 13:19:45 -0800

Isn't timeout-based loss recovery something that goes all the way back to
the 1st implementation draft?

---

From: Eric Rescorla <[email-masked]>
Date: Tue, 5 Dec 2017 13:23:06 -0800

Yes. This is actually demonstrating that it works :) I am trying to be
responsive to the request for clear test cases.

-Ekr

On Tue, Dec 5, 2017 at 1:19 PM, Martin Duke <[email-masked]> wrote:

>>> Possibly this is part of "Update to draft-08", but I'd like to
>>> explicitly state we're moving to TLS 1.3 draft 22.
>>>

---

From: Praveen Balasubramanian <[email-masked]>
Date: Tue, 5 Dec 2017 21:33:32 +0000

How are we going to exercise the “random 10% loss” test case given this is all remote participation?

From: QUIC [mailto:[email-masked]] On Behalf Of Eric Rescorla
Sent: Tuesday, December 5, 2017 1:23 PM
To: Martin Duke <[email-masked]>
Cc: Ian Swett <[email-masked]>; IETF QUIC WG <[email-masked]>
Subject: Re: Third Implementation Draft Prototype

Yes. This is actually demonstrating that it works :) I am trying to be responsive to the request for clear test cases.

-Ekr

On Tue, Dec 5, 2017 at 1:19 PM, Martin Duke <[email-masked]<mailto:[email-masked]>> wrote:
Isn't timeout-based loss recovery something that goes all the way back to the 1st implementation draft?

On Mon, Dec 4, 2017 at 5:59 PM, Eric Rescorla <[email-masked]<mailto:[email-masked]>> wrote:
It is done.

-Ekr

On Mon, Dec 4, 2017 at 5:43 PM, Ian Swett <[email-masked]<mailto:[email-masked]>> wrote:
Possibly this is part of "Update to draft-08", but I'd like to explicitly state we're moving to TLS 1.3 draft 22.

On Mon, Dec 4, 2017 at 8:28 PM, Eric Rescorla <[email-masked]<mailto:[email-masked]>> wrote:
Here's my first cut:
https://github.com/quicwg/base-drafts/wiki/Third-Implementation-Draft<https://na01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Fquicwg%2Fbase-drafts%2Fwiki%2FThird-Implementation-Draft&data=02%7C01%7Cpravb%40microsoft.com%7C4decf03776a0402ccdb108d53c267d08%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C636481058360872322&sdata=JncJCrU5XTECTx3P0uSj2LoBJogmxBZaLGExzZceWqo%3D&reserved=0>

---

From: Eric Rescorla <[email-masked]>
Date: Tue, 5 Dec 2017 13:37:25 -0800

On Tue, Dec 5, 2017 at 1:33 PM, Praveen Balasubramanian <[email-masked]

> all remote participation?

I was more thinking this for MEL.

Lars and I were talking about making a test harness, but that probably
won't be available 12/18.

-Ekr

>
> *From:* QUIC [mailto:[email-masked]] *On Behalf Of *Eric Rescorla
> *Sent:* Tuesday, December 5, 2017 1:23 PM
> *To:* Martin Duke <[email-masked]>
> *Cc:* Ian Swett <[email-masked]>; IETF QUIC WG <[email-masked]>
> *Subject:* Re: Third Implementation Draft Prototype
>
>
>
> <https://na01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Fquicwg%2Fbase-drafts%2Fwiki%2FThird-Implementation-Draft&data=02%7C01%7Cpravb%40microsoft.com%7C4decf03776a0402ccdb108d53c267d08%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C636481058360872322&sdata=JncJCrU5XTECTx3P0uSj2LoBJogmxBZaLGExzZceWqo%3D&reserved=0>
>
>
>
>
>
>
>
>
>

---

From: Praveen Balasubramanian <[email-masked]>
Date: Tue, 5 Dec 2017 21:52:32 +0000

Even for MEL there might be folks participating remotely so we need to figure out a way. Can we have the client side implementations incorporate a knob for doing this on Tx and Rx? Either inline in the QUIC code or as another tool that runs locally. Doing this on server side will be challenging because other “non loss recovery” test cases might be in progress in parallel.

Thanks

From: Eric Rescorla [mailto:[email-masked]]
Sent: Tuesday, December 5, 2017 1:37 PM
To: Praveen Balasubramanian <[email-masked]>
Cc: Martin Duke <[email-masked]>; Ian Swett <[email-masked]>; IETF QUIC WG <[email-masked]>
Subject: Re: Third Implementation Draft Prototype

On Tue, Dec 5, 2017 at 1:33 PM, Praveen Balasubramanian <[email-masked]<mailto:[email-masked]>> wrote:
How are we going to exercise the “random 10% loss” test case given this is all remote participation?

Lars and I were talking about making a test harness, but that probably won't be available 12/18.

-Ekr

From: QUIC [mailto:[email-masked]<mailto:[email-masked]>] On Behalf Of Eric Rescorla
Sent: Tuesday, December 5, 2017 1:23 PM
To: Martin Duke <[email-masked]<mailto:[email-masked]>>
Cc: Ian Swett <[email-masked]<mailto:[email-masked]>>; IETF QUIC WG <[email-masked]<mailto:[email-masked]>>
Subject: Re: Third Implementation Draft Prototype

-Ekr

-Ekr

---

From: "Fossati, Thomas (Nokia - GB/Cambridge, UK)" <[email-masked]>
Date: Tue, 5 Dec 2017 22:44:33 +0000

On Linux, the easiest is probably netem(8).  Server side you can couple it with a filter to match a specific client address or a server port if you plan to run different server instances for different test cases.

On Windows, one possibility seems to be Clumsy (http://jagt.github.io/clumsy/) (I have zero experience with it.)

On Mac, the Network Link Conditioner from Xcode.

Cheers

On 05/12/2017, 21:52, "QUIC on behalf of Praveen Balasubramanian" <[email-masked]<mailto:[email-masked]> on behalf of [email-masked]<mailto:[email-masked]>> wrote:

Thanks

-Ekr

-Ekr

-Ekr

---

From: Patrick McManus <[email-masked]>
Date: Tue, 5 Dec 2017 17:58:08 -0500

those will all work for the immediate use case of "drop 10%", but the more
interesting case will be something like "what happens to flow control when
rst_stream is dropped" and for that you're going to need something quic
specific... maybe a harness with access to keys. It looks like all the
cases ekr chose for the first instance of this test intentionally don't
need to be able to know anything about packet contents to do the dropping
so we can check those off while developing a more sophisticated testing
approach..

On Tue, Dec 5, 2017 at 5:44 PM, Fossati, Thomas (Nokia - GB/Cambridge, UK) <
[email-masked]> wrote:

> On Linux, the easiest is probably netem(8).  Server side you can couple it
> with a filter to match a specific client address or a server port if you
> plan to run different server instances for different test cases.
>
>
>
> On Windows, one possibility seems to be Clumsy (
> http://jagt.github.io/clumsy/) (I have zero experience with it.)
>
>
>
> On 05/12/2017, 21:52, "QUIC on behalf of Praveen Balasubramanian" <
> [email-masked] on behalf of [email-masked]> wrote:
>
>
>
> Even for MEL there might be folks participating remotely so we need to
> figure out a way. Can we have the client side implementations incorporate a
> knob for doing this on Tx and Rx? Either inline in the QUIC code or as
> another tool that runs locally. Doing this on server side will be
> challenging because other “non loss recovery” test cases might be in
> progress in parallel.
>
>
>
> Thanks
>
>
>
> *From:* Eric Rescorla [mailto:[email-masked]]
> *Sent:* Tuesday, December 5, 2017 1:37 PM
> *To:* Praveen Balasubramanian <[email-masked]>
> *Cc:* Martin Duke <[email-masked]>; Ian Swett <
> [email-masked]>; IETF QUIC WG <[email-masked]>
> On Tue, Dec 5, 2017 at 1:33 PM, Praveen Balasubramanian <
> [email-masked]> wrote:
>