Re: [quicwg/base-drafts] max_packet_size in 0-RTT (#3447)

[Kazuho Oku <[e-mail]>]

> I don't like @kazuho's proposed change. The point of this is to express a limitation of the endpoint. If the endpoint only has X bytes of memory for receiving packets, then it can use this limit. Absent this, we can't ever hope to have big endpoints talking to little ones. We will end up with middleboxes (hello CoAP).

Yes, I share the view that the sender should adhere to the receiver's advertised limit. But that does not mean that exceeding the limit needs to trigger a protocol violation, or if the receiver should be allowed to trigger that.

I might argue that, in practice, receivers would not trigger protocol violation when it receives a QUIC packet that is larger than the advertised maximum. This is because the receiver has to decrypt the packet that is larger than its limit in order to check that the packet was not spoofed. But is there an incentive to have a buffer that is larger than the advertised maximum just for this purpose? I do not think so. I'd assume that endpoints would simply advertise its buffer size.

I think we just have different view points. One way of viewing this TP is that it is an ordinary TP, and therefore that when 0-RTT is being used, the resumed connection inherits this TP too from the previous connection.

The other way of viewing this TP is that it is an optimization of PMTUD, that lets a receiver advertise the maximum size of a datagram that is capable of processing. PMTUD needs to be applied per each connection (or to be precise per each path), regardless of if 0-RTT is used. If we view the TP this way, it can be considered something that kicks in when the TP is received for every connection.

IMO the latter view is simpler in terms of implementation complexity, and has no downsides.

-- 
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/3447#issuecomment-589501315