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

From: "Pat Calhoun (pacalhou)" <[email-masked]>
Date: Thu, 13 Apr 2006 06:18:22 -0700

I believe the request is for a *new* set of statistics to be sent from
the WTP to the AC. If this is the case, then a
separate issue is required that describes this request. I think I was
just as confused as Dorothy that the request
was to include the existing dot11 statistics within the echo request,
which didn't seem to make sense to me.
 
Having said that, I believe that sending an echo should not require
digging everywhere around the system to collect various
statistics, as I believe this would create overhead on the WTP. If this
is localized information, and limited in nature,
then perhaps the impact is minimal.

Pat Calhoun
CTO, Wireless Networking Business Unit
Cisco Systems

________________________________

	From: Dorothy Stanley [mailto:[email-masked]] 
	Sent: Wednesday, April 12, 2006 8:00 AM
	To: Saravanan Govindan
	Cc: capwap
	Subject: Re: [Capwap] Proposed Resolution to Issue 45 - Issue
oncombiningmessages

	Saravanan, Richard,
	
	I suggest we set aside the question of how the statistics might
be  transported for the moment - either in WTP Event Request, Echo
Request or some new
	message, and first agree on the nature/definition of the
statistics themselves. We are talking about non-802.11 specific
statistics, as the 802.11
	specific ones, or new 802.11 ones would go in 11.7.2.1:
	
	WPT buffer levels - which buffers? Concern that this would be
implementation specific
	Congestion conditions - congestion on the wireless link? On the
WTP to AC link?
	etc - needs to be specified.
	
	Richard suggests
	Network Congestion - which network, the wireless one or the WTP
to AC link. How is the level of congestion measured?
	Traffic Loading - How is this measured? Which traffic? 
	Channel Interferences - Need to specify. Concern that there is
overlap with what will be coming in .11k for radio measurement
	
	Thanks,
	
	Dorothy
	
	On 4/11/06, Saravanan Govindan
<[email-masked]> wrote: 

		Hi Dorothy,

		WTP Event Request is being positioned for
technology-specific statistics exchange (Section 2.1). So my
understanding is that WTP Event Request would be used for information
such as transmission attempts, beacon and probe counts, decryption
errors etc. 

		In addition to technology-specific information, the AC
also needs big-picture information on factors affecting the WLAN as a
whole. This would include WTP buffer levels, congestion conditions, etc.
This information is not specific to a technology but does affect the
WLAN. It is this type of statistics that I suggest the Echo Request
exchange.

		Cheers,

		Saravanan

		 

________________________________

		From: Dorothy Stanley [mailto:[email-masked]] 
		Sent: Tuesday, April 11, 2006 10:50 PM
		To: Saravanan Govindan
		Cc: capwap
		Subject: Re: [Capwap] Proposed Resolution to Issue 45 -
Issue on combiningmessages

		Saravanan, Richard, 
		
		First of all, thank you for your comments.
		
		Clearly, the WTP must have a means to provide statistics
and other relevant data to the AC..
		
		The question becomes, what specific mechanism should be
used? 
		Overloading the echo request message is one way. CAPWAP
has the WTP event request message,
		section 8.5, and already includes the decryption error
report, and can include the .11 specific
		statistics report.
		
		Why is using the WTP event report to report statistics
not sufficient? We should add other applicable CAPWAP message elements
		to be included in it.

		Thanks,
		
		Dorothy 

		On 4/10/06, Saravanan Govindan
<[email-masked]> wrote: 

		Hi Dorothy,

		I think this recommendation add substantial value to the
CAPWAP protocol. There have been discussions on the need for aggregating
statistics information from the WTP to AC. The Echo Request offers a way
for achieving this. The mechanisms for statistics exchanges - timer,
periodic exchange - are available with Echo Request. So I think it is of
value to keep Echo Request and add statistics information fields to it. 

		Cheers,

		Saravanan

		
________________________________

		From: Dorothy Stanley [mailto: [email-masked]] 
		Sent: Tuesday, April 11, 2006 1:20 AM
		To: capwap
		Subject: [Capwap] Proposed Resolution to Issue 45 -
Issue on combiningmessages

		All,
		
		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), 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
		
		Comments please.
		
		Thanks,
		
		Dorothy

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

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

---

From: "Saravanan Govindan" <[email-masked]>
Date: Thu, 13 Apr 2006 22:46:54 +0800

Pat,

I hope to help clarify any confusion. My concern is that CAPWAP does need a 
set of statistics that are indicative of the WLAN as a whole. Such 
big-picture statistics are currently not in the specifications - the current 
statistics are specific to the technology binding (802.11).

I am ok with discussing this as a separate issue.

Having said this, I think this set of general statistics does not complicate 
Echo Request exchanges. In many implementations, this information is already 
available - buffer levels, transmission failures, etc. As I mentioned 
earlier, such big-picture information provides greater visibility to the AC 
and adds value to its control operations.

Saravanan

----Original Message Follows----
From: "Pat Calhoun (pacalhou)" <[email-masked]>
To: "Dorothy Stanley" <[email-masked]>,"Saravanan Govindan" 
<[email-masked]>
CC: capwap <[email-masked]>
Subject: RE: [Capwap] Proposed Resolution to Issue 45 - 
Issueoncombiningmessages
Date: Thu, 13 Apr 2006 06:18:22 -0700

Pat Calhoun

	Saravanan, Richard,

	Richard suggests

	Thanks,

	Dorothy

		Hi Dorothy,

		Cheers,

		Saravanan

		Saravanan, Richard,

		Thanks,

		Dorothy

		Hi Dorothy,

		Cheers,

		Saravanan

		All,

		Recommendation:

		Discussion:

		Comments please.

		Thanks,

		Dorothy

_________________________________________________________________
Get an advanced look at the new version of MSN Messenger. 
http://messenger.msn.com.sg/Beta/Default.aspx