NFD

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?

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.

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.

MTU is now optional in faces/update requests and responses. See FaceMgmt r106.

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.

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.

The changes in note 14 are reflected in FaceMgmt r107.

FaceMgmt r111 adds the special MTU value of 0 to faces/update to allow the override MTU to be unset.

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.

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)

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?

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.

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 2³² -1 for this purpose.
I don't see any network would need a packet larger than that in next 10 years.

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.

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 2³² -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 2⁶⁴ - 1. Why use 2³² - 1 instead of this?

Eric Newberry wrote:

NNI can have a variable length of either 1, 2, 4, or 8 bytes, so the max value is 2⁶⁴ - 1. Why use 2³² - 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.

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 2⁶⁴ - 1. Why use 2³² - 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.

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