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

[Kazuho Oku <[e-mail]>]

@martinduke 
> I would like someone to articulate what harm is done if the server were to accept 0-RTT when the max_packet_size has decreased.

Consider the case where the original value of max_packet_size was 9000, and client sending 0-RTT packets of 9000 bytes. If the server's max_packet_size goes down to 1280 and the server accepts 0-RTT, the client would consider the 0-RTT packets it has sent to be lost. I think that would halve CWND (to 5 MTU) and we'd exit slow start. This negative impact is likely to be greater than the benefit we'd get from 0-RTT.

That said, I am not sure if I like the framing of the discussion, or the current definition of `max_packet_size`.

I think we might be conflating the maximum size of QUIC packets and the maximum size of UDP datagrams, and I might argue that what matters in reality is the size of UDP datagrams.

As `max_packet_size` is a limit at the QUIC packet level, the transport draft allows a sender to send (and therefore requires a receiver to not discard) a UDP datagram that contains multiple QUIC packets being colesced, each of those QUIC packets being as large as `max_packet_size`. A server might send a UDP datagram that is 3x of `max_packet_size` (datagram consisting of full-sized Initial, Handshake, 1-RTT packet). Once a client receives the TP, it might send a UDP datagram that is 2x of `max_packet_size` (consisting of full-sized Handshake and 1-RTT packet).

Are we fine with that? Shouldn't we better change the TP to `max_datagram_size`?

-- 
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-588714349