Feature #3257
closed
EthernetTransport: support runtime MTU changes
100%
Description
The MTU of a Transport can change at runtime, for example when a user modifies the MTU of the underlying network device using ip or ifconfig.
On Linux, rtnetlink provides a notification that we can use to change the MTU of the affected transport(s) when this happens.
Updated by Davide Pesavento about 8 years ago
- Blocked by Feature #3353: NetworkMonitor: emit fine-grained signals when the state of a network interface changes added
Updated by Davide Pesavento over 4 years ago
- Blocks Bug #5056: Creating permanent face with changed MTU does not work if on-demand face already exists added
Updated by Eric Newberry about 4 years ago
- Status changed from New to In Progress
In order to track changes to the MTU, the face must know which NetworkInterface it is on. The design Davide and I were thinking of for this would involve splitting the existing system into separate channels for each face. However, this would require that NFD know which local endpoint it should use for a given connection. The open question is how this should be accomplished, particularly if there are multiple physical interfaces with non-loopback addresses on the system.
Updated by Davide Pesavento about 4 years ago
Eric Newberry wrote:
separate channels for each face
I was saying one channel for each local IPv4/v6 address, not for each face (the context was UDP channels)
However, this would require that NFD know which local endpoint it should use for a given connection. The open question is how this should be accomplished, particularly if there are multiple physical interfaces with non-loopback addresses on the system.
The "simple" answer is look at the kernel's IP routing table... except that it's not that simple. And I don't think we want to replicate the IP routing logic in NFD.
Updated by Davide Pesavento about 4 years ago
One alternative approach (for UDP) is to let the kernel do PMTU discovery, and react to "datagram too large" errors by fragmenting the packet via NDNLP. This would also be more accurate than just looking at the interface MTU.
Updated by Eric Newberry about 4 years ago
Davide Pesavento wrote:
Eric Newberry wrote:
separate channels for each face
I was saying one channel for each local IPv4/v6 address, not for each face (the context was UDP channels)
Sorry, that's what I meant.
However, this would require that NFD know which local endpoint it should use for a given connection. The open question is how this should be accomplished, particularly if there are multiple physical interfaces with non-loopback addresses on the system.
The "simple" answer is look at the kernel's IP routing table... except that it's not that simple. And I don't think we want to replicate the IP routing logic in NFD.
I agree that this would be pretty complicated (and redundant).
Updated by Davide Pesavento about 4 years ago
Eric Newberry wrote:
this would require that NFD know which local endpoint it should use for a given connection.
Actually, why do we need to do that? Unless I forgot something, we can do the following: keep using a single channel on the "any" address and let the kernel pick the outgoing interface; then, once the face is created, query the socket's local endpoint and find it among all the addresses of all the known network interfaces (you can either maintain a reverse mapping address -> netif or search the address every time).
Updated by Eric Newberry about 4 years ago
Davide Pesavento wrote:
Eric Newberry wrote:
this would require that NFD know which local endpoint it should use for a given connection.
Actually, why do we need to do that? Unless I forgot something, we can do the following: keep using a single channel on the "any" address and let the kernel pick the outgoing interface; then, once the face is created, query the socket's local endpoint and find it among all the addresses of all the known network interfaces (you can either maintain a reverse mapping address -> netif or search the address every time).
How would we check for changes in the MTU? Perhaps the Factory or Channel could connect to the MTU changed signal on all netifs and then iterate through all Transports to determine which ones needed to be updated?
Updated by Eric Newberry about 4 years ago
- Status changed from In Progress to Code review
- % Done changed from 0 to 100
This change will only apply to Ethernet faces, since UDP will be addressed in #5056.
Updated by Eric Newberry about 4 years ago
- Status changed from Code review to Closed
Updated by Davide Pesavento about 4 years ago
- Subject changed from Transport: support runtime MTU changes to EthernetTransport: support runtime MTU changes
- Target version set to 22.02
Eric Newberry wrote:
This change will only apply to Ethernet faces, since UDP will be addressed in #5056.
#5056 is about changing (limiting) the MTU via NFD management, as opposed to this issue which is about the underlying interface changing its MTU via some external means. The difference is not about UDP vs ethernet. That being said, we can restrict this issue to ethernet faces, which are fairly simple to handle in this regard. We can open a separate issue for UDP faces, which are substantially more complex (see note-6 above for instance).
Updated by Davide Pesavento about 4 years ago
- Blocks deleted (Bug #5056: Creating permanent face with changed MTU does not work if on-demand face already exists)