PSync

add an option to SegmentFetcher to use constant interest timeout for first segment

Why can't PSync use constant timeout for all segments? What's special for the first segment?

Junxiao Shi wrote:

add an option to SegmentFetcher to use constant interest timeout for first segment

Why can't PSync use constant timeout for all segments? What's special for the first segment?

First segment (segment 0) is also the traditional sync interest so it is expected to stick to sync period rather than timeout early.

hmm maybe using SegmentFetcher for sync interests isn't appropriate? And there's another (minor) problem with this: the RTT/RTO logic in SegmentFetcher will likely overestimate the RTT, because the sync Interest may be satisfied a (relatively) long time after being sent, because there was nothing new before then. I think SegmentFetcher is mainly designed for fetching "static" content.

Data segmentation is required when there are large amount of differences or when no difference is recognized and we want to send everything we have. So I think we will use SegmentFetcher for now as it is available.

I didn't say anything about segmentation :) I'm just pointing out that SegmentFetcher doesn't completely fit the requirements of PSync. And I am mildly opposed to adding a hack to SegmentFetcher to cover another hack.

I suggested an alternative on gerrit (change the estimator's initial RTO).

Yet another idea is to not use SegmentFetcher for the first segment (I assume PSync already handles the periodic retx internally anyway), and only start a SegmentFetcher for subsequent segments after you learn that the data is segmented. The drawback is that the first segment will be fetched twice, the second interest will be satisfied by the local Content Store, but that means that for a few segments the RTT will be underestimated, which could cause more RTO timeouts than necessary.

Okay, thanks. I will change the initial RTO and look at other solutions if any problems with over-estimation show up in the future.