Subject: Re: [quicwg/base-drafts] MSS and MTU (#592)

From: Oknet <[email-masked]>
Date: Mon, 13 Nov 2017 11:40:28 +0000 (UTC)

According to https://quicwg.github.io/base-drafts/draft-ietf-quic-transport.html#rfc.section.9

```
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.
```

-- 
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/592#issuecomment-343894292

---

From: pravb <[email-masked]>
Date: Thu, 16 Nov 2017 06:22:45 +0000 (UTC)

I think kInitialWindow and kMinimumWindow need to refer to actual MSS rather than a constant kDefaultMss. For implementations that use the minimum value and do not do PMTU discovery they should use kDefaultMss 1232 or 1252. For implementations that do PMTU discovery the kDefaultMss will reflect the actual MSS for the path which could be as high as 9k - 40 when jumbo frames are configured in a DC network but typically would be similar to TCP i.e. 1460.

-- 
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/592#issuecomment-344827811