Subject: [mobile-ip] AD question on the "A" bit in draft-ietf-mobileip-reg-revok-04.txt

From: Thomas Narten <[email-masked]>
Date: Tue, 17 Dec 2002 11:26:33 -0500

The WG has asked that this document be adavanced. I've started my
review of this document, and rather than provide a full review in one
message, I'd like to get a better understanding of some basic issues
in the document.

The protocol has both an "I" and an "A" bit. Both of these seem odd to
me.

The A bit allows for acknowledgements. I.e., a recipient must first
indicate that it supports acknowledgements, and only then is the
sender allowed to request that revocation messages be
acknowledged. This seems odd to me for several reasons.

- implementing an ACK seems to have low cost. The ACK doesn't have to
  any semantics other than "I got your message". So, it's easy to
  implement, and doesn't require a lot of bandwidth. Why make it
  optional?

- without an ACK, the sender can't reliably deliver revocations. If an
  entity wants  to be notified of revocations, I would assume it wants
  reliability. At least, certainly better than just "send the message
  once and hope it gets delivered".

- It would be one thing for the sender to decide it doesn't want to
  deliver the message reliably, but the way the protocol is specified
  today, it doesn't even have the choice of asking for an ACK. The
  recipient may have opted to not even support them.

Instead, I would have expected: a) the message to be required to be
implemented (not optional) and b) the receiver should always return an
ACK, except *maybe* if the sender didn't want an ACK, as a (minor)
optimization. (Having said that, under what conditions would the
sender not want an ACK, and in those situations, couldn't it just
ignore the ACK?)

My thinking is that having a A bit needlessly complicates the protocol
and doesn't really provide a lot of useful benefit.  It would seem to
be simpler and more robust to just require everyone implement ACKs.

What is the thinking behind the need for the A bit?

Thomas

---

From: "Madhavi W. Chandra" <[email-masked]>
Date: Tue, 17 Dec 2002 14:05:50 -0500

Thomas,

Yes...we went back and forth on the need of the 'A' bit.  The
decision to include the 'A' bit was based on the following:

- From the senders point of view, it is doing a courtesy by
informing the other mobility agent of the revocation.  Basically,
an FYI.  

- The question of wanting reliable notification of this
revocation is for the benefit of the receiver.  From the senders
point of view, the ACK are unnecessary messages to process (since the
binding(s) are gone) and the resulting 'retransmission' behavior is
overhead.

- Thus, the 'A' bit was viewed then to allow both sides to negotiate
that they both will partake in the ACK/'retransmission' behavior.
Basically, the 'A' bit says:
"I really want to see your revocation messages, please agree to retransmit
until you see my ACK, and I'll do the same."

I agree that the bandwidth to send an ACK is minimal, and I certainly 
see your points.  I guess the question comes down to *need and
robustness*.   And as I said, we really debated this issue and are
open to making the ACK behavior mandatory.

Thanks,
Madhavi

---

From: Thomas Narten <[email-masked]>
Date: Tue, 17 Dec 2002 14:22:20 -0500

> informing the other mobility agent of the revocation.  Basically,

OK, I can see this perspective.

> binding(s) are gone) and the resulting 'retransmission' behavior is

From the sender's point of view, sending the revocation is
unnecessary. After all, it gets no benefit, and sending the message is
just overhead. Right? :-)

Seems to me that if a peer wants to be notified, it *will* want to be
notified, i.e., reliably, not just some or most of the time.

That's not the way I read the text. Specifically:

>    3.1.3  Revocation Support Extension Format
...

>         'A' Bit 
>                 When this bit is set to '1', the mobility agent is
>                 specifying that it will send a revocation
>                 acknowledgment in receipt of a registration revocation
>                 message for this registration (if the other side
>                 agrees to do the same).  See Sections 3.2 and 4.2.

I.e., based on your explanation, I would have expected text more like:

         'A' Bit 
                 When this bit is set to '1', the mobility agent wants
                 revocation requests to be sent reliably (i.e.,
                 retransmitted until acknowledged) and will
                 acknowledge them. See Sections 3.2 and 4.2.

note: this is negotiated on a peer-to-peer basis, no need to have
individual revocation requests include an ACK bit. Either all are
acked, or none are.

At another level, it seems to me that an agent will either want to be
notified (all the time) or doesn't care to be notified at all. If this
is the case, you don't need the A bit on individual requests. What is
the motivation for allowing the sender to decide when to include the A
bit in revocation requests?

The other thing odd about the current wording is that it doesn't seem
to say "if the peer included the A bit in the 'Revocation Support
Extension', then the sender MUST (or SHOULD??) set it in all
subsequent requests. The current text seems to say its the senders
choice. I.e.,:

>    3.2  Revocation Message
...
>         A       Acknowledge bit.
> 
>                 This bit MUST NOT be set to '1' unless acknowledgment
>                 support was negotiated in the last successful
>                 registration of at least one of the mobile nodes whose
>                 registration is being revoked, otherwise the results
>                 can be unpredictable.
> 
>                 Set to '0' when the revoking agent does NOT want an
>                 acknowledgment for this revocation message, or when
>                 the 'A' bit was not negotiated.
> 
>                 Set to '1' when the revoking agent is expecting an
>                 acknowledgment of this revocation message.

Note that above, there is not guidance on when the sender is supposed
to set the A bit. Hence, my confusion about what the intended
semantics are supposed to be.

Alos, per above, why should the *sender* decide whether to set the A
bit or not on individual requests? If it is the receiver that cares
whether revocation requests are delivered reliably, *it* should
control whether they ACKs are required. 

Thomas

---

From: "Madhavi W. Chandra" <[email-masked]>
Date: Tue, 17 Dec 2002 15:21:21 -0500

> bit in revocation requests?

Since a revocation extension is appended to a RRQ on an MN basis, the
'A' bit became on an MN basis.

In any case, I think that the 'A' bit is causing much confusion and
getting more complicated than it needs to be.  Even Steve and I
grappled quite a bit with it.  It seems that your initial suggestion
to make the ACK behavior mandatory is cleaner and more robust.  Then,
the philosphy behind revocation messages changes from an 'FYI' to a
'Handshake-notification'.   Note that the agreement to employ the
revocation mechanism with one another is still a negotiation.  Once
negotiated, acknowledging revocation messages is mandatory.

If we agree on this change, we can modify the text accordingly...after
your final review of the entire draft.

Thanks,
Madhavi