Bug #5056
closed
Creating permanent face with changed MTU does not work if on-demand face already exists
Added by John DeHart about 5 years ago. Updated over 4 years ago.
100%
Description
On the NDN Testbed I have tried to create permanent faces with an MTU of 1450 to turn on NDNLP fragmentation and reassembly. But if the neighbor node has already started sending NDN packets an on-demand face will be created with an MTU of 8800. In this state, the addition of the new permanent face with MTU 1450 does not succeed.
Updated by Davide Pesavento about 5 years ago
- Description updated (diff)
- Start date deleted (
11/18/2019)
Updated by Davide Pesavento about 5 years ago
- Blocked by Feature #3257: EthernetTransport: support runtime MTU changes added
Updated by Davide Pesavento almost 5 years ago
- Related to Feature #4005: NDNLPv2 fragmentation instead of IP fragmentation on UDP tunnels added
Updated by Davide Pesavento almost 5 years ago
- Blocked by deleted (Feature #3257: EthernetTransport: support runtime MTU changes)
Updated by Eric Newberry almost 5 years ago
- Status changed from New to In Progress
Updated by Eric Newberry almost 5 years ago
John, if I'm understanding this issue correctly, the following occurs:
- Host A already has an on-demand face from Host B with a MTU 8800.
- A management command is run via nfdc on Host A to create a permanent face to Host B with MTU 1450.
- The face creation fails with an error code.
Is this correct? Does the face creation explicitly fail or does it succeed, but the MTU is set to 8800?
Updated by Davide Pesavento almost 5 years ago
Eric, remember that nfdc's "face create" operation maps to two management commands: faces/create and faces/update. If the former fails because the face already exists (error 409), the client (nfdc in this case) is supposed to retry with a faces/update to change the configuration of the existing face.
So I believe there are two missing features in the current code: (1) FaceManager needs to accept and process MTU changes; (2) nfdc needs to request an MTU update if the face already exists, instead of giving up.
Updated by John DeHart almost 5 years ago
Eric Newberry wrote:
John, if I'm understanding this issue correctly, the following occurs:
- Host A already has an on-demand face from Host B with a MTU 8800.
- A management command is run via nfdc on Host A to create a permanent face to Host B with MTU 1450.
- The face creation fails with an error code.
Is this correct? Does the face creation explicitly fail or does it succeed, but the MTU is set to 8800?
The nfdc face create command fails. If you need the actual error message(s) I could try to regenerate it for you.
Updated by Eric Newberry almost 5 years ago
- Status changed from In Progress to Code review
- % Done changed from 0 to 100
I've pushed what I think might be a solution to allow MTU changes through management here:
https://gerrit.named-data.net/c/NFD/+/5947
https://gerrit.named-data.net/c/ndn-cxx/+/5948
Any feedback is much appreciated!
Updated by Eric Newberry almost 5 years ago
MTU is now optional in faces/update requests and responses. See FaceMgmt r106.
Updated by Eric Newberry almost 5 years ago
I've been thinking more about how to structure this change. I believe we should track two values of MTU: underlying transport MTU and override MTU (which can be unset). These will combine to the "effective" MTU of the transport, with the underlying MTU being used unless an override MTU has been specified. If the underlying MTU changes (as it can in Ethernet), we will check whether the override MTU is still valid (using a transport type-specific check). If it is no longer valid, we will reset the MTU back to the underlying MTU. It should also be possible to unset the override MTU via management and go back to the underlying MTU.
Updated by Eric Newberry almost 5 years ago
After talking with Davide, I believe it's better to structure this change as follows:
- The Transport will keep track of the true MTU of the interface (the maximum permitted MTU of the face).
- The GenericLinkService will keep track of an optional override MTU value.
- Fragmentation and other tasks in GenericLinkService will use the smaller of the override MTU (if set) and the maximum MTU from the Transport (the "effective MTU" of the face).
- Management will report the smaller of the override MTU (if set) and the maximum MTU from the Transport (the "effective MTU").
- MTU changes via management will change the override MTU value in GenericLinkService.
- There will be an option to unset the override MTU via management.
Updated by Eric Newberry almost 5 years ago
The changes in note 14 are reflected in FaceMgmt r107.
Updated by Eric Newberry over 4 years ago
FaceMgmt r111 adds the special MTU value of 0 to faces/update to allow the override MTU to be unset.
Updated by Junxiao Shi over 4 years ago
Eric Newberry wrote:
FaceMgmt r111 adds the special MTU value of 0 to faces/update to allow the override MTU to be unset.
I reviewed the updates and agree with them.
Updated by Davide Pesavento over 4 years ago
Eric Newberry wrote:
FaceMgmt r111 adds the special MTU value of 0 to faces/update to allow the override MTU to be unset.
Why do you need a special value for that in the protocol? Can't you just use a very large number? (note: this doesn't mean the user has to specify that number on the command line, CLI syntax != mgmt protocol)
Updated by Eric Newberry over 4 years ago
Davide Pesavento wrote:
Eric Newberry wrote:
FaceMgmt r111 adds the special MTU value of 0 to faces/update to allow the override MTU to be unset.
Why do you need a special value for that in the protocol? Can't you just use a very large number? (note: this doesn't mean the user has to specify that number on the command line, CLI syntax != mgmt protocol)
Are you suggesting, for example, that any value above 8800 (or whatever the implementation-defined upper bound of MTU is) would just be interpreted as unsetting the override MTU?
Updated by Davide Pesavento over 4 years ago
Either that or use the largest value representable with the data type of the mtu field. And actually you don't even need to have special semantics to "unset" the override, since the lesser of that value and the transport's original MTU is used. Just an idea.
Updated by Davide Pesavento over 4 years ago
- Category set to Management
- Target version set to 22.02
Updated by Junxiao Shi over 4 years ago
Are you suggesting, for example, that any value above 8800 (or whatever the implementation-defined upper bound of MTU is) would just be interpreted as unsetting the override MTU?
8800 is an implementation defined upper bound.
Although NFD Management is an implementation-driven protocol, it's better to avoid using this in the protocol.
Either that or use the largest value representable with the data type of the mtu field. And actually you don't even need to have special semantics to "unset" the override, since the lesser of that value and the transport's original MTU is used. Just an idea.
Data type of the MTU field is another implementation defined limit.
However, we could define a large value as the maximum possible MTU at the protocol level, not tied to any particular implementation.
I suggest the value 232 -1 for this purpose.
I don't see any network would need a packet larger than that in next 10 years.
Updated by Davide Pesavento over 4 years ago
Junxiao Shi wrote:
Either that or use the largest value representable with the data type of the mtu field. And actually you don't even need to have special semantics to "unset" the override, since the lesser of that value and the transport's original MTU is used. Just an idea.
Data type of the MTU field is another implementation defined limit.
Is it though? Isn't it a nonNegativeInteger? NNI has a well-defined maximum value.
Updated by Eric Newberry over 4 years ago
Junxiao Shi wrote:
Are you suggesting, for example, that any value above 8800 (or whatever the implementation-defined upper bound of MTU is) would just be interpreted as unsetting the override MTU?
8800 is an implementation defined upper bound.
Although NFD Management is an implementation-driven protocol, it's better to avoid using this in the protocol.Either that or use the largest value representable with the data type of the mtu field. And actually you don't even need to have special semantics to "unset" the override, since the lesser of that value and the transport's original MTU is used. Just an idea.
Data type of the MTU field is another implementation defined limit.
However, we could define a large value as the maximum possible MTU at the protocol level, not tied to any particular implementation.
I suggest the value 232 -1 for this purpose.
I don't see any network would need a packet larger than that in next 10 years.
NNI can have a variable length of either 1, 2, 4, or 8 bytes, so the max value is 264 - 1. Why use 232 - 1 instead of this?
Updated by Junxiao Shi over 4 years ago
Eric Newberry wrote:
NNI can have a variable length of either 1, 2, 4, or 8 bytes, so the max value is 264 - 1. Why use 232 - 1 instead of this?
As I already explained:
I don't see any network would need a packet larger than that in next 10 years.
Updated by Eric Newberry over 4 years ago
Junxiao Shi wrote:
Eric Newberry wrote:
NNI can have a variable length of either 1, 2, 4, or 8 bytes, so the max value is 264 - 1. Why use 232 - 1 instead of this?
As I already explained:
I don't see any network would need a packet larger than that in next 10 years.
I still don't see why this is a good reason to use a value smaller than the max.
Updated by Eric Newberry over 4 years ago
After discussions with Davide, I have updated FaceMgmt in r113 to remove the special value to "unset" the override MTU. Instead, nfdc can approximate returning to the transport MTU by setting the override MTU to 8800 bytes, since the face will always use the lesser of the override and the transport MTU (with unlimited MTU being effectively 8800 bytes).
Updated by Davide Pesavento over 4 years ago
- Status changed from Code review to Closed