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

[Christer Holmberg <[e-mail]>]

Hi Markku,

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

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

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

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.


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

Just to clarify, I am not asking for the definition of "endpoint", but the definition of "new".
    
    > 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.

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

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

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


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

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