Feature #4054
closedForwarding hint: represented as name only
Added by Junxiao Shi over 7 years ago. Updated almost 7 years ago.
100%
Description
Change the Interest packet to carry only the delegation names as forwarding hint, instead of full Link objects.
Rationale: routers do not validate Link object, so the signature is unnecessary and consumes bandwidth.
Updated by Junxiao Shi over 7 years ago
- Blocks Feature #4055: Forwarding hint: represented as name only added
Updated by Junxiao Shi over 7 years ago
- Status changed from New to Resolved
- Assignee set to Junxiao Shi
- % Done changed from 0 to 30
Updated by Junxiao Shi over 7 years ago
- Status changed from Resolved to Closed
- % Done changed from 30 to 100
Updated by Junxiao Shi over 7 years ago
- Status changed from Closed to Feedback
In the implementation of this protocol change https://gerrit.named-data.net/4024 patchset3, when the default-free router at border of consumer region decides on which delegation in the forwarding hint to use, the router overwrites the forwarding hint to only contain this delegation.
In my vision, if multiple delegations in the forwarding hint lead to the same upstream, the default-free router can also overwrite the forwarding hint to contain these delegations but remove others, and defer the decision between these delegations to the upstream router.
Alex disagrees:
no way i would ever agree with that. This is a completely different semantics from setting "selected delegation" and has adverse effects when Interest Digest is (if) used.
I would argue that this is the same semantics as SelectedDelegation in previous version of the protocol. SelectedDelegation field chooses one delegation out of the set of delegations provided in the Link object. Upstream routers are required to follow this instruction, and are not allowed to modify this choice. Effectively, it reduces the set of delegations to one. The default-free router making this choice uses SelectedDelegation instead of overwriting the Link object, because it cannot re-sign the Link object.
Overwriting the forwarding hint also does not conflict with Interest Digest (#3333) any more than stripping the Link object or forwarding hint when the Interest reaches the producer region (#3893). In both cases, the outgoing Interest differs from the incoming Interest, and thus the router may handle the different digests.
As agreed in 20170201 NFD call (#3333-7):
It's agreed that a universal hash function is not needed. Instead, the hash function can be a hop-by-hop decision. A negotiation mechanism is needed, but it is not required since day one.
This already requires a router to index the PIT in a way that Interests belonging to the same PIT entry can carry a different digest on each interface. Therefore, as long as the router makes a consistent choice in which delegation(s) to pick from a forwarding hint, the Interest sent to the same interface remains the same and has the same digest.
Updated by Junxiao Shi over 7 years ago
- Status changed from Feedback to Closed
20170717 NFD call clarifies that the problem with modifying forwarding hint is a conflict with #3161.
Supose all Interests requesting /E
content initially carry forwarding hint {telia,ucla}
. If the edge of consumer region reduces the forwarding hint to have only one delegation, each delegation would create a separate partition in the CS, causing the same data to be cached twice.
It's decided that a router can pick the first delegation that has nexthops, and there is no need to record the decision in the packet.
Updated by Junxiao Shi almost 7 years ago
- Status changed from Closed to In Progress
I notice that TLV-TYPE numbers related to Link object is not defined in the spec. I'm adding them in https://gerrit.named-data.net/4380.
Updated by Junxiao Shi almost 7 years ago
- Status changed from In Progress to Closed