How does NSD use TFO (TCP Fast Open)?

NSD
1

Hi NSD developers,

I see that NSD can be configured with --enable-tcp-fastopen. However, the documentation doesn't say which parts of NSD use TFO.

Does NSD use TFO as a client, when requesting XFR from a server?

Does NSD generate and provide TFO cookies to clients that request them?

Or does NSD do both of the above?

Is there any downside to enabling TFO? If not, why isn't it enabled by default?

Regards,
Anand

2

Hello NSD developers,

Did you see this email I sent a few days ago? I'd love to here from you, to better understand how NSD uses TFO.

Regards,
Anand

3

Hi Anand,

Hello NSD developers,

Did you see this email I sent a few days ago? I'd love to here from you,
to better understand how NSD uses TFO.

Sure.

Regards,
Anand

Hi NSD developers,

I see that NSD can be configured with --enable-tcp-fastopen. However,
the documentation doesn't say which parts of NSD use TFO.

NSD uses TCP fast open for servicing clients. That is downstream
connections. It is an authoritative server. If enabled NSD uses it for
TCP streams, and also for TLS streams.

Does NSD use TFO as a client, when requesting XFR from a server?

No it does not. NSD does perform session reuse, using the same tcp
stream again for XFR requests from a server, or asking multiple XFRs at
the same time.

Does NSD generate and provide TFO cookies to clients that request them?

No, but I guess the system may do that, when TFO is enabled with a
socket option. But NSD can perform OCSP stapling with tls-service-ocsp,
if you want that.

Or does NSD do both of the above?

Is there any downside to enabling TFO? If not, why isn't it enabled by
default?

The option is there because the functionality is not present in all
kernels. If you want it by default, that mostly depends on people with
older kernels and how that fails, if our users have recent systems we
could enable it by default I guess.

In many cases the user has to enable TFO support in the kernel of the
system with admin commands, you can see them in documentation, and I
think it is a surprise to enable the TFO in NSD by default for users
that have not enabled it?

Best regards, Wouter

4

Hi Wouter,

NSD uses TCP fast open for servicing clients. That is downstream
connections. It is an authoritative server. If enabled NSD uses it for
TCP streams, and also for TLS streams.

Okay, thanks. That's clear.

No it does not. NSD does perform session reuse, using the same tcp
stream again for XFR requests from a server, or asking multiple XFRs at
the same time.

Okay, also clear. Thank you.

Does NSD generate and provide TFO cookies to clients that request them?

No, but I guess the system may do that, when TFO is enabled with a
socket option. But NSD can perform OCSP stapling with tls-service-ocsp,
if you want that.

Correct. The TFO cookie is handled by the kernel, and not by individual applications.

Is there any downside to enabling TFO? If not, why isn't it enabled by
default?

The option is there because the functionality is not present in all
kernels. If you want it by default, that mostly depends on people with
older kernels and how that fails, if our users have recent systems we
could enable it by default I guess.

In many cases the user has to enable TFO support in the kernel of the
system with admin commands, you can see them in documentation, and I
think it is a surprise to enable the TFO in NSD by default for users
that have not enabled it?

This is true. On our CentOS servers, for example, TFO is not on by default. It has to be enabled. Also, if we want TFO to work well, then all the servers behind a load-balancer must provide the same cookie.

As for the compile option... maybe it could just be on by default, so the code is compiled in. However, NSD would not turn it on at runtime, unless an option like "tcp-fast-open" is set to "yes".

The way it's currently coded, if NSD is compiled with tcp-fastopen, then it always tries to use it. I know it won't work unless the appropriate kernel option is set, but it leaves the user with no control. The ideal setup would be if the code were compiled it by default (unless explicitly disabled at compile time with --disable-tcp-fastopen), and then make NSD turn it on or off based on a config option.

Regards,
Anand