Joining Fetch

[englishm]

This PR adds the desired "Join" functionality as discussed at IETF 121 in Dublin¹

Adding this functionality to Fetch unblocks further simplifications of Subscribe, allowing us to more clearly delineate between "past" (Fetch) and "future" (Subscribe). (see #598, #510 (review), etc.)

There are several ways we could allow a publisher to "atomically" join a Fetch and a Subscribe.
At IETF 121, @wilaw presented slides showing API options:

1. a new macro-like singular JOIN message that is decomposed at the publisher into both a SUBSCRIBE and a FETCH
2. a modified form of FETCH that can be joined together with an existing Subscribe

The consensus of the discussion seemed to heavily favor the latter design, so, as was requested, this PR is written as a modified form of Fetch: Joining Fetch.

This PR:

• Adds "Fetch Type" field to Fetch messages
• Redefines pre-existing behavior as a Fetch Type: "Standalone Fetch"
• Defines new Fetch Type: "Joining Fetch"
• Defines new error code: "Invalid Subscribe ID"

Footnotes

1. 21:18 in the recording. Note: the Meetecho page includes the chat, synced to the video. ↩

[englishm]

(Fixed some capitalization inconsistencies)

[afrind]

Individual Review:

Thanks for this. I think it's an improvement over "Current Group" in subscribe.

[englishm]

Individual Review:

Thanks for this. I think it's an improvement over "Current Group" in subscribe.

Thanks for the quick feedback @afrind!

I'll fix up the definitions for how to resolve the range relative to the Subscribe so the terminology matches the current draft text and the details are more clear.

[wilaw]

Looking good Mike. I added a few points for clarification.

[wilaw]

Are there limits on this value? Is zero allowed? Is 1000 allowed? Is -1 allowed?

[englishm]

Consolidating discussion of this point.

For simplicity, we should disallow PGC = 0. It essentially overlaps the FETCH with the SUBSCRIBE. Forcing PGC >= 1 seems cleaner.

I'm in favor of allowing "Preceding Group Offset" = 0 so that we can have the option of using Fetch to retrieve the first portion of a group when Subscribe(LatestObject) is used to retrieve the rest. The updated text hopefully makes it clear that the Fetch and Subscribe do not overlap.

Is 1000 allowed?

Yes. Depending on how group ID are set for a given track this may make sense.

That said, it is not necessarily advisable to use a Joining Fetch to Fetch a large number of groups. In that case it may be better to wait for Subscribe OK and then make a series of smaller Fetch requests to fill the desired range.

I'm not opposed to putting some kind of limit on this value, but it's hard to say what it ought to be for all circumstances. I think it may be better to just allow publishers to reject joining fetch requests with PGOs larger than they wish to fulfill by responding with a Fetch Error. (I just created a separate issue about defining more error codes: #644)

Is -1 allowed?

No. This field is defined as [Preceding Group Offset (i),] and this Variable-Length Integer Encoding does not permit negative values.

[afrind]

Individual Review

[fluffy]

I think we need to fix up the "what happens" when no content case but I like the overall PR here and seems to meet the use cases.

[englishm]

@ianswett let me know if there are any other editorial changes you'd like to see here.

[afrind]

Individual Review

[afrind]

There's a non-normative 'may' - suggest 'can'.

I like leaving some flexibility here.

The case I brought up in the interim (SUBSCRIBE_OK seen but with contentExists=false) implicitly goes to "wait until you can resolve fetch locally" because you cannot send another SUBSCRIBE upstream. Maybe we could say a bit more here.

[englishm]

Good catch, switched that to 'can'.

Do we want to suggest behavior for particular cases like the one you describe?
The other one we discussed as seeming fairly straightforward is the case of receiving a Joining Fetch that joins to the first Subscribe for a track. Since the relay would send a new Subscribe upstream in that case, it could also forward the Joining Fetch so that the join point is resolved at the upstream publisher.

That said, the exact details of how relays choose to handle aggregation may vary from implementation to implementation and I agree with Will's sentiments that it would not be good to be too prescriptive here. If we spell out specific scenarios where a relay can choose to take a particular course of action, does that make this note sound more normative than it should be? Or is just avoiding normative language (i.e. sticking to 'can' instead of MAY/MUST/SHOULD) sufficient?

I'll take a stab at spelling out these two cases non-normatively if folks think that makes sense.

[wilaw]

I'd replace

Note: If a relay does not yet have LatestGroup and LatestObject for a given track, it can choose to either forward both the Subscribe and the Joining Fetch upstream or to wait until the Joining Fetch can be resolved locally. In either case, the Resolved Subscribe Start values for a Joining Fetch MUST correspond to the Subscribe within the same session so the Fetch and Subscribe can be contiguous and non-overlapping.

with

The Resolved Subscribe Start values for a Joining Fetch MUST correspond to the referenced Subscribe so that the Objects delivered across the Fetch and Subscribe are contiguous and non-overlapping.

[englishm]

I like that @wilaw - simple and to the point, thanks!

@afrind @fluffy do either of you feel it's necessary to spell out the cases outlined above or could we just go with something like Will's suggestion, focusing on only the normative requirement and omitting reference to what will likely be implementation-specific behavior to meet that requirement?

[afrind]

I liked your language "within the same session" because it made clear that the resolution had to be on the same endpoint.

I think the "already subscribed upstream, content-exists=false' case warrants a sentence explaining what to do. Eg if the relay sends SUBSCRIBE_OK with content-exists=false, it MUST send a FETCH_ERROR for the joining fetch.

[afrind]

I think we need to resolve what's going on with Subscribe(LatestGroup). Options:

1. Remove it (it splits past and future)
2. Subscribe(LatestGroup) is identical to Subscribe(LatestObject) + Joining Fetch(PGO=0) -- it sends a Subscribe Ok, a FetchOK, a Fetch stream and any future subgroups.
3. Special rules for publishers/relays that definitively have the entire current group cached

I guess it can be in another PR.

[englishm]

I agree. I've tried to write this PR in a way where 1 is a viable option, but I think that actually modifying Subscribe should be done in a separate PR.

[afrind]

I agree. I'll wait for this to land since I don't think it will impact the decision and then open a separate issue.

[afrind]

Individual Comments

[afrind]

I agree. I'll wait for this to land since I don't think it will impact the decision and then open a separate issue.

[afrind]

I liked your language "within the same session" because it made clear that the resolution had to be on the same endpoint.

I think the "already subscribed upstream, content-exists=false' case warrants a sentence explaining what to do. Eg if the relay sends SUBSCRIBE_OK with content-exists=false, it MUST send a FETCH_ERROR for the joining fetch.