Subject: [quicwg/base-drafts] frame type field of CONNECTION_CLOSE provides little value (#1989)

From: Marten Seemann <[email-masked]>
Date: Sat, 10 Nov 2018 22:49:51 -0800

The frame type field of the CONNECTION_CLOSE frame seems to provide little value, except for the FRAME_ENCODING_ERROR error code.

For example, consider the FLOW_CONTROL_ERROR. The only two values that would make sense in that field is the type of a STREAM frame or a RST_STREAM frame (no guidance is provided regarding that in the draft, as far as I can see). Debugging such an error based on the frame type alone will be hardly possible, you'll need a clear reason string for that.

For other error codes, things look even worse. What is the appropriate frame type for a TRANSPORT_PARAMETER_ERROR? Probably the type of a CRYPTO frame, since transport parameters are carried in TLS messages that are carried in CRYPTO frames. But setting this value provides no additional information to the peer. And what about VERSION_NEGOTIATION_ERROR or SERVER_BUSY?

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

---

From: Martin Thomson <[email-masked]>
Date: Sun, 11 Nov 2018 22:12:35 -0800

FWIW, I agree, but I'd rather not reopen the discussion.  What we have is the result of the discussion we had in either Melbourne or Kista about error handling.  Some people believed it important to have this level of reporting.  What I've seen is code like this:

```go
c.handling = f.type
switch f.type {
// dispatch to handlers
}
c.handling = FramePadding
// ...
func (c *Connection) error(qe QuicError) error {
  c.sendFrame(&ConnectionClose{c.handling, qe})
}
```

-- 
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/1989#issuecomment-437768115

---

From: Marten Seemann <[email-masked]>
Date: Sun, 11 Nov 2018 22:26:25 -0800

I don't remember any discussion about error codes in Melbourne and Kista (and I can't find any in the minutes from there). If I remember correctly, the last we discussed error codes was in Paris, and it was a lengthy and rather unpleasant discussion. 
But it was long before we defined this strange frame format for the CONNECTION_CLOSE containing the frame type field. I don't have a strong opinion if we need one generic parsing error code, or an error code for every single frame type, but I feel that with the current solution we ended up with the worst of both worlds.

I'm sorry, but I have no idea what I'm supposed to see from the code snippet you posted.

-- 
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/1989#issuecomment-437770490

---

From: janaiyengar <[email-masked]>
Date: Mon, 12 Nov 2018 03:18:34 -0800

I remember the discussion in Paris being quite pleasant and nice. What are you talking about, @marten-seemann?

The code above shows exactly how to populate the frame type field -- if known, populate with frame type, else use 0 (FramePadding).  The interpretation of 0 here is _special_ ... it implies that there's no frame type associated with this error.

I don't think this is terrible really. If you have a frame to associate with the error, use it, else use 0. It's unambiguous, even if not pretty.

-- 
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/1989#issuecomment-437844155

---

From: Mike Bishop <[email-masked]>
Date: Tue, 13 Nov 2018 12:16:59 -0800

@janaiyengar, it was nice for you, because you were reclining on a cushion on the floor.
![](https://i.postimg.cc/Z5n05Rx5/image.jpg)

-- 
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/1989#issuecomment-438421028

---

From: Dmitri Tikhonov <[email-masked]>
Date: Tue, 13 Nov 2018 13:46:54 -0800

I say we keep the field.  If it prove to be useless, we can always re-purpose it.

-- 
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/1989#issuecomment-438450188

---

From: Marten Seemann <[email-masked]>
Date: Tue, 13 Nov 2018 16:34:53 -0800

@janaiyengar Just my personal impression of that one particular discussion. Doesn't matter.

What matters is how we use this frame type field. We can decide that it's too late in the process to change the wire format, and just leave it there. We would need a lot of additional text how to properly use it though, see my examples in https://github.com/quicwg/base-drafts/issues/1989#issue-379495874. I would prefer to actually define a format that makes sense.

-- 
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/1989#issuecomment-438492618

---

From: Lucas Pardue <[email-masked]>
Date: Tue, 13 Nov 2018 18:58:18 -0800

> @janaiyengar, it was nice for you, because you were reclining on a cushion on the floor.

That's made my day. 

-- 
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/1989#issuecomment-438519931

---

From: MikkelFJ <[email-masked]>
Date: Wed, 14 Nov 2018 00:31:05 -0800

Agree with @marten-seemann and @LPardue 

-- 
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/1989#issuecomment-438579288

---

From: janaiyengar <[email-masked]>
Date: Wed, 14 Nov 2018 20:11:44 -0800

@marten-seemann : I was being sarcastic :-)
@mikebishop: Not my fault, nobody else wanted the cushion.

The info is at worst useless in some cases, and given that a CONNECTION_CLOSE is sent at most once per connection, I'm not concerned about the additional byte. We could perhaps state clearly that it's only useful for FRAME_ENCODING_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/1989#issuecomment-438910895

---

From: Martin Thomson <[email-masked]>
Date: Wed, 14 Nov 2018 20:15:13 -0800

I'm fairly sure that it is useful for some cases of PROTOCOL_VIOLATION, at least for narrowing things down.

-- 
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/1989#issuecomment-438911414

---

From: Marten Seemann <[email-masked]>
Date: Wed, 14 Nov 2018 20:20:50 -0800

@janaiyengar: I'm not concerned about the bandwidth consumed by that byte. The reason I'm raising this is because I started implementing this, and found little guidance how to use this field.

@martinthomson 
> I'm fairly sure that it is useful for some cases of PROTOCOL_VIOLATION, at least for narrowing things down.

What cases are you thinking about? I can hardly imagine a case where this field alone will help you find a problem, unless there's a decent reason phrase given (in which case it's the reason phrase that's helpful, not the frame byte).

-- 
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/1989#issuecomment-438912251