Closed gvisor-bot closed 6 months ago
The description in this issue brings some helpful info about why the logs for a Cloud Run deployment is full of these lines:
Hopefully this can be fixed, so the logs can become easier to read and more useful.
Can this be moved to a higher priority?
cc @iangudger @ianlewis
@AndreiIgna What were you running on Cloud Run when you got these messages?
hi @ianlewis
These logs still appear all the time
in a project that uses these 2 libraries:
dig
command to query DNSFrom ~20 different Cloud Run services, only the one using these libraries shows those logs. To be honest I don't understand much about gvisor
or the title of this issue (I was just directed here), so hope these details are helpful for pinpointing to the cause of this.
@AndreiIgna No problem, I think this is a different issue though. Could you post your screenshot and other info into a new issue? I'll try to take a look at it when I get a chance.
Closing because this has secretly been in netstack (updateMaxPayload
) for a long time, and starting from e367e0b134890cb8929f9a2bdb0c16710e70ffe8 we have it enabled by default.
PMTU will be useful when determine the MSS for a TCP connection. RFC 1122 sectiion 4.2.2.6 has a discission:
Some TCP implementations send an MSS option only if the destination host is on a non-connected network. However, in general the TCP layer may not have the appropriate information to make this decision, so it is preferable to leave to the IP layer the task of determining a suitable MTU for the Internet path. We therefore recommend that TCP always send the option (if not 536) and that the IP layer determine MMS_R as specified in 3.3.3 and 3.4. A proposed IP-layer mechanism to measure the MTU would then modify the IP layer without changing TCP.