Subject: ACK reliability

From: Michael Thomas <[email-masked]>
Date: Wed, 11 Jul 2001 10:14:25 -0700 (PDT)

The current draft defines an optional three-way handshake:

1) cmd--------------->
2) <-------------reply
3) [ack------------->]

but doesn't say what to do if the respondent
doesn't receive the final ack if it requests one.
One possibility is that the respondent might
retransmit its reply which would elicit an ACK
response. The problem is that the initiator would
normally want to retire the transaction in step 2
and wouldn't have the context around to retransmit
the ACK (especially with a fresh ap_req). Since
the ACK itself is not acknowledged, the initiator
might be left needing to hold onto that state for
quite some time, which seems pretty sub-optimal.

After thinking about this for a while, it occurs
to me that the final ACK is only used  for the
respondent to know when to (de)install the other
half of the SA (incoming/outgoing depending on
CREATE/DELETE). The draft also mentions that there
should be a grace timer ala TCP to field the last
bits and dregs of a DELETE'd SA.

What I'd like to propose is we do the following:

1) Make ACK's explicitly *un*reliable
2) Require that the respondent use a retransmit
   length-ish timer to finalize the transaction
   in lieu of a received ACK

The only downside here is that there's a very rare
possibility that the respondent might send data on
an SA where it chose a different payload than the
optimistic payload *and* where the initiator
dropped the REPLY and thus hadn't installed the
correct SA parameters on the incoming SA. In other
words, pretty far out into the weeds. Given the
complexity of making reliable ACK's, I think that
this is a worthwhile tradeoff.

If I don't hear any strenuous objection, I'll 
fix this in the -01 draft.

	 Mike