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

From: "Richard Gwee" <[email-masked]>
Date: Wed, 12 Apr 2006 10:10:12 +0800

Hi Dorothy,

Thanks for the email. I will like to propose the following message
elements 

 0 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26
27 28 29 30 31

+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-
+-+-+-+-+-+-+

| Network Congestion                        |  Traffic Loading
|

+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-
+-+-+-+-+-+-+

| Channel interferences                      |

+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

As mentioned before, these message elements can be loaded onto the Echo
messages.

Regards

Richard  

________________________________

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

Hello Richard,

Is the statistics message element that the
presentation refers to a new message element, or one/part of one that is
already defined?

- The CAPWAP Protocol needs regular Statistics exchange
- Statistics should be applicable to the overall network, e.g.
congestion, traffic loading,channel interferences
-Size of statistics element  4-8 bytes

If it is a new message element, then we need to agree on the
contents of that element, and then the means of its transport.

Thanks,

Dorothy

On 4/10/06, Richard Gwee <[email-masked]> wrote:

Hi Dorothy,

I believe that I have mentioned this point during my presentation in the
last IETF meeting. While combining messages does reduce overhead
significantly (as shown in my powerpoint presentation slides), we should
also look at another benefit of combining the keepalive and statistics
messages. As I have highlighted before, there is no statistics for the
whole WLAN in the CAPWAP protocol. We need to include this in and I feel
that putting this statistics element in the Echo Request message is the
best bet. While I understand your concern for keeping the echo messages
simple, I cannot visualize how much more complicated it can be if we
just combine statistics for our keepalive mechanism.

Appreciate any comments.

Thanks & Regards

Richard Gwee

________________________________

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

________________________________

Republic Polytechnic, 9 Woodlands Avenue 9, Singapore 738964 (Near
Woodlands MRT/Interchange)
. www.rp.sg <http://www.rp.sg>  . Fax: +65 6415-1310 . 

Republic Polytechnic, the first Institute of Higher Learning to fully
adopt the Problem-Based Learning approach in Singapore, continues to
strive towards best practices and maintain excellence in service
standards with the following certifications: Singapore Innovation Class
(SIC), Singapore Quality Class (SQC), People Developer Standards and
QEHS (ISO 9001, 14001 and OHSAS 18001)

________________________________

CONFIDENTIALITY CAUTION: This message is intended only for the use of
the individual or entity to whom it is addressed and contains
information that is privileged and confidential. If you, the reader of
this message, are not the intended recipient, you should not
disseminate, distribute or copy this communication. If you have received
this communication in error, please notify us immediately by return
email and delete the original message. Thank you. 

_________________________________________________________________
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 13:59:58 +0800

Hi Dorothy,

I agree that we should decide the statistics as a first step. 

Here is my take on what the AC needs for control over the WLAN as a
whole;

1. WTP buffer levels 

- Similar to metric used in routers

- Percentage occupancy of transmit buffers

- Independent of implementation

2. Congestion conditions - Wireless segment & AC-WTP segment

- Number of transmission failures

- Percentage occupancy of transmit buffers    

The key here is to provide the AC with information that provides broader
information than what it gets from technology-specific statistics. This
gives the AC more visibility in to the WLAN. And in relation,
big-picture information helps set the framework for CAPWAP applicability
to manage any future wireless technology.

Cheers,

Saravanan

 

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

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,

 

Recommendation:

Discussion:

Comments please.

Thanks,

Dorothy