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

From: "Richard Gwee" <[email-masked]>
Date: Tue, 11 Apr 2006 10:27:41 +0800

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 . 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: "Dorothy Stanley" <[email-masked]>
Date: Tue, 11 Apr 2006 08:21:33 -0700

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:
> 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,
>
> 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,
>
> values for the other Section 12 CAPWAP timers too?  Assume that the CAPWAP
> statistics timer used
> ------------------------------
>
> . *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.
>
>