Subject: [quicwg/base-drafts] transport: a frame of unknown type (#4348)

From: Kazu Yamamoto <[email-masked]>
Date: Tue, 10 Nov 2020 17:18:21 -0800

Sec 12.4 says:

> An endpoint MUST treat the receipt of a frame of unknown type as a connection error of type FRAME_ENCODING_ERROR.

I don't understand why a frame of unknown type MUST be treated as a connection error. Other unknown stuffs are just ignored. In the spirit of greasing, I think that a frame of unknown type is also just ignored.

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

---

From: Lucas Pardue <[email-masked]>
Date: Tue, 10 Nov 2020 17:51:05 -0800

In order to decode QUIC packets you need to know the length of all the frames inside them. An unknown frame is likely to have an unknown length. Requiring all frames to have a length field is an overhead that we didn't want to pay.

-- 
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/4348#issuecomment-725076317

---

From: Kazu Yamamoto <[email-masked]>
Date: Tue, 10 Nov 2020 18:27:16 -0800

Good point. Thanks.

But my point is why MUST? What about "MAY"?

-- 
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/4348#issuecomment-725087870

---

From: Lucas Pardue <[email-masked]>
Date: Tue, 10 Nov 2020 18:37:21 -0800

The rationale is explained a bit more in section 19.21. But really this is simply one of those cases where the peer is behaving in a way that violates a core contract of the protocol, I don't see any benefits that a MAY would allow. Better to fail fast and fail hard.

-- 
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/4348#issuecomment-725090886

---

From: Kazuho Oku <[email-masked]>
Date: Tue, 10 Nov 2020 18:52:01 -0800

Aside from what @LPardue pointed out, one of the practical issues are that the receiver cannot decode frames that might exist after the unknown one.

If the receiver acks the packet that carried an unknown frame, the sender might not retransmit the frames that followed the unknown frame. If the receiver does not ack the packet that carried the unknown frame, then the sender might continue retransmitting that frame.

Either ways, the connection gets stuck.

-- 
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/4348#issuecomment-725095093

---

From: Martin Thomson <[email-masked]>
Date: Tue, 10 Nov 2020 19:18:37 -0800

This is a fine question, but I don't see any need for changes. 

To add to the reasons, btw, if frames preceding the unknown one are processed, and frames after aren't, you both have to acknowledge and can't acknowledge the packet. At the same time.

-- 
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/4348#issuecomment-725107386

---

From: Kazu Yamamoto <[email-masked]>
Date: Tue, 10 Nov 2020 20:39:05 -0800

@kazuho Thanks! I understand.

@martinthomson It would be nice if the reasons were added.

-- 
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/4348#issuecomment-725192838