Capwap Mailing List: Re: Recap of current pending issues

[Pat Calhoun (pacalhou) (pcalhoun]

Thanks Pasi, that was very useful. You did not cover all of the cases in
the existing section, so I presume you were only providing text to cover
the issues you had. With this assumption in mind, the new section looks
like:

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

   After transmitting a Request message, the RetransmitInterval (see
   Section 4.7) timer and MaxRetransmit (see Section 4.8) variable are
   used to determine if the original Request message needs to be
   retransmitted.  The RetransmitInterval timer is used the first time
   the Request is retransmitted.  The timer is then doubled every
   subsequent time the same Request message is retransmitted, up to
   MaxRetransmit but no more than half the EchoInterval timer (see
   Section 4.7.7).  Response messages are not subject to these timers.

   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.

   When a Request message is retransmitted, it MUST be re-encrypted via
   the DTLS stack.  If the peer had received the Request message, and
   the corresponding Response message was lost, it is necessary to
   ensure that retransmitted Request messages are not identified as
   replays by the DTLS stack.  Similarly, any cached Response messages
   that are retransmitted as a result of receiving a retransmitted
   Request message MUST be re-encrypted via DTLS.

   Duplicate Response messages, identified by the Sequence Number field
   in the CAPWAP control message header, SHOULD be discarded upon
   receipt.
</new section>

PatC 

-----Original Message-----
From: Pasi.Eronen [at] nokia.com [mailto:Pasi.Eronen [at] nokia.com] 
Sent: Tuesday, August 19, 2008 2:30 AM
To: Pat Calhoun (pacalhou); capwap [at] frascone.com
Subject: RE: Recap of current pending issues

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