Project

General

Profile

Feature #3257

EthernetTransport: support runtime MTU changes

Added by Davide Pesavento almost 6 years ago. Updated over 1 year ago.

Status:
Closed
Priority:
Normal
Assignee:
Category:
Faces
Target version:
Start date:
Due date:
% Done:

100%

Estimated time:

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.


Related issues

Blocked by ndn-cxx - Feature #3353: NetworkMonitor: emit fine-grained signals when the state of a network interface changesClosedDavide Pesavento

Actions
#1

Updated by Davide Pesavento over 5 years ago

  • Blocked by Feature #3353: NetworkMonitor: emit fine-grained signals when the state of a network interface changes added
#2

Updated by Davide Pesavento almost 2 years ago

  • Blocks Bug #5056: Creating permanent face with changed MTU does not work if on-demand face already exists added
#3

Updated by Eric Newberry over 1 year ago

  • Assignee set to Eric Newberry
#4

Updated by Eric Newberry over 1 year 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.

#5

Updated by Davide Pesavento over 1 year 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.

#6

Updated by Davide Pesavento over 1 year 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.

#7

Updated by Eric Newberry over 1 year 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).

#8

Updated by Davide Pesavento over 1 year 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).

#9

Updated by Eric Newberry over 1 year 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?

#10

Updated by Eric Newberry over 1 year 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.

#11

Updated by Eric Newberry over 1 year ago

  • Status changed from Code review to Closed
#12

Updated by Davide Pesavento over 1 year ago

  • Subject changed from Transport: support runtime MTU changes to EthernetTransport: support runtime MTU changes
  • Target version set to v0.8

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).

#13

Updated by Davide Pesavento over 1 year ago

  • Blocks deleted (Bug #5056: Creating permanent face with changed MTU does not work if on-demand face already exists)

Also available in: Atom PDF