Subject: [quicwg/base-drafts] Restructure packetization section (#985)

From: Martin Thomson <[email-masked]>
Date: Tue, 05 Dec 2017 03:13:10 +0000 (UTC)

This includes the changes from #849, which I have simply moved around.

I think that moving out the discussion on packet size to a subsection helps focus the attention on the most important part of this section, which is the discussion of how retransmission of frames works.

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

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

-- Commit Summary --

  * Add some suggestions for RFC 4821 probe packets.
  * Update draft-ietf-quic-transport.md
  * Update draft-ietf-quic-transport.md
  * Move PLPMTUD section a little, fix Initial
  * Restructure packetization section

-- File Changes --

    M draft-ietf-quic-transport.md (115)

-- Patch Links --

https://github.com/quicwg/base-drafts/pull/985.patch
https://github.com/quicwg/base-drafts/pull/985.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/985

---

From: Martin Thomson <[email-masked]>
Date: Tue, 05 Dec 2017 03:19:26 +0000 (UTC)

@martinthomson pushed 1 commit.

a73dea0  Take changes from 776debf0e45ffe

-- 
You are receiving this because you are subscribed to this thread.
View it on GitHub:
https://github.com/quicwg/base-drafts/pull/985/files/7ae32c71729f2c918d494581bc285fc50664f59d..a73dea0c0aa7cc71a656e13da0b5d5526b3a089b

---

From: martinduke <[email-masked]>
Date: Thu, 07 Dec 2017 08:13:53 -0800

martinduke approved this pull request.

I like the editorial reorganization. That section was too long.

I have few nits, mostly about shifting terminology of packet types.

Note also that @gloinul has some outstanding issues with this text. We can commit, but we can't yet close #614.

> @@ -2740,7 +2697,57 @@ that it sends.
 Strategies and implications of the frequency of generating acknowledgments are
 discussed in more detail in {{QUIC-RECOVERY}}.
 
-## Special Considerations for PMTU Discovery
+
+## Packet Size
+
+Clients MUST ensure that the first packet in a connection, and any
+retransmissions of those octets, has a QUIC packet size of least 1200 octets.
+The packet size for a QUIC packet includes the QUIC header and integrity check,

s/"packet size for QUIC packet"/"QUIC packet size"

Keep the terminology consistent, and shorter

> @@ -2740,7 +2697,57 @@ that it sends.
 Strategies and implications of the frequency of generating acknowledgments are
 discussed in more detail in {{QUIC-RECOVERY}}.
 
-## Special Considerations for PMTU Discovery
+
+## Packet Size
+
+Clients MUST ensure that the first packet in a connection, and any
+retransmissions of those octets, has a QUIC packet size of least 1200 octets.
+The packet size for a QUIC packet includes the QUIC header and integrity check,
+but not the UDP or IP header.
+
+The initial client packet SHOULD be padded to exactly 1200 octets unless the

s/initial client/QUIC initlal

> -## Special Considerations for PMTU Discovery
+
+## Packet Size
+
+Clients MUST ensure that the first packet in a connection, and any
+retransmissions of those octets, has a QUIC packet size of least 1200 octets.
+The packet size for a QUIC packet includes the QUIC header and integrity check,
+but not the UDP or IP header.
+
+The initial client packet SHOULD be padded to exactly 1200 octets unless the
+client has a reasonable assurance that the Path Maximum Transmission Unit (PMTU)
+is larger.  Sending a packet of this size ensures that the network path supports
+an MTU of this size and helps reduce the amplitude of amplification attacks
+caused by server responses toward an unverified client address.
+
+Servers MUST ignore an initial plaintext packet from a client if its total size

s/initial plaintext packet/QUIC initial packet

> @@ -2767,6 +2774,26 @@ provisional until QUIC's loss detection algorithm determines that the packet is
 actually lost.

+### Special Considerations for Packetization Layer PMTU Discovery
+
+
+The PADDING frame provides a useful option for PMTU probe packets that does not
+exist in other transports. PADDING frames generate acknowledgements, but their
+content need not be delivered reliably. PADDING frames may delay the delivery of
+application data, as they consume the congestion window. However, by definition
+their likely loss in a probe packet does not require delay- inducing

Eliminate space after dash.

-- 
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/985#pullrequestreview-81904916

---

From: janaiyengar <[email-masked]>
Date: Thu, 07 Dec 2017 13:54:47 -0800

janaiyengar commented on this pull request.

Looks good, a few minor things.

grammar nit: s/retransmissions/retransmission/ , since it's followed by "has a"

I don't think we need this; "QUIC packet size" is defined in Section 2.

Perhaps "QUIC Initial and Handshake packets" ?

+caused by server responses toward an unverified client address.
+
+Servers MUST ignore an initial plaintext packet from a client if its total size
+is less than 1200 octets.
+
+
+## Path Maximum Transmission Unit
+
+The Path Maximum Transmission Unit (PMTU) is the maximum size of the entire IP
+header, UDP header, and UDP payload. The UDP payload includes the QUIC packet
+header, protected payload, and any authentication fields.
+
+All QUIC packets SHOULD be sized to fit within the estimated PMTU to avoid IP
+fragmentation or packet drops. To optimize bandwidth efficiency, endpoints
+SHOULD use Packetization Layer PMTU Discovery ({{!PLPMTUD=RFC4821}}) and MAY use

readability nit: long sentence, which is fine, but I would split it at the "and": "... SHOULD use Packetization Layer PMTU Discovery ({{!PLPMTUD=RFC4821}}). Endpoints MAY use ..."

> +header, protected payload, and any authentication fields.
+
+All QUIC packets SHOULD be sized to fit within the estimated PMTU to avoid IP
+fragmentation or packet drops. To optimize bandwidth efficiency, endpoints
+SHOULD use Packetization Layer PMTU Discovery ({{!PLPMTUD=RFC4821}}) and MAY use
+PMTU Discovery ({{!PMTUDv4=RFC1191}}, {{!PMTUDv6=RFC8201}}) for detecting the
+PMTU, setting the PMTU appropriately, and storing the result of previous PMTU
+determinations.
+
+In the absence of these mechanisms, QUIC endpoints SHOULD NOT send IP packets
+larger than 1280 octets. Assuming the minimum IP header size, this results in
+a QUIC packet size of 1232 octets for IPv6 and 1252 octets for IPv4.
+
+QUIC endpoints that implement any kind of PMTU discovery SHOULD maintain an
+estimate for each combination of local and remote IP addresses (as each pairing
+could have a different maximum MTU in the path).

suggestion: remove the round brackets, and make the parenthetical phrase part of the main sentence.

> +fragmentation or packet drops. To optimize bandwidth efficiency, endpoints
+SHOULD use Packetization Layer PMTU Discovery ({{!PLPMTUD=RFC4821}}) and MAY use
+PMTU Discovery ({{!PMTUDv4=RFC1191}}, {{!PMTUDv6=RFC8201}}) for detecting the
+PMTU, setting the PMTU appropriately, and storing the result of previous PMTU
+determinations.
+
+In the absence of these mechanisms, QUIC endpoints SHOULD NOT send IP packets
+larger than 1280 octets. Assuming the minimum IP header size, this results in
+a QUIC packet size of 1232 octets for IPv6 and 1252 octets for IPv4.
+
+QUIC endpoints that implement any kind of PMTU discovery SHOULD maintain an
+estimate for each combination of local and remote IP addresses (as each pairing
+could have a different maximum MTU in the path).
+
+QUIC depends on the network path supporting a MTU of at least 1280 octets. This
+is the IPv6 minimum and therefore also supported by most modern IPv4 networks.

nit: s/the IPv6 minimum/the IPv6 minimum packet size/

> +SHOULD use Packetization Layer PMTU Discovery ({{!PLPMTUD=RFC4821}}) and MAY use
+PMTU Discovery ({{!PMTUDv4=RFC1191}}, {{!PMTUDv6=RFC8201}}) for detecting the
+PMTU, setting the PMTU appropriately, and storing the result of previous PMTU
+determinations.
+
+In the absence of these mechanisms, QUIC endpoints SHOULD NOT send IP packets
+larger than 1280 octets. Assuming the minimum IP header size, this results in
+a QUIC packet size of 1232 octets for IPv6 and 1252 octets for IPv4.
+
+QUIC endpoints that implement any kind of PMTU discovery SHOULD maintain an
+estimate for each combination of local and remote IP addresses (as each pairing
+could have a different maximum MTU in the path).
+
+QUIC depends on the network path supporting a MTU of at least 1280 octets. This
+is the IPv6 minimum and therefore also supported by most modern IPv4 networks.
+An endpoint MUST NOT reduce their MTU below this number, even if it receives

nit: s/their MTU/its MTU/ 

> +determinations.
+
+In the absence of these mechanisms, QUIC endpoints SHOULD NOT send IP packets
+larger than 1280 octets. Assuming the minimum IP header size, this results in
+a QUIC packet size of 1232 octets for IPv6 and 1252 octets for IPv4.
+
+QUIC endpoints that implement any kind of PMTU discovery SHOULD maintain an
+estimate for each combination of local and remote IP addresses (as each pairing
+could have a different maximum MTU in the path).
+
+QUIC depends on the network path supporting a MTU of at least 1280 octets. This
+is the IPv6 minimum and therefore also supported by most modern IPv4 networks.
+An endpoint MUST NOT reduce their MTU below this number, even if it receives
+signals that indicate a smaller limit might exist.
+
+If a QUIC endpoint determines that the PMTU between any pair of local and remote

There's obviously a good reason for this, which I can't seem to remember. Why do we disallow smaller packets? Can you add a note here about that as well, so it's obvious to any reader?

-- 
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/985#pullrequestreview-82001037

---

From: MikkelFJ <[email-masked]>
Date: Thu, 07 Dec 2017 22:12:24 +0000 (UTC)

mikkelfj commented on this pull request.

+

My reading of this is that the maximum must not be reduced, but if you have less to send, go ahead. This will trigger packet loss and eventual connection failure when sending bulk data on a network that does not honor the 1200 minimum and therefore possibly trigger a connection migration if possible, or otherwise stop a hopeless quest.

-- 
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/985#discussion_r155656158

---

From: MikkelFJ <[email-masked]>
Date: Thu, 07 Dec 2017 14:15:44 -0800

+

Another reason may be to prevent DoS attacks by injection of unverifiable network congestion control / status data.

-- 
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/985#discussion_r155656832

---

From: Martin Thomson <[email-masked]>
Date: Thu, 07 Dec 2017 17:29:15 -0800

2de0c05  Some editorial changes

-- 
You are receiving this because you are subscribed to this thread.
View it on GitHub:
https://github.com/quicwg/base-drafts/pull/985/files/a73dea0c0aa7cc71a656e13da0b5d5526b3a089b..2de0c0512b32594a919115c37be4b4b5f8aceeb1

---

From: Martin Thomson <[email-masked]>
Date: Thu, 07 Dec 2017 17:29:26 -0800

martinthomson commented on this pull request.

Ugh, this is what you get when you move text.  I swear I didn't change anything here.

Rewording coming up.

I never realized that "QUIC packet size" was defined there.  I think that this is the better place to add that definition.

It's only Initial.  I'll reword this.

+
+## Packet Size
+

Moar rewording coming up.

+

or a new sentence

MTU, not packet size (a 1280 MTU implies a smaller packet size)

+

I'm going to request that you open an issue if you care about this.  This is old text and I'm not really equipped to deal with it right now.  I *think* that @mikkelfj is approximately right.  It might also be to avoid using paths that will drop random packets.

Frankly, I don't think that we need the requirement.  If you *know* that this has happened, you can deal.  The only real cost at that point is that you might be unable to create a new connection on that path.

-- 
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/985#pullrequestreview-82044308

---

From: janaiyengar <[email-masked]>
Date: Wed, 13 Dec 2017 07:22:20 +0000 (UTC)

janaiyengar approved this pull request.

LGTM. Merge when you're ready.

-- 
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/985#pullrequestreview-83078543

---

From: Martin Thomson <[email-masked]>
Date: Wed, 13 Dec 2017 13:48:11 -0800

Merged #985.

-- 
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/985#event-1386564449