Subject: Re: [quicwg/base-drafts] Varint h3 unidirectional stream types (#2275)

From: David Schinazi <[email-masked]>
Date: Thu, 03 Jan 2019 14:02:51 -0800

I also support this (with changing existing stream types to be <= 63). I'd also make it a MUST encode as smallest possible encoding.

-- 
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
https://github.com/quicwg/base-drafts/issues/2275#issuecomment-451291767

---

From: Mike Bishop <[email-masked]>
Date: Wed, 30 Jan 2019 21:34:54 -0800

Discussed in Tokyo; despite some unhappiness, we will do this.

-- 
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
https://github.com/quicwg/base-drafts/issues/2275#issuecomment-459221800

---

From: Lucas Pardue <[email-masked]>
Date: Wed, 30 Jan 2019 21:52:31 -0800

I'm not against the idea of this. The observation I made during the discussion is that uni streams are a critical part of a H3 session. Failure to read the uni stream type successfully will be a killer: reading a single byte is more resistant to failure.

I think we should put some energy into the H3 interop to try and ensure that implementations are resilient to varint stream type failures. I wonder if this can be done as a test vector, or by some other interop test design.

-- 
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
https://github.com/quicwg/base-drafts/issues/2275#issuecomment-459224917

---

From: Lucas Pardue <[email-masked]>
Date: Wed, 30 Jan 2019 23:01:50 -0800

One idea for testing is to use a set of grease streams. On connection open the opposite endpoint sends partial varints at various encoding lengths (e.g. write one byte, delay, write another byte, etc). the receiving endpoint should either wait for a complete varint and then proceed (i.e. a resilient endpoint), or it will explode in varint parse failure (a fragile one).

-- 
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
https://github.com/quicwg/base-drafts/issues/2275#issuecomment-459238192

---

From: Martin Thomson <[email-masked]>
Date: Thu, 31 Jan 2019 02:48:29 -0800

I plan to send unidirectional stream types in non-minimal varint encodings.  Vive la liberté.

-- 
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
https://github.com/quicwg/base-drafts/issues/2275#issuecomment-459300169

---

From: Lucas Pardue <[email-masked]>
Date: Thu, 31 Jan 2019 02:57:38 -0800

Great opportunity for network-oriented fuzzer

-- 
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
https://github.com/quicwg/base-drafts/issues/2275#issuecomment-459302782

---

From: Martin Thomson <[email-masked]>
Date: Thu, 31 Jan 2019 11:00:43 +0000 (UTC)

Fuzzer?  I'm talking a live stack.

-- 
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
https://github.com/quicwg/base-drafts/issues/2275#issuecomment-459303690

---

From: Lucas Pardue <[email-masked]>
Date: Thu, 31 Jan 2019 03:19:15 -0800

Me too. To elaborate my thoughts, some of the test methods presented at EPIQ, like quic tracker, can easily write bytes-on-wire tests that exercise such handling and edge cases 

-- 
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
https://github.com/quicwg/base-drafts/issues/2275#issuecomment-459308587