Subject: [quicwg/base-drafts] Transport error codes would be smaller and more consistent as a varint (#2672)

From: ianswett <[email-masked]>
Date: Tue, 07 May 2019 13:24:46 -0700

Currently there are three spots in the QUIC transport spec which used fixed length(16-bit) integers:
* Connection Close error code
* Application Protocol Error Code in Reset Stream
* Application Error Code in Stop Sending

This typically makes reset stream and stop sending frames 1 byte larger than they need to be, which could be slightly annoying if one is churning through a huge number of streams.

It creates some unnecessary oddness in the HTTP/3 spec, where the HTTP_MALFORMED_FRAME(0x01XX) is describing a frame type that's a varint.  Admittedly, there would still be a limit of 2^60 being expressible, but it's easy to avoid that.

I think all 3 fields would be better as a varint, given our recent decisions to make HTTP/3 all varints.

-- 
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/2672

---

From: Nick Banks <[email-masked]>
Date: Tue, 07 May 2019 21:20:03 +0000 (UTC)

I would support a move to varints. I've been wanting to support more than 16-bit application error codes, for non-http protocols.

-- 
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/2672#issuecomment-490259243

---

From: Marten Seemann <[email-masked]>
Date: Tue, 07 May 2019 15:59:38 -0700

We discussed this in #1940, and closed it because nobody felt strongly either way, if I remember correctly.

-- 
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/2672#issuecomment-490284570

---

From: Jana Iyengar <[email-masked]>
Date: Tue, 07 May 2019 16:09:37 -0700

I think preferences may have changed, and @nibanks did have a preference for varints here anyways. Since nobody had a strong preference either way in #1940, it's probably worth having people voice their opinions if they now believe more strongly than they did before.

-- 
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/2672#issuecomment-490286832

---

From: Martin Thomson <[email-masked]>
Date: Tue, 07 May 2019 23:50:01 +0000 (UTC)

I'm of the opinion that varint is OK.  We can crib text from other varint usages about IANA registries and such, so the change is cheap for the spec perspective.

The HTTP_MALFORMED_FRAME thing would need a solution.  I've never been a big fan of the concept, but anything would do (apart from the 2^60 thing, which would take 1/4 of the entire space for bad frames, which is excessive; I hope that's just an error).

-- 
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/2672#issuecomment-490294758

---

From: Kazuho Oku <[email-masked]>
Date: Wed, 08 May 2019 17:39:03 -0700

I also think that varint is OK. It gives application protocols to use up to 62-bit space for error codes rather than enforcing them to use 16-bit space. The downside is that the CONNECTION_CLOSE frame could become one byte bigger, but I do not think that is a real cost.

Re HTTP_MALFORMED_FRAME, my preference goes to either a) recommend endpoints expressing the offending frame type in the reason phrase, or b) change the definition of application-close frame (i.e. CONNECTION_CLOSE with type=0x1d) to carry a blob, and define in the HTTP/3 spec. that the blob would be a tuple of error-code (varint), offending-frame-type (varint), and a reason phrase.

My view is that 2^60 is a dirty hack. It works, but I'd argue that it is a sign the HTTP draft doing something unexpected by the transport design. Therefore, I'm arguing to do what is expected by the transport, or change the design of the transport to meet the requirement of HTTP.

-- 
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/2672#issuecomment-490700673

---

From: ianswett <[email-masked]>
Date: Thu, 09 May 2019 06:41:56 -0700

For HTTP_MALFORMED_FRAME, I think @LPardue PR #2662 that removes it and replaces it with a small number of specific error codes is like a good way to go instead of the 2^60 hack.

@kazuho Are you happy with that PR?  I'm going to write a varint PR with the assumption #2662 or something like it is likely to land, so it will be transport-only.

-- 
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/2672#issuecomment-490909896

---

From: Lucas Pardue <[email-masked]>
Date: Thu, 09 May 2019 06:54:06 -0700

FWIW I just fixed the merge conflict on #2662 

-- 
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/2672#issuecomment-490914630

---

From: Kazuho Oku <[email-masked]>
Date: Thu, 09 May 2019 10:00:56 -0700

@ianswett 
> @kazuho Are you happy with that PR? I'm going to write a varint PR with the assumption #2662 or something like it is likely to land, so it will be transport-only.

#2662 works for me. My complaint is that HTTP/3 should not "hack" QUIC. Eliminating HTTP_MALFORMED_FRAME is a way of achieving that, and I do not have a strong preference on communicating the malformed frame ID.

-- 
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/2672#issuecomment-490985236