Subject: [quicwg/base-drafts] Remembering transport parameters (#3434)

From: Martin Thomson <[email-masked]>
Date: Thu, 06 Feb 2020 01:42:34 -0800

Our current posture is to be selective about what transport parameters are remembered.  Clients and servers are required to remember a select set of parameters.

@MikeBishop described a more principled approach: remember any transport parameter that the client could transgress with 0-RTT packets.  The implied corollary here is that operation of 0-RTT is not constrained relative to 1-RTT.

Based on that principle, we already have one transport parameter that violates that.  `max_packet_size` is one of those.

I think that we will always have a split here between connection-specific stuff (original destination connection ID, preferred address) and stuff that is necessary for 0-RTT (flow control limits).  Having a principle that we can use to guide that decision would help a great deal.

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

---

From: martinduke <[email-masked]>
Date: Mon, 10 Feb 2020 10:51:42 -0800

I don't read the text this way. It lists a handful of TPs that clients MUST NOT remember and it says that all others MUST be remembered. I read this as saying that max_packet_size is on the list.

Obviously, servers must be allowed to provide a smaller subsequent max_packet_size if necessary, which is how the text currently reads.

I suggest we close this with no action.

-- 
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/3434#issuecomment-584291949

---

From: Martin Thomson <[email-masked]>
Date: Mon, 10 Feb 2020 13:29:19 -0800

Yeah, I was writing based on memory, and you are right that the text strongly skews toward remembering by default.

However, I don't agree that reducing `max_packet_size` is safe.  Unless you are suggesting that 0-RTT has to use the minimum size always.  What we have now is that clients and servers have to remember `max_packet_size`, but they aren't specifically required to avoid clients violating new restrictions.  That's weird.

I would suggest then that we make this editorial in order to capture the aforementioned principle and then I will open another issue to track `max_packet_size` constraints.

-- 
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/3434#issuecomment-584365833

---

From: martinduke <[email-masked]>
Date: Mon, 10 Feb 2020 14:52:05 -0800

There are three separate questions here:
1) Can a client exceed the previous max_packet_size in 0RTT? Clearly not.
2) Does the server have to do anything if it receives packets that exceed the old value? This isn't clear to me.
3) Is the server allowed to advertise a lower max_packet_size in its new TPs? I can imagine some use cases to motivate a "yes", and it has the advantage of being what the text already says.

-- 
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/3434#issuecomment-584397286

---

From: Mike Bishop <[email-masked]>
Date: Tue, 25 Feb 2020 07:47:34 -0800

>     3. Is the server allowed to advertise a lower max_packet_size in its new TPs? I can imagine some use cases to motivate a "yes", and it has the advantage of being what the text already says.

> the server MUST NOT reduce any limits or alter any values that might be violated by the client with its 0-RTT data

I think it's fairly clear that the client *could* violate the server's max packet size in 0-RTT so this would seem to apply.  But since the penalty for that is dropped packets, rather than connection errors, I agree that it shouldn't have to apply.

-- 
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/3434#issuecomment-590933987

---

From: martinduke <[email-masked]>
Date: Tue, 25 Feb 2020 07:53:14 -0800

@martinthomson I have trouble seeing why this isn't safe.

Let's say that we change the rule to say that servers MUST reject 0RTT if max_udp_payload_size has decreased. Then the client will send its Initial, plus a bunch of 0RTT, and then get a server extension that indicates that the server isn't accepting early data. A sensible congestion controller will then disregard the inevitable 0RTT packet losses.

If we allow 0RTT in this case, the client will send the same thing. The server doesn't get, or chooses to drop, any datagram that exceeds the new max size. A sensible congestion controller will see the updated TP and disregard 0RTT packet losses that exceeded the new max size.

The second scenario doesn't strike me as any more problematic than the other.

-- 
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/3434#issuecomment-590936990