Clarification on what current object means in SUBSCRIBE, SUBSCRIBE_OK and FETCH

[wilaw]

Given the sequence below, of Groups each containing 4 objects, with the request time of subscription shown midway through receipt of object 1 of group 2. The relay has received the first bytes of Object 1-2, but not the complete object.

1. Current SUSBCRIBE text indicates

Latest Group (0x1) : Specifies an open-ended subscription with objects from the beginning of the current group. If no content has been delivered yet, the subscription starts with the first published or received group.

Latest Object (0x2): Specifies an open-ended subscription beginning from the current object of the current group. If no content has been delivered yet, the subscription starts with the first published or received group.

Does a SUBSCRIBE of Latest Object (0x2) begin with
a) 2-0 because it the latest complete object at the relay
b) 2-1 because some of the bytes have been received
c) 2-2 because we don't want to start a subscription on a partially received object

2. FETCH text indicates

EndObject: The end Object ID, plus 1. A value of 0 means the entire group is requested.

What is the largest EndObject object a player can issue a FETCH for? Is it
a) Object 2-0 because that is the last fully received object?
b) Object 2-1 because some bytes have been received?

3. SUBSCRIBE_OK text indicates

Largest Object ID: The largest Object ID available within the largest Group ID for this track. This field is only present if ContentExists has a value of 1.

What largest Object ID would be returned? Is it
a) 2-0 because it the latest complete object at the relay
b) 2-1 because some of the bytes have been received

[afrind]

Speaking as someone with a non-caching relay implementation:

SUBSCRIBE_OK will return 2-1
SUBSCRIBE (Latest obj) begins with 2-2

I haven't implemented FETCH yet, but I think FETCH can set the end object to 2^62-1. The question is, what comes in the FETCH OK? Since I don't have a cache, I can just forward upstream (side question: should the relay rewrite the upstream FETCH end object to 2-1?). If I had a cache, I'm not sure. I want to set the end object in FETCH OK to 2-1, but because it would be incomplete in cache, it's probably easier to return 2-0, but that might create a gap that needs refetching.

[ianswett]

I think the most important thing here is consistency. If some relays begin on 2-2 when they respond to SUBSCRIBE_OK with 2-1 and others begin at Object 2-1, it seems bound to cause interop problems.

[englishm]

With Joining Fetch (#638) now merged, it's especially important to clarify this now. It doesn't matter too much where we draw the line, but it's important that we're consistent and that 2-1 be accessible on one side or the other.

Delivering all of 2-1 on the Subscribe side would mean keeping at least a "current object" cache as part of subscribe implementations. Some may prefer purely fanout implementations with no cache and this might be a slightly burdensome requirement.

Delivering all of 2-1 on the Fetch side could mean waiting for all of it to become available (particularly in the case of a Joining Fetch) which could mean blocking the Fetch until that object is fully in-cache or preemptively starting delivery of the Fetch range, but accepting that it may get blocked once it reaches 2-1 and have to drop from line rate delivery to application rate delivery. This could potentially have implications for CC / BWE algorithms if they expect Fetch to always deliver at or close to line rate. For small enough objects and large enough Fetch ranges this may be a non-issue in practice, but for very large objects and smaller Fetch ranges, it could have a larger impact.

As someone currently thinking a lot about implementation requirements for minimalist fanout relays, I'm slightly inclined towards the position which says 2-1 belongs on the "past" / Fetch side of the line.

[wilaw]

Delivering all of 2-1 on the Subscribe side would mean keeping at least a "current object" cache as part of subscribe implementations. Some may prefer purely fanout implementations with no cache and this might be a slightly burdensome requirement.

Remember that Objects can have arbitrarily long durations and also large sizes. We tend to think of them as video frames, but they could be 10 minutes in duration and carry data at 20Mbps. If we want to enable non-caching fan-out relays, then the requirement to hold the current object in memory could be more than "slightly burdensome". We could set normative limits on the memory size of an Object (which may constrain some applications), or we could make holding the current Object optional, which leads to indeterminate behavior between relay networks.

[afrind]

Individual Comment:

There needs to be a verb that can access the "current" object, either SUBSCRIBE or FETCH, and both choices come with warts as Mike points out. I think I'm also leaning towards 2-1 is past/FETCH.

[ianswett]

Subscribe Start Object could replace the ContentExists and Current Object fields with a single field.

So Subscribe Start Object is the first Object in the Subscription range filter.

[afrind]

This was discussed in Denver (I think) and the conclusion was that SUBSCRIBE won't deliver partial objects. So SUBSCRIBE_OK will have 2-1 as latest and 2-2 is the first object delivered via SUBSCRIBE. 2-1 can be FETCHed, even if it's incomplete at the Original Publisher. The tail of the object will be delivered in the FETCH response as it becomes available.

PR #853 is splitting Latest Object into two filters, but that doesn't impact this issue. Neither filter will include 2-1, because it's already started. CC: @martinduke