Clarify Too Far Behind and DELIVERY TIMEOUT #1014
Conversation
DELIVERY TIMEOUT is not a guarantee Fixes: #715
afrind
added
the
Editorial & Minor Design
draft-ietf-moq-transport.md
Outdated
| assumption that the Object's data was reordered. | ||
|
|
||
| Publishers can, at their discretion, discontinue forwarding Objects earlier than | ||
| the negotiated DELIVERY TIMEOUT. However, if neither the subscriber or |
There was a problem hiding this comment.
I see the intent here, but wondering if we can add more information explaining the publisher's discretion statement?
There was a problem hiding this comment.
@suhasHere do you have a specific suggestion? I suppose the primary case in mind is resource constraints but that is just one example.
There was a problem hiding this comment.
They can't just randomly drop stuff, they have to close the steam or signal they are doing that. Think of the example where a relay send object 1,2, and 4 on a fetch stream and just decided to drop 3. I think this is the wrong place to talk about how relays deal with overload.
There was a problem hiding this comment.
@fluffy you are correct that random object drops are not allowed. I added a note and linked to the section describing those rules.
I think this is the wrong place to talk about how relays deal with overload.
This is describing what delivery timeout is and how to process subscriptions with delivery timeouts, so it seems relevant here, at least for now.
|
@vasilvv is this sufficiently addressing your concern? |
The original PR included a drive-by reflow of the previous paragraph, but that got handled in a different PR, which has merged, so this is smaller now. Only the modified paragraph has reflowed, but I only added the first sentence, and the word "However". |
|
thanks - that makes more sense now |
DELIVERY TIMEOUT is not a guarantee
Fixes: #715