Subject: RE: [Capwap] Proposed Resolution to Issue 45 -Issueoncombiningmessages

From: "Saravanan Govindan" <[email-masked]>
Date: Thu, 4 May 2006 11:18:01 +0800

Hi Dorothy,

I suggest that the Echo Request MAY only be send in the absence of
specifically Statistics control packets as opposed to any control
packets. The reason for this is that Statistics packets are the only
regular exchanges, so the AC has just one type of packet to monitor for
the timer. 

So I'd like to suggest the following text:

From:

"If another Echo Request or other control message is not received by the
AC when the timer expires, the AC
SHOULD consider the WTP to be unreachable"

To:

"If another Echo Request or Statistics message is not received by the AC
when the timer expires, the AC
SHOULD consider the WTP to be unreachable"

Cheers,

Saravanan

 

________________________________

From: Dorothy Stanley [mailto:[email-masked]] 
Sent: Thursday, May 04, 2006 3:03 AM
To: Pat Calhoun (pacalhou)
Cc: Scott G Kelly; Saravanan Govindan; capwap
Subject: Re: [Capwap] Proposed Resolution to Issue 45
-Issueoncombiningmessages

All,

After the lengthy discussion on this topic, I believe that the
conclusion is
still to reject the comment, and as Pat summarized, the echo remains,
does not include any
statistics, and MAY only be sent in the absence of any control packets. 

Changes to the text:

Change text in 6.2" Echo Response" from:
"If another Echo Request message is not received by the AC when the
timer expires, the AC
SHOULD consider the WTP to be unreachable" to 

"If another Echo Request or other control message is not received by the
AC when the timer expires, the AC
SHOULD consider the WTP to be unreachable" 

and from

"If the NeighborDeadInterval timer expires prior to receiving an Echo
Response message, 
message, the WTP enters the Reset State."
to
"If the NeighborDeadInterval timer expires prior to receiving an Echo
Response message, or other control
message, the WTP enters the Reset State."

Thanks,

Dorothy

Issue 45, Issue on Combining messages currently has the following
discussion in the issues database: 

Currently, the keepalive and statistics messages are separated. Separate

messages for keepalive signaling and statistics can lead to high
overhead. 

Initial analysis have shown that these overhead can be reduced
significantly 

if the messages can be combined.

Recommendation:

To combine the keepalive and statistics message into one combined
message, 

thus reducing overhead significantly.

Discussion:

The CAPWAP protocol specification currently supports the
Echo Request Message and Echo Response Messages, which are used for
keep-alive
purposes, and do not carry message elements.

There is an IEEE 802.11 Statistics measurement element(11.7.2.1
<http://11.7.2.1/> ), and several CAPWAP statistics related
measurement elements: decryption error report, WTP descriptor, WTP radio
information, WTP reboot statistics.
There is no statistics message. 

There is no requirement on how often the statistics related measurement
elements must be reported
to the AC from the WTP, there is a Statistics timer, see 7.2.5, which is
used by the AC to indicate the
timer value to the WTP. (separate question - should the statistics timer
be made general, and indicate the
values for the other Section 12 CAPWAP timers too?  Assume that the
CAPWAP statistics timer used
to determine how often to send the 802.11 specific statistics).

It is not clear that there is a high overhead in keeping the
echo/keep-alive mechanism from
the statistics reporting. There is some benefit in keeping the echo
messages simple,
rather than complicating the processing of those messages.  It is true
that small messages (echo request, response) have high overhead.
In this case, the design choice is to accept the overhead as the cost of
simplicity in design and implementation. 

Recommended resolution: reject the comment, with the explanation in the
above paragraph

On 4/28/06, Pat Calhoun (pacalhou) < [email-masked]
<mailto:[email-masked]> > wrote:

I will summarize my thoughts here and not try to inject in the various 
threads, but I agree that the echo remains, does not include any
statistics, and MAY only be sent in the absence of any control packets.
I say MAY because an implementation could send them if it wishes, but
the receiver must take into account control packets in addition to the 
echo prior to declaring a link dead.

Pat Calhoun
CTO, Wireless Networking Business Unit
Cisco Systems

> -----Original Message-----
> From: Scott G Kelly [mailto: [email-masked]
<mailto:[email-masked]> ]
> Sent: Friday, April 21, 2006 5:52 AM
> To: Saravanan Govindan
> Cc: capwap
> Subject: Re: [Capwap] Proposed Resolution to Issue 45
> -Issueoncombiningmessages
>
> Hi Saravanan,
>
> Saravanan Govindan wrote:
> > Hi Scott,
> >
> > I think David's note does address the issue on hand.
> >
> > To formalize;
> > 
> > The exchange of control messages between a WTP and AC implicitly
> > indicates that the WTP is operational. For the purpose of protocol
> > simplicity, I suggest that we focus on statistics messages 
> alone for
> > this purpose, reason being that statistics are periodically
> exchanged.
> >
> > My concern is that by using "any" control message to indicate
> > keepalive (Echo), the AC processing will be complicated. This is 
> > because the AC will need to process each control message
> for both its own value (e.g.
> > Configure Request) and also keepalive value.
>
> Of course, complexity is a function of many factors, but 
> there is a straightforward way to implement an echo trigger
> with a flag and timer:
> when you receive a control message, unconditionally raise the flag.
> Periodically (according to your keepalive interval timer) 
> check the flag; If it's up, put it down, else send a
> keepalive. There are more complicated ways to implement, but
> this works just fine.
>
> On the AC this can easily be implemented by having the 
> fastpath raise the flag, and having the cp lower it and/or do
> whatever it is your AC does if a WTP doesn't report in a
> given echo interval (which may be nothing). Pretty basic stuff.
>
> On the WTP, implementation is similar, except that if the 
> flag is down, you send the keepalive. Again, very simple and basic.
>
> > So I suggest keeping it simple - arrival of statistics message from
> > WTP means WTP is alive.
>
> Certainly, a statistics message qualifies as a control 
> message, so I have no issues with this statement when taken
> alone. I'm concerned with the earlier suggestion that the
> echo req/reply message be discarded and replaced by the
> statistics message. 
>
> In some cases, the keepalive interval must be *very* brief in
> order to facilitate rapid link loss detection and recovery. I
> know of one vendor who routinely uses a one second interval,
> and it's conceivable that in some scenarios one might choose
> to use even less.
>
> And keep in mind that WTP and AC requirements are typically
> asymmetric in this regard: the WTP needs to react quickly 
> (maybe try to find another AC), whereas the AC simply needs
> to somehow report the event.
> While in some cases reporting might be considered urgent,
> this is not the typical (or average) case. 
>
> The granularity requirements for reporting are typically much
> coarser than those of recovery. That is, the AC may, at it's
> option, only check every 10,20,30,... seconds for WTP
> liveness, and it may very well do that via the stats message, 
> rather than the echo, since this allows echo processing to
> remain wholly in the AC fastpath.
>
> But say we eliminate the echo: what happens when, say, 500
> WTPs send stats potentially every second or less? 
>
> I think we still need the echo req/rsp.
>
> Scott
>
> >
> > Saravanan
> >
> >
> >
> >
> >
> > -----Original Message----- 
> > From: Scott G. Kelly [mailto:[email-masked]]
> > Sent: Wednesday, April 19, 2006 1:51 AM
> > To: capwap
> > Subject: RE: [Capwap] Proposed Resolution to Issue 45 
> > -Issueoncombiningmessages
> >
> > Just trying to close the loop: I think David's point (i.e.
> that echoes
> > should only be sent in the absence of other control
> traffic) is dead 
> > on, and that this effectively closes the question as to
> whether echoes
> > and stats should be combined in the same messages.
> >
> > Does anyone disagree?
> >
> > Scott
> >
> >
> > _________________________________________________________________
> > To unsubscribe or modify your subscription options, please visit:
> > http://lists.frascone.com/mailman/listinfo/capwap
> >
> > Archives: http://lists.frascone.com/pipermail/capwap
> >
> >
> _________________________________________________________________ 
> To unsubscribe or modify your subscription options, please visit:
> http://lists.frascone.com/mailman/listinfo/capwap
>
> Archives: http://lists.frascone.com/pipermail/capwap
>
_________________________________________________________________
To unsubscribe or modify your subscription options, please visit: 
http://lists.frascone.com/mailman/listinfo/capwap

Archives: http://lists.frascone.com/pipermail/capwap 

_________________________________________________________________
To unsubscribe or modify your subscription options, please visit:
http://lists.frascone.com/mailman/listinfo/capwap

Archives: http://lists.frascone.com/pipermail/capwap

---

From: "Dorothy Stanley" <[email-masked]>
Date: Thu, 4 May 2006 07:07:46 -0700

Hi Saravanan,

There is no statistics control packet defined. There is an 802.11 Statistics
message element, and we can add CAPWAP
statistics, but these statistics message elements would be carried in the
WTP Event message.

So, it sounds like your proposal is to use just Echo Request and WTP Event
Request messages? It seems that
we are already above 1 message to consider.

 Dorothy

On 5/3/06, Saravanan Govindan <[email-masked]> wrote:
> specifically Statistics control packets as opposed to any control packets.
> The reason for this is that Statistics packets are the only regular
> exchanges, so the AC has just one type of packet to monitor for the timer.
>
>
>
>  ------------------------------
>
> *From:* Dorothy Stanley [mailto:[email-masked]]
> *Sent:* Thursday, May 04, 2006 3:03 AM
>
> *To:* Pat Calhoun (pacalhou)
> *Cc:* Scott G Kelly; Saravanan Govindan; capwap
> *Subject:* Re: [Capwap] Proposed Resolution to Issue 45
> After the lengthy discussion on this topic, I believe that the conclusion
> is
> still to reject the comment, and as Pat summarized, the echo remains, does
> not include any
> "If another Echo Request message is not received by the AC when the timer
> expires, the AC
> messages for keepalive signaling and statistics can lead to high overhead.
>
> Initial analysis have shown that these overhead can be reduced significantly
>
>
>
>
>
> To combine the keepalive and statistics message into one combined message,
>
> There is an IEEE 802.11 Statistics measurement element(11.7.2.1), and
> several CAPWAP statistics related
> values for the other Section 12 CAPWAP timers too?  Assume that the CAPWAP
> statistics timer used
> On 4/28/06, *Pat Calhoun (pacalhou)* < [email-masked]> wrote:
>
> > From: Scott G Kelly [mailto: [email-masked]]