Subject: [core] MAX_TRANSMIT_WAIT vs EXCHANGE_LIFETIME

From: "Peter A. Bigot" <[email-masked]>
Date: Mon, 28 Oct 2013 11:14:41 -0500

coap-18 section 4.8.2 has:

    o  MAX_TRANSMIT_WAIT is the maximum time from the first transmission
       of a Confirmable message to the time when the sender gives up on
       receiving an acknowledgement or reset.

    o  EXCHANGE_LIFETIME is the time from starting to send a Confirmable
       message to the time when an acknowledgement is no longer expected,
       i.e.  message layer information about the message exchange can be
       purged.

I'm not able to grasp the difference between these two concepts.  I
understand there are two calculations (elided) that produce a different
number, but not why each description supports a different calculation.
(The difference appears to be that EXCHANGE_LIFETIME takes into account
MAX_LATENCY while MAX_TRANSMIT_WAIT assumes the reply message
transmission takes zero time, but that makes MAX_TRANSMIT_WAIT an
unrealistic and useless number.)

It would make some sense if (using my nomenclature), MAX_TRANSMIT_WAIT
was the time in which a reply message (ACK/RST) must be received while
EXCHANGE_LIFETIME relaxes this to support an implicit acknowledgment
inferred from other information such as a response message.  But the
explicit reference to "message layer information can be purged" suggests
this isn't what was intended.

Clarification, please?  Should MAX_TRANSMIT_WAIT just be ignored as
useless?  It seems to serve no role in the protocol.

(Context: I'm trying to figure out how long the sender of a confirmable
or non-confirmable message must wait before being able to commit to the
success or failure of the transmission, as defined by the senders best
guess as to whether the recipient accepted or rejected the message.  It
appears this is not defined.)

Peter

---

From: Carsten Bormann <[email-masked]>
Date: Mon, 28 Oct 2013 18:04:29 +0100

>      receiving an acknowledgement or reset.

This is when the initiator gives up on the exchange.
(Of course, if you are patient, you can give up later.
But the responder can’t rely on that.)

>      i.e.  message layer information about the message exchange can be

This is when the initiator can reuse the Message-ID, and the responder can forget all knowledge about it.

For protocol safety, this is a much longer time.
MAX_LATENCY (which is related to TCP’s MSL) was chosen as a reasonably safe upper bound, not as the desired operational characteristics of networks that you want to run CoAP in.

> success or failure of the transmission,

That is MAX_TRANSMIT_WAIT.

> as defined by the senders best
> guess as to whether the recipient accepted or rejected the message.  

What do you mean by “rejected the message”?
(4.2: "rejecting a Confirmable message is effected by sending a
   matching Reset message and otherwise ignoring it.”)

Grüße, Carsten

---

From: "Peter A. Bigot" <[email-masked]>
Date: Mon, 28 Oct 2013 12:48:41 -0500

> This is when the initiator can reuse the Message-ID, and the responder can forget all knowledge about it.

Eh; ok, but the difference doesn't seem useful.  I don't see how the 
initiator can establish a deadline for an acknowledgement that does not 
take into account latency (unless MAX_LATENCY somehow does not apply to 
ACK/RST messages, and the 100 seconds is solely for sender network stack 
delays).  Not if the receiver does have to account for latency, given 
that from its perspective the transmission/reply duration is shorter.

Let's not waste more time on this part.

> That is MAX_TRANSMIT_WAIT.

For confirmable messages, yes.  The issue I'm confronting is that 
non-confirmable messages can also be rejected by the receiver 
transmitting a RST, and there is no corresponding discussion of how long 
the sender should wait to see if that happens.  Following the argument 
for MAX_TRANSMIT_WAIT I guess that'd be ACK_TIMEOUT or 
ACK_TIMEOUT*ACK_RANDOM_FACTOR, but the text does not address using those 
parameters for non-confirmable messages.

>     matching Reset message and otherwise ignoring it.”)

Rejecting a non-confirmable message may involve sending a RST, it's just 
not required in that case.

But, yes, that's what I mean by rejection.  The issue here is that CoAP 
defines message rejection only from the perspective of the receiver, and 
only for CON does that rejection require an externally visible stimulus 
(RST back to the sender).  Even when the receiver does send a RST that 
reply may not be received by the sender.

There needs to be a corresponding assessment from the perspective of the 
sender: I'm calling this "success/failure" of the transmission 
(contrasted with "accept/reject" for receiver perspective).  As 
specified, the sender can only determine whether the message was 
accepted or rejected under some circumstances (when it receives an ACK 
or RST reply, for example).  In other cases, it has to make an assumption.

If you take the position that, from the sender's perspective, a 
confirmable message transmission fails unless it succeeds, and success 
can be detected only if an ACK (or some other positive assurance of 
acceptance) is visible to the sender within EXCHANGE_LIFETIME (or 
MAX_TRANSMIT_WAIT), it is possible for the sender to treat the 
transmission as failed while the receiver treated it as accepted.

(A similar but even messier situation exists for non-confirmable 
messages, as suggested above, though there the default is something like 
"a non-confirmable transmission is successful unless it fails", and 
there's no deadline for when you say that it didn't fail.)

Success or failure of individual message transmissions, in turn, affects 
whether an exchange or transaction is perceived as active or aborted, 
and hence whether an endpoint must retain state associated with the 
transaction and other currently under-specified situations.

For example, at least one point I raised in 
http://www.ietf.org/mail-archive/web/core/current/msg04955.html 
regarding whether a block transfer is still active remains unaddressed.

Peter

---

From: "Peter A. Bigot" <[email-masked]>
Date: Mon, 28 Oct 2013 17:42:54 -0500

[Missed list on first reply; thunderbird is weird]

>> That is MAX_TRANSMIT_WAIT.

Assuming one can't commit to a decision about success/failure for
transmission of an outstanding message, per coap-18 section 4.7 the
answer's actually EXCHANGE_LIFETIME for confirmable request messages.
For confirmable non-request messages it's still MAX_TRANSMIT_WAIT.  For
non-confirmable messages it's undefined (explicitly for request
messages per 4.7, implicitly for non-request messages).

Peter