3 ms·

I think the case is a little bit more subtle than described. Linux doesn't actually need ICMP-based path MTU discovery to figure out the safe MSS to use. It im

by jsnell 5y ago

I think the case is a little bit more subtle than described. Linux doesn't actually need ICMP-based path MTU discovery to figure out the safe MSS to use. It implements RFC 4821-style MTU probing, where after repeated retransmissions the sender will try to retransmit smaller prefixes of the segment and see if that makes it through. If it does, it can be deduced that the safe MSS is lower than advertised, and the MSS for the connection is (permanently) dropped to the newly discovered limit. So even if the ICMP return path isn't working, the connection should just have a hickup for a few seconds but then resume working. Why isn't MTU probing triggering here? I haven't checked the code, but would guess that it's refusing to split a segment with the PSH flag set.

touisteur 5y ago
Fun fact, was observing periodic latency peaks on some customer network. TCP analysis would show a resend after an icmp 'too big' packet from a middlebox. Fine. Once at connection establishment or rather at the first PSH over the default MTU, right? But why periodically? Well Linux re-raises the path mtu periodically, iirc in case of icmp spoofing... Is it different here for mss-based discovery? You say permanently?
- jsnell 5y ago
  That was my recollection, but looking at the source I don't think that was correct.
  - touisteur 5y ago
    Ah thanks. Will have to open tcp.c, but it gets crazier every year it might take some time... It would make sense to keep it permanently if the justification is purely based on the risk of icmp spoofing. But TCP connections can be very long-lived and the network might change under your feet, even worst if you're doing some bonding/teaming or container-/connection-migration, it might be a good idea to probe the path mtu again. It's just a pain from a latency perspective. I wish I could skip a bit of a stream without re-establishing the full connection.

by jsnell 5y ago

touisteur 5y ago

Fun fact, was observing periodic latency peaks on some customer network. TCP analysis would show a resend after an icmp 'too big' packet from a middlebox. Fine. Once at connection establishment or rather at the first PSH over the default MTU, right? But why periodically? Well Linux re-raises the path mtu periodically, iirc in case of icmp spoofing... Is it different here for mss-based discovery? You say permanently?

jsnell 5y ago
That was my recollection, but looking at the source I don't think that was correct.
- touisteur 5y ago
  Ah thanks. Will have to open tcp.c, but it gets crazier every year it might take some time... It would make sense to keep it permanently if the justification is purely based on the risk of icmp spoofing. But TCP connections can be very long-lived and the network might change under your feet, even worst if you're doing some bonding/teaming or container-/connection-migration, it might be a good idea to probe the path mtu again. It's just a pain from a latency perspective. I wish I could skip a bit of a stream without re-establishing the full connection.