Capwap Mailing List: Re: Recap of current pending issues

[Pasi.Eronen (Pasi.Eronen]

Pat Calhoun wrote:
>> The answer (you can't have multiple outstanding requests) really
>> needs to be in the spec. Also, the spec needs some more text about
>> how the receiver processes them -- e.g. does the receiver maintain
>> "last seen sequence number" counter, and silently drop (without
>> replying) requests older than this?
> 
> 
> I believe some of this was already covered, but I have added a new
> sentence to the end of the first paragraph. I am including some
> additional language that does address some of your concern that was
> already in the spec:
> 
> <text>
> 4.5.3.  Retransmissions
> 
>    The CAPWAP control protocol operates as a reliable transport.
>    For each Request message, a Response message is defined, which is
>    used to acknowledge receipt of the Request message.  In addition,
>    the control header Sequence Number field is used to pair the
>    Request and Response messages (see Section 4.5.1).  This
>    Request/Response pair, combined with the Sequence Number, implies
>    that both the WTP and the AC can only have a single request
>    outstanding at any given time.

Hmm... it doesn't really *imply* it. For example, IKEv2 has almost
identical approach -- request/response pairs, sequence number, same
way of doing retransmissions -- but does allow multiple outstanding
requests (in some circumstances).

Also, the definition of the Sequence Number field (4.5.1.2) says that
"counter is monotonically incremented, ensuring that no two pending
Request messages have the same Sequence Number" -- this sentence makes
sense only if there can be more than one pending request.

>    Response messages are not explicitly acknowledged, therefore if a
>    Response message is not received, the original Request message is
>    retransmitted.  Implementations MAY cache Response messages to
>    respond to a retransmitted Request messages with minimal local
>    processing.  

It isn't quite clear what the alternative to this "MAY" (what should
an implementation that doesn't cache the Response message do). 

The most obvious answer would be to "process the message as usual and
generate a reply", but unfortunately, that doesn't seem to work for
all messages (for example, if the WTP processes retransmissions of
Image Data Requests as normal requests, it seems the resulting image
would be wrong).

I'd suggest just making caching the Response message a MUST -- this
would be the simplest solution, both specification-wise and
implementation-wise. (A possible alternative might involve keeping a
"Last Received Sequence Number" field, and specifying how to process
the messages and generate a correct reply without really processing
the message. Or making all Request messages idempotent.  But those
seem complex.)

>    Retransmitted Request messages MUST NOT be altered
>    by the sender.  The sender MUST assume that the original Request
>    message was processed, but that the Response message was lost.

I doubt any implementation would actually follow this "MUST assume".

(E.g. if the AC is sending Image Data Requests, does it make sense to
assume the WTP really received it, and move to the next image data
block?  Or if the Station Configuration Request isn't acknowledged,
would the AC assume that station is now configured OK?)

Also, the state machine says that if you reach the MaxRetransmit count
without receiving a response, you move to DTLS Teardown state.

In theory, you could abandon a Request for other reason that reaching
the MaxRetransmit count (perhaps you changed your mind, and didn't
want to do it anyway). But then you can't know whether the recipient
received and processed it, leaving things is slightly indeterminate
state.

>    Any alterations to the original Request message MUST have a new
>    Sequence Number, and be treated as a new Request message by the
>    receiver.

Here's a suggestion based on my comments above:

   4.5.3.  Retransmissions
 
   The CAPWAP control protocol operates as a reliable transport.  For
   each Request message, a Response message is defined, which is used
   to acknowledge receipt of the Request message.  In addition, the
   control header Sequence Number field is used to pair the Request
   and Response messages (see Section 4.5.1).

   Response messages are not explicitly acknowledged, therefore if a
   Response message is not received, the original Request message is
   retransmitted.

   Implementations MUST keep track of the Sequence Number of the last
   received Request message, and MUST cache the corresponding Response
   message. If a retransmission with the same Sequence Number is
   received, the cached Response message MUST be retransmitted without
   re-processing the Request. If an older Request message (with
   smaller Sequence Number modulo 32) is received, it MUST be
   ignored. A newer Request message (with larger Sequence Number
   modulo 32) is processed as usual.

   Both the WTP and the AC can only have a single request outstanding
   at any given time. Retransmitted Request messages MUST NOT be
   altered by the sender.

   If the sender stops retransmitting a Request message before
   reaching MaxRetransmit retransmissions (which leads to transition
   to DTLS Teardown, as described in Section 2.3.1), it cannot know
   whether the recipient received and processed the Request or not.
   In most situations, the sender SHOULD NOT do this, and instead
   continue retransmitting until a Response message is received,
   or transition to DTLS Teardown occurs. However, if the
   sender does decide to continue the connection with a new or
   modified Request message, the new message MUST have a new Sequence
   Number, and be treated as a new Request message by the receiver.
 
Best regards,
Pasi