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

From: Christer Holmberg <[email-masked]>
Date: Wed, 20 Nov 2019 05:06:28 +0000

Hi,

I took a look at the FASOR draft, and I have a few comments and questions.

Q1:

Section 4.4. says:

   "The Retransmission Count Option is used to distinguish whether an
   Acknowledgement message arrives for the original transmission or one
   of the retransmissions of a Confirmable message."

- I assume this is achieved by, once it has been confirmed that the receiver supports the option, incrementing the counter value in each retransmitted message. However, I cannot find that described anywhere. The text only says that the value of the original transmission is zero.

- Does CoAP allow changing option values in retransmissions? I cannot find any text about that in RFC 7252 that forbids it, but my general assumption is that retransmitted messages are identical.

Q2:

Section 4.4. says:

   "However, the Retransmission Count Option cannot be used with an Empty
   Acknowledgement (or Reset) message because the CoAP protocol
   specification [RFC7252] does not allow adding options to an Empty
   message.  Therefore, Retransmission Count Option is useful only for
   the common case of Piggybacked Response."

- This means that the count option cannot be used when the receiver is a proxy, since a proxy will typically send an empty acknowledgement when it receives a message.

Q3:

Section 4.4 says:

   "The original transmission of a request is indicated with the number
   0, except when sending the first request to a new destination
   endpoint.  The first original transmission of the request to a new
   endpoint carries the number 255 (0xFF) and is interpreted the same as
   an original transmission carrying the number 0."

- What is meant by "new" endpoint? Does the sender have to remember the endpoints it has previously communicated with? If so, for how long?

Q4:

Section 4.5 describes how, as an alternative solution, the Token can be used to exchange count information.

- How would that work? Would you use different Token values in each retransmission? Again, I am not sure whether CoAP explicitly forbids that, but I assume that is not the intention.

Regards,

Christer

---

From: Carsten Bormann <[email-masked]>
Date: Wed, 20 Nov 2019 13:33:17 +0800

On Nov 20, 2019, at 13:06, Christer Holmberg <christer.holmberg=[email-masked]> wrote:
> 
> - Does CoAP allow changing option values in retransmissions? 

Yes, it actually encourages that, e.g.:

   The value is intended to be current at the time of transmission.
   Servers that provide resources with strict tolerances on the value of
   Max-Age SHOULD update the value before each retransmission.[…]

https://tools.ietf.org/html/rfc7252#section-5.10.5

(The interesting part here is eventual consistency — you can’t be sure that the acknowledgement you get is actually for the most recent retransmission.)

Grüße, Carsten

---

From: Christer Holmberg <[email-masked]>
Date: Wed, 20 Nov 2019 06:03:41 +0000

Hi,

   > https://tools.ietf.org/html/rfc7252#section-5.10.5

   So, that means that implementations will have to perform a full parse of received retransmissions, instead of only parsing enough in order to detect a retransmission?

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.

    > (The interesting part here is eventual consistency — you can’t be sure that the acknowledgement you get is actually for the most recent retransmission.)

    Retransmissions can also be received out of order, and if they contain different information the receiver may not necessarily know which is the most recent.

    Regards,

    Christer

---

From: Markku Kojo <[email-masked]>
Date: Wed, 20 Nov 2019 09:22:48 +0200 (EET)

Hi Christer,

thanks for the comments/questions. Please see inline.

On Wed, 20 Nov 2019, Christer Holmberg wrote:

> - I assume this is achieved by, once it has been confirmed that the
> receiver supports the option, incrementing the counter value in each 
> retransmitted message. However, I cannot find that described anywhere. 
> The text only says that the value of the original transmission is zero.

Right, but the text says it just with a bit different phrasing. In the 
second but last para of Sec 4.4:

  "Retransmissions, if any, carry the ordinal number of the
   retransmission."

> - Does CoAP allow changing option values in retransmissions? I cannot
> find any text about that in RFC 7252 that forbids it, but my general
> assumption is that retransmitted messages are identical.

It does allow, just like Carsten already confirmed.

> - This means that the count option cannot be used when the receiver is
> a proxy, since a proxy will typically send an empty acknowledgement when
> it receives a message.

Yes, that's what it means and that's why it's an optional enhancement. 
Unfortunately, CoAP didn't include such a feature in its base spec. 
And I believe the reason for this was that the base spec. didn't include 
any kind of RTT measurements for the RTO timer, so it would have been 
unnecessary. This could have been achieved by stealing 2-3 bits from the 
Message ID, for example. Alternatively, it could still be possible to 
introduce a new type of message, an Empty Message with options, I 
believe. This would allow support for delivering options in an empty ack. 
Such an empty ack message would be needed also for other purpuses, for 
example, if at some point support for ECN is seen useful for CoAP (over 
UDP). Otherwise, there seems not to be any other way to provide the 
necessary feedback.

> - What is meant by "new" endpoint? Does the sender have to remember the 
> endpoints it has previously communicated with? If so, for how long?

Endpoint means how it is defined in the base spec (RFC 7252):

Endpoint
       An entity participating in the CoAP protocol.  Colloquially, an
       endpoint lives on a "Node", although "Host" would be more
       consistent with Internet standards usage, and is further
       identified by transport-layer multiplexing information that can
       include a UDP port number and a security association
       (Section 4.1).

Just like a CoCoA sender, a FASOR sender needs to maintain an RTO timer 
per endpoint, i.e., it needs to remember the endpoints. For how long, is 
not specified. However, from the option usage point of view it would be 
just ok to forget about an endpoint at any point and consider it as a new 
endpoint next time the sender communicates with it. This would just mean 
that when sending to the same endpoint next time we cannot leverage the 
empty option value optimization of CoAP (i.e., need to include the 
special value 255 (0xFF) in the option and confirm again that the 
receiver supports the option). Forgeting about the RTO timer (and 
corresponding RTT estimate would be possible too (just like in RFC 
6298), but is not advisable as it would affect the accuracy of the RTT 
estimation.

> Q4: >
> - How would that work? Would you use different Token values in each 
> retransmission? Again, I am not sure whether CoAP explicitly forbids 
> that, but I assume that is not the intention.

Yes, it should work just fine. It is all up to the client to decide how it 
generates the token values. Servers just echo it back without 
modification.

Best regards,

/Markku

>
> Regards,
>
> Christer
>
>
> _______________________________________________
> core mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/core
>

---

From: Carsten Bormann <[email-masked]>
Date: Wed, 20 Nov 2019 19:17:58 +0800

> On Nov 20, 2019, at 14:03, Christer Holmberg <[email-masked]> 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.
(On the other hand, for safe, idempotent methods, the server might well decide to indeed process the request again instead of de-duplicating it.)

(And I hope nobody tries this trick with non-safe methods.  Please make three coffees. <timeout waiting for ack>.  Please make two coffees.)

> 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.

>    Retransmissions can also be received out of order, and if they contain different information the receiver may not necessarily know which is the most recent.

Indeed.  The problem with max-age is, of course, that the receiver (here: the client) does not know how long the packet needed to transit the network, so reordering does not really add to that ambiguity.

Grüße, Carsten

---

From: Christer Holmberg <[email-masked]>
Date: Wed, 20 Nov 2019 14:04:00 +0000

Hi,

   > 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??? 

If so, why do we need this new counter to begin with?  The sender could simply use different message-id values in each retransmission, and use that to associate an acknowledgement with a specific retransmission.
    
   > Right.  That is not the intention.

Well, if one is allowed to update information in retransmissions, that would be the case...

    > Indeed.  The problem with max-age is, of course, that the receiver (here: the client) does not know how long the packet needed to transit the network, 
    >so reordering does not really add to that ambiguity.

Retransmissions are typically handled by the protocol stack, so to me it sounds strange that they would update information in the message itself.

Regards,

Christer

---

From: Christer Holmberg <[email-masked]>
Date: Wed, 20 Nov 2019 14:15:48 +0000

Hi Markku,

    >  "Retransmissions, if any, carry the ordinal number of the

I think you should be more specific, and say something like: "the client MUST increment the number by one in each retransmission", or something like that...

    > UDP). Otherwise, there seems not to be any other way to provide the 

I don't argue against the reasons you give, but I think it would be good to explicitly point out the limitations when the receiver is a proxy.

    > Endpoint means how it is defined in the base spec (RFC 7252):

Just to clarify, I am not asking for the definition of "endpoint", but the definition of "new".
    
    > not specified.

Since you say "new", you need to give guidance on what it means.

    >However, from the option usage point of view it would be 

In that case, I think you should describe it that way. Instead of talking about a "new" endpoint, you should talk about an endpoint that does not exist in the sender's memory of known remote endpoints, or something like that... 

    >generates the token values. Servers just echo it back without 

My issue is not about how the sender generates the token value, but that the sender would use a different token value in each retransmission. I would really like to hear from the CoAP experts whether that is allowed or not...

Regards,

Christer

---

From: Carsten Bormann <[email-masked]>
Date: Wed, 20 Nov 2019 23:27:11 +0800

>   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.

> If so, why do we need this new counter to begin with?  The sender could simply use different message-id values in each retransmission, and use that to associate an acknowledgement with a specific r…

This would take away the deduplication feature, which is sometimes needed, and sometimes just saves some work on the part of the server.

> 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).

> 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.)

Grüße, Carsten

---

From: Christer Holmberg <[email-masked]>
Date: Sat, 23 Nov 2019 13:15:57 +0000

Hi,

    >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.
    
    >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...
    
    > (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.

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

Regards,

Christer

---

From: Carsten Bormann <[email-masked]>
Date: Sun, 24 Nov 2019 13:57:49 +0100

On Nov 23, 2019, at 14:15, Christer Holmberg <[email-masked]> wrote:
> …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.

> 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.

> 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

---

From: Christer Holmberg <[email-masked]>
Date: Thu, 28 Nov 2019 11:55:21 +0000

HI,

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

Where is this "warning" documented?

Section 4.5 of 7252 says:

   "The recipient SHOULD acknowledge each

   duplicate copy of a Confirmable message using the same

   Acknowledgement or Reset message but SHOULD process any request or

   response in the message only once."

Based on that, to me it looks weird that we then define functionality which is based on actually processing retransmissions of requests/responses…

    >> 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…

    > Also useful.

Yes, but the sender will not know if the receiver will get the updated data, and that can cause problems, depending on what data is updated.

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

Not sure what you mean.

Regards,

Christer