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

[Christer Holmberg <[e-mail]>]

Hi,

    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.
    
Not sure I understand. The Message ID will expose that the message is a retransmission.

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

The advantage of MUST-increment-by-one is that it also enables one to detect lost messages.

---

    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.

I think you should document the limitation, as it represents the current state.  Then, if we define a new message (e.g., Empty Message with options) we simply remove the limitation text.

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

Sure, but when proposing a new work I think it is good to document the issues and limitations that are known at that moment. The WG will then decide how/if to address them.

Regards,

Christer