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

[Markku Kojo <[e-mail]>]

Hi Christer,

thanks for the comments/questions. Please see inline.

On Wed, 20 Nov 2019, Christer Holmberg wrote:

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

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.

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

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.

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

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

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
> [e-mail]
> https://www.ietf.org/mailman/listinfo/core
>