Re: [core] Comments and questions on draft-jarvinen-core-fasor-02

[Carsten Bormann <[e-mail]>]

On Nov 23, 2019, at 14:15, Christer Holmberg <[e-mail]> wrote:
> 
> Hi,
> 
>>>> I don’t think that is the intention.
>>>> If the message-id of a received message is the same as the one the server just processed, just discard.
>>> 
>>>  Are you saying that retransmissions of the same message may have different message-id values??? 
>> 
>> No, I was trying to say that a recipient discards duplicates, which they detect by them having the same message-id.
> 
> …which means the recipient would miss any updated data conveyed in the retransmission.

Yes.  Hence the warning that the server should not consider the updated data conveyed.

>>>>> In addition, if a retransmission contains updated information, retransmissions will have to be exposed to the application, rather than being handled by the protocol stack.
>>>> 
>>>> Right.  That is not the intention.
>>> 
>>> Well, if one is allowed to update information in retransmissions, that would be the case…
>> 
>> Again, the point is that a duplicate is not processed, so the sender could not rely on the updated information being seen (in the case the ACK was lost).
> 
> I think it is weird to define functionality that is based on the information being updated, and at the same time say that the sender can not rely that the receiver will see the updated information…

The receiver is getting a more accurate max-age.  This is useful.
If data are updated as well, the receiver gets more timely data.
Also useful.

Since we don’t have reliable ACKs, we can’t go beyond that.

>>> Retransmissions are typically handled by the protocol stack, so to me it sounds strange that they would update information in the message itself.
>> 
>> (Filling in the max-age value can be handled by the protocol stack as well, which is a good idea at least for implementations that care about accuracy 
>> of that information, which is why it can be easy to update it in a retransmission.)
> 
> Yes, but in order for the updated information to be useful the recipient stack will also have to parse the information, and provide it to the recipient application.

Certainly not “have to”, as the server will send an update at an opportune time (assuming observe).  Outside of observe, there is no way to know whether the “updated information” is actually a late arrival of an earlier transmission.

The really useful part of allowing a server to send updated information in a retransmission actually is that the server can choose not to deduplicate idempotent, safe requests if that would be more expensive than actually answering duplicates.  If this option is chosen, the server doesn’t know what was sent originally.

> The recipient can of course claim that the retransmission was lost, and that it never received it, but that’s a hack :)

(Without observe,) the recipient no longer has an active request at the time the (retransmission-induced or network-replicated) duplicate arrives, so without a hack it is not possible to process the duplicate.

Grüße, Carsten