quic-go: PMTUD may be implemented incorrectly

Hi,

We talked about the DF bit on Windows a while ago, and I submitted https://github.com/lucas-clemente/quic-go/pull/3155. But apparently it led to this unforeseen problem https://github.com/lucas-clemente/quic-go/issues/3273 so PMTUD ended up being disabled on Windows as a dirty fix. As I revisited this today I realized that perhaps there is something fundamentally wrong with the way quic-go currently implements PMTUD, and it’s not really a Windows issue.

Previously we both assumed that the DF bit is enabled by default on Linux. But that’s not true, as the man page says this:

image

The default behavior on Linux (IP_PMTUDISC_WANT) is to only set DF bit when the packet is smaller than the path MTU, and fragment the packet otherwise. This implies that right now even if quic-go sends a packet larger than the path MTU, it will still be fragmented, sent, and received, nullifying PMTUD altogether. And if you explicitly set it to IP_PMTUDISC_DO, you will get a similar behavior as on Windows - errors when trying to send packets larger than the path MTU, instead of discarding them silently.

I wrote a demo and verified this on my Ubuntu 20.04 server, which has an MTU of 1500. When it sends packets smaller than 1500, the DF bit is set. When it sends packets larger than 1500, it fragments them and sends them successfully nonetheless.

image

About this issue

  • Original URL
  • State: closed
  • Created 2 years ago
  • Comments: 18 (18 by maintainers)

Commits related to this issue

Most upvoted comments

Then the right solution would be to ignore this error message. PMTUD packets don’t carry any application data, so there’s no benefit in declaring them lost right away. If we wanted to be fancy, we could tell the MTU discoverer right away, but I’m not sure if that’s worth the extra complexity.

Do you want to send us a PR?

Maybe 🤔 I’ll see what I can do