MSS and MTU

[gloinul]

In draft-ietf-quic-recovery-03, section 4.3:

kDefaultMss (default 1460 bytes):  The default max packet size used
for calculating default and minimum congestion windows.

kInitialWindow (default 10 * kDefaultMss):  Default limit on the
amount of outstanding data in bytes.

kMinimumWindow (default 2 * kDefaultMss):  Default minimum congestion
window.

The document doesn't discuss MSS more, however it clearly have significant impact on the protocol behavior. Thus, I really like to get some clarifications on how MSS are handled in QUIC. Some questions I have are:

1. What is the relation between MSS and IP layer MTU?
2. Is the constants above intended to be related to actual packets possible to send, where MSS = MTU is important, or only to indicate a certain number of bytes?
3. What manipulation is allowed of MSS during a connections life time. In QUIC change of MTU has to be expected for several reasons. Thus, should MSS be updated due to MTU changes, and how are they performed?

[oknet]

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.

[pravb]

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.

[gloinul]

A Quick look in -10 seems that this is not yet addressed, so I will keep it open.

[ianswett]

The intent is to use MSS to set a congestion window that is similar to what a TCP connection would use. It also factors into Reno congestion control, since that specifies one packet of CWND increase per round.

I think it's important to use a single value throughout, but I don't have any reason to believe the exact number(ie: 1232, 1252, 1460, etc) matters that much.

I'd like a suggestion on what to do about this issue, because I'm unclear on what the problem is or what the resolution would be.