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

[Markku Kojo <[e-mail]>]

Hi Christer,

Apologies for the late reply.

Thanks a lot for your feedback. As usual, certainly there is room for 
improvement with a draft in its "infancy". We'll take action items on 
your comments and try to address them in the next rev.

Please see inline.

On Wed, 20 Nov 2019, Christer Holmberg wrote:

> 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",
> A or something like that...

Right. We would need to be more specific.

What you suggest is possibly more accurate but I'd hesitate using MUST 
for increment by one because it's all up to the client to decide how to 
distinguish between the retransmissions. Only the first message to an 
endpoint is an interoparatibility issue on the wire, others after that 
are not.
I'm saying this even though we have orginally proposed using this quite 
obvious option of "increment by one" but with a second thought the client 
should be able to decide how to do it, I think. It might even be 
desireable in some cases not to expose to the network whether a reguest 
is retransmission or not? We'd be happy to hear opinions on this.

On the other hand, if the wg thinks it would be useful for a receiver 
(server) to know whether a request is a retransmission or not that would 
make it different. We'd be happy to hear opinions on this as well.

We'll try to find text that's more clear and possibly give the "increment 
by one" approach as one example of how to implement it.

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

Agreed. However, we'd like to postpone further discussion about 
limitations until we know what actually is possible. That is, if this 
gets adopted and the wg thinks it might be a good idea to have such a new 
type of message (Empty Message with options), then the draft does not 
need to discuss any limitations at all for this part. Otherwise, the 
draft probably should discuss, unless we find some other less restrictive 
way.

After all, this is not yet even draft-ietf-core-...-00  ;)

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

You are right. It is similar to the concept of "new connection", e.g., 
with TCP, that is five-tuple. We need to figure out an accurate way 
to phrase it, maybe simply just like how it is is specified in the CoCoA 
draft.

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

Right. This obviously needs some clarifying text.

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

Fine. The authors base this on what is written in RFC 7252 and some 
hallway discussions with "the experts" but as the authors do not consider 
themselves as "CoAP experts" we would appreciate any advice from the wg.

Once again: many thanks for your input!

Best regards,

/Markku