Subject: [quicwg/base-drafts] Remember UDP size limit for 0-RTT (#3498)

From: Martin Thomson <[email-masked]>
Date: Tue, 03 Mar 2020 19:44:05 -0800

As @kazuho points out, isn&#39;t *necessary* for the server to remember and not reduce `max_udp_datagram_size`.  The connection doesn&#39;t fail if the value is reduced.  If the value is reduced below what the client assumes the path MTU to be (a client might remember this too), then it results in dropping all 0-RTT packets at the server.  That isn&#39;t fatal, but it is pretty terrible.

This says remember it, consistent with the preceding text.

Closes #3447.
You can view, comment on, or merge this pull request online at:

  https://github.com/quicwg/base-drafts/pull/3498

-- Commit Summary --

  * renamed max_packet_size to max_udp_size
  * fixed typo
  * synced to latest, resolved conflict
  * erase merge artifact
  * delete whitespace
  * Resolved multiple review comments
  * Update draft-ietf-quic-transport.md
  * MT&#39;s suggestion and resolve conflict
  * Merge branch &#39;max_datagram&#39; of https://github.com/martinduke/base-drafts into max_datagram
  * Editorial: More concise intro text
  * Update draft-ietf-quic-recovery.md
  * Update draft-ietf-quic-recovery.md
  * Update draft-ietf-quic-recovery.md
  * Clarify client anti-amplification response
  * Update draft-ietf-quic-transport.md
  * Simplify
  * Update draft-ietf-quic-transport.md
  * Reworked Martin&#39;s suggestion
  * Martin&#39;s suggestion reworded
  * Clarify adaptive loss thresholds
  * Make congestion control more self-contained
  * Separate out initial and min congestion window
  * Remove tabs from recovery draft
  * Lint HTAB
  * Transport parameters can be declared unilaterally
  * ^^
  * Scope connection IDs to the current connection
  * Fix typo in transport draft changelog
  * Improve language on evictable entries. (#3131)
  * Fix typo in HTTP draft (#3482)
  * HTTP/3: Add RFC8446 reference for TLS 1.3. (#3483)
  * Jana&#39;s suggestions
  * Update draft-ietf-quic-transport.md
  * Update draft-ietf-quic-transport.md
  * Update draft-ietf-quic-transport.md
  * Update draft-ietf-quic-transport.md
  * Update draft-ietf-quic-transport.md
  * Update draft-ietf-quic-transport.md
  * Update draft-ietf-quic-transport.md
  * MT&#39;s comments and minimize text in the appendix
  * Update draft-ietf-quic-recovery.md
  * Update draft-ietf-quic-recovery.md
  * Normative language in cc section
  * Remember max_udp_payload_size for 0-RTT

-- File Changes --

    M .lint.py (5)
    M draft-ietf-quic-http.md (8)
    M draft-ietf-quic-qpack.md (20)
    M draft-ietf-quic-recovery.md (90)
    M draft-ietf-quic-transport.md (58)

-- Patch Links --

https://github.com/quicwg/base-drafts/pull/3498.patch
https://github.com/quicwg/base-drafts/pull/3498.diff

-- 
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/pull/3498

---

From: Martin Thomson <[email-masked]>
Date: Tue, 03 Mar 2020 19:45:45 -0800

Oh wow, that has a lot of commits.  The intent was to just base this on #3473.  I'll fix this up when that lands.

-- 
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/pull/3498#issuecomment-594310545

---

From: Kazuho Oku <[email-masked]>
Date: Tue, 03 Mar 2020 19:56:36 -0800

kazuho commented on this pull request.

 * initial_max_data
 * initial_max_stream_data_bidi_local
 * initial_max_stream_data_bidi_remote
 * initial_max_stream_data_uni
 * initial_max_streams_bidi
 * initial_max_streams_uni
+* max_udp_payload_size

While I agree that it is a good idea to encourage clients to remember the value, I'm not sure if we want to add max_udp_payload_size to this list. That is because doing so mandates the server to remember the max_udp_payload_size value that it advertised in the previous connection, and to not accept 0-RTT if the value has changed.

When a client reconnects from a different path, a path that the server thinks it is better to have smaller MTUs, it might be a good idea to let the server reduce the MTU. If 0-RTT packets succeed to come through (due to it being small or due to the maximum MTU being larger than what the server thinks is safe), there is no reason to drop them, just because max_udp_payload_size is going to be different.

-- 
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/pull/3498#pullrequestreview-368490297

---

From: Martin Thomson <[email-masked]>
Date: Tue, 03 Mar 2020 23:00:16 -0800

martinthomson commented on this pull request.

 * initial_max_data

You are suggesting then that this can work in certain narrow cases, therefore it shouldn't be a firm requirement?

The inverse of that is that is what concerns me.  Servers accept 0-RTT with reduced limits, with reasons other than the ones you describe, and all of the 0-RTT goes into the void.  Clients will routinely attempt to fill all available 0-RTT space with data.  If the limits that the server imposes matter here.

If local constraints change in a way that the server knows about, such that it will advertise a lower limit in the transport parameter, then it is better if it doesn't accept 0-RTT.

I get that this is a "no harm" scenario in the sense that the connection won't be torn down as a result of all those packets getting lost, but the result is worse than rejecting 0-RTT because the client will mark all those packets as lost as opposed to just forgetting them.

-- 
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/pull/3498#discussion_r387479268

---

From: Kazuho Oku <[email-masked]>
Date: Wed, 04 Mar 2020 02:42:04 -0800

* initial_max_data

Well, the counter argument would be that by sending datagrams larger than 1,280 bytes, the client is already risking packet drops caused by the network. I would assume that that risk is far bigger than packet drops caused by the server reducing the size of its packet receive buffer.

-- 
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/pull/3498#discussion_r387583924

---

From: ianswett <[email-masked]>
Date: Tue, 10 Mar 2020 11:53:08 -0700

ianswett approved this pull request.

-- 
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/pull/3498#pullrequestreview-372233300

---

From: Martin Thomson <[email-masked]>
Date: Tue, 10 Mar 2020 15:40:15 -0700

@martinthomson pushed 1 commit.

d1047cdba460e58f7c0c7f056989ec5610e385d3  Merge branch 'master' into max_udp_size-0rtt

-- 
You are receiving this because you are subscribed to this thread.
View it on GitHub:
https://github.com/quicwg/base-drafts/pull/3498/files/a356f032a97ea2619e6b991d054c0850b7151a4a..d1047cdba460e58f7c0c7f056989ec5610e385d3

---

From: Martin Thomson <[email-masked]>
Date: Tue, 17 Mar 2020 15:55:45 -0700

Closing this.

-- 
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/pull/3498#issuecomment-600339729

---

From: Martin Thomson <[email-masked]>
Date: Tue, 17 Mar 2020 15:55:49 -0700

Closed #3498.

-- 
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/pull/3498#event-3139348325