Feature #2551
open
PIT refresh between neighbors
0%
Description
Design an algorithm to allow a router to limit its PIT size by requiring the downstream to refresh the PIT entry.
- An upstream router can set an upper bound on the InterestLifetime received from each downstream router: "I'll keep all Interests you send to me no more than N seconds".
- The downstream router needs to retry those Interests that did not get satisfied within N seconds.
This issue includes:
- Determine whether this idea is feasible.
- Identify the necessary additions to link layer headers, if any.
- Decide how upstream should inform downstream about its upper bound, whether this upper bound is global or per-namespace, and whether this upper bound is fixed or dynamic.
- Identify the necessary to changes to tables and forwarding pipelines.
- Identify how strategy at the upstream router can make use of this information.
- Identify how strategy at the downstream router can make use of this information.
This issue does not involve implementation.
Updated by Ernest McCracken over 5 years ago
- So for clarification..if the downstream router has an interest with a lifetime of 4 seconds but the upstream router has a lifetime limit of 2 seconds then the downstream router would need to retry the interest after 2 seconds? How would this help to limit PIT size other than hoping the downstream router's interest gets satisfied by someone else?
- Will upstream routers deny interest retries if they have reached their PIT limit? A NACK with a reason "PIT Limit Reached" seems like it would be useful by the downstream router's strategy.
Updated by Junxiao Shi over 5 years ago
I didn't design this protocol. It's Van Jacobson's idea as relayed by Beichuan. I recorded the idea in this issue.
if the downstream router has an interest with a lifetime of 4 seconds but the upstream router has a lifetime limit of 2 seconds then the downstream router would need to retry the interest after 2 seconds?
The downstream needs to resend the Interest before upstream's 2-second limit is up.
How would this help to limit PIT size other than hoping the downstream router's interest gets satisfied by someone else?
Yes, the downstream's Interest could have been satisfied by someone else.
- Will upstream routers deny interest retries if they have reached their PIT limit? A NACK with a reason "PIT Limit Reached" seems like it would be useful by the downstream router's strategy.
This idea predates Nack and congestion marks, so the answer is unspecified.
Now we have congestion marks, which would start appearing when PIT is filled to close to capacity.
Consequently, PIT limit should not normally be reached.
If PIT is completely full, Nack~Congestion could be used, and there's no need for a separate "PIT Limit Reached" reason.
I can see this design benefiting sync protocols.
Sync protocols commonly use long lived Interests.
When an application sends a sync Interest with 60-second lifetime, the Interest is flooded to all group members.
Any group member who has a sync update could respond to the Interest to notify everyone, and then everyone would express a new sync Interest.
Without periodical refreshing, if an Interest got lost, the application would not receive sync updates until it expresses the next Interest after 60 seconds.
With periodical refreshing, suppose upstream sets a 12-second limit and downstream resends the Interest after 10 seconds, a lost Interest can be recovered after 10 seconds.
In term of PIT occupancy, whether having periodical refreshing does not change anything, because the sync group will always have one outstanding Interest.
However, having periodical refreshing allows faster loss recovery, but this is only useful when there's no L2 reliability.
Note that this idea predates L2 reliability, and it's unclear whether it's better or worse than relying on L2 reliability.