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

From: "Scott G. Kelly" <[email-masked]>
Date: Thu, 13 Apr 2006 09:20:26 -0700 (GMT-07:00)

I agree heartily with Pat. Implementers know that one implicit purpose of the echo req/reply is to facilite fast recovery in case of a lost capwap "connection". Hence, these may be sent *very* frequently, e.g. the interval may even be as small as 1 second (or even less!)

An echo request may be automagically turned around by the AC in the fastpath (without bothering the control processor), but if you add stats to this message, that is no longer the case. The WTP will have to run around and collect everything to assemble the messages, and the AC will have to punt these to the control processor. This does not sound like a scalable design.

-----Original Message-----
>From: Saravanan Govindan <[email-masked]>
>Sent: Apr 13, 2006 7:46 AM
>To: [email-masked], [email-masked], [email-masked]
>Cc: [email-masked]
>Subject: RE: [Capwap] Proposed Resolution to Issue 45 -	Issueoncombiningmessages
>
>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
>
>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
>
>_________________________________________________________________
>Get an advanced look at the new version of MSN Messenger. 
>http://messenger.msn.com.sg/Beta/Default.aspx
>
>_________________________________________________________________
>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: "Saravanan Govindan" <[email-masked]>
Date: Sun, 16 Apr 2006 08:07:46 +0800

Scott,

I understand your concerns regarding Echo Request. However, I believe using 
Echo Requests as a transport offers advantages that exceed your stated 
concerns below.

We've seen substantial overhead reduction in exchanging statistics with Echo 
Request. This alone should be enough to for its inclusion in CAPWAP.

Furthermore, there are implementations currently available that indeed use 
Echo Requests to exchange some sort of information between APs and AC.

Saravanan

----Original Message Follows----
From: "Scott G. Kelly" <[email-masked]>
Reply-To: "Scott G. Kelly" <[email-masked]>
To: [email-masked], 
[email-masked],[email-masked]
CC: [email-masked]
Subject: RE: [Capwap] Proposed Resolution to Issue 45 
-Issueoncombiningmessages
Date: Thu, 13 Apr 2006 09:20:26 -0700 (GMT-07:00)

I agree heartily with Pat. Implementers know that one implicit purpose of 
the echo req/reply is to facilite fast recovery in case of a lost capwap 
"connection". Hence, these may be sent *very* frequently, e.g. the interval 
may even be as small as 1 second (or even less!)

An echo request may be automagically turned around by the AC in the fastpath 
(without bothering the control processor), but if you add stats to this 
message, that is no longer the case. The WTP will have to run around and 
collect everything to assemble the messages, and the AC will have to punt 
these to the control processor. This does not sound like a scalable design.

-----Original Message-----

_________________________________________________________________
Get MSN Hotmail alerts on your mobile. 
http://mobile.msn.com/ac.aspx?cid=uuhp_hotmail

---

From: Scott G Kelly <[email-masked]>
Date: Sat, 15 Apr 2006 18:16:39 -0700

Hi Saravanan,

Saravanan Govindan wrote:
> Scott,
> 
> I understand your concerns regarding Echo Request. However, I believe 
> using Echo Requests as a transport offers advantages that exceed your 
> stated concerns below.

Show me the arithmetic.

> We've seen substantial overhead reduction in exchanging statistics with 
> Echo Request. This alone should be enough to for its inclusion in CAPWAP.

Again, show me the arithmetic. Along with the bandwidth savings, include 
the WTP processor overhead involved with gathering the stats 
(potentially every second) and the AC fastpath-to-cp overhead this 
incurs. I don't recall seeing this demonstrated on this list.

And exactly what statistics are we talking about here? As far as I can 
tell, these statistics remain largely undefined, aside from a few 
suggestions. Until (and unless) they are fully specified, these 
arguments cannot be fully evaluated.

> Furthermore, there are implementations currently available that indeed 
> use Echo Requests to exchange some sort of information between APs and AC.

This is irrelevant. Existence is not a technical justification.

The purpose of echo requests (as they have been defined thus far) is to 
detect a dead peer. One of the primary reasons for this detection is to 
enable rapid recovery (e.g. AC failover). That implies that echo 
requests may be sent *very* frequently, as I said below.

If you want to make a convincing argument, please show us the math and 
other arguments that demonstrate we really want to send stats as 
frequently as we send dead peer detection probes (echo requests), and 
that there is a compelling justification for combining these (and 
forcing the echo requests of hundreds of (or more) WTPs to be punted to 
the control processor every name-yer-favorite-interval seconds)

Scott

> I agree heartily with Pat. Implementers know that one implicit purpose 
> of the echo req/reply is to facilite fast recovery in case of a lost 
> capwap "connection". Hence, these may be sent *very* frequently, e.g. 
> the interval may even be as small as 1 second (or even less!)
> 
> An echo request may be automagically turned around by the AC in the 
> fastpath (without bothering the control processor), but if you add stats 
> to this message, that is no longer the case. The WTP will have to run 
> around and collect everything to assemble the messages, and the AC will 
> have to punt these to the control processor. This does not sound like a 
> scalable design.
>

---

From: "Saravanan Govindan" <[email-masked]>
Date: Sun, 16 Apr 2006 14:41:42 +0800

Hi Scott,

I'll point you to the presentation Richard made during the meeting in 
Dallas. The slide on peformance results clearly shows the math you are 
looking for - exchanging statistics through Echo Request substantially 
reduces overhead.

Your note seems to suggests that Echo signals cannot be configured with 
statistics. This is not the case.

Saravanan

----Original Message Follows----
From: Scott G Kelly <[email-masked]>
To: Saravanan Govindan <[email-masked]>
CC: [email-masked]
Subject: Re: [Capwap] Proposed Resolution to Issue 45 
-Issueoncombiningmessages
Date: Sat, 15 Apr 2006 18:16:39 -0700

Hi Saravanan,

Show me the arithmetic.

>Echo Request. This alone should be enough to for its inclusion in CAPWAP.

Again, show me the arithmetic. Along with the bandwidth savings, include the 
WTP processor overhead involved with gathering the stats (potentially every 
second) and the AC fastpath-to-cp overhead this incurs. I don't recall 
seeing this demonstrated on this list.

And exactly what statistics are we talking about here? As far as I can tell, 
these statistics remain largely undefined, aside from a few suggestions. 
Until (and unless) they are fully specified, these arguments cannot be fully 
evaluated.

The purpose of echo requests (as they have been defined thus far) is to 
detect a dead peer. One of the primary reasons for this detection is to 
enable rapid recovery (e.g. AC failover). That implies that echo requests 
may be sent *very* frequently, as I said below.

If you want to make a convincing argument, please show us the math and other 
arguments that demonstrate we really want to send stats as frequently as we 
send dead peer detection probes (echo requests), and that there is a 
compelling justification for combining these (and forcing the echo requests 
of hundreds of (or more) WTPs to be punted to the control processor every 
name-yer-favorite-interval seconds)

Scott

>fastpath (without bothering the control processor), but if you add stats to 
>this message, that is no longer the case. The WTP will have to run around 
>and collect everything to assemble the messages, and the AC will have to 
>punt these to the control processor. This does not sound like a scalable 
>design.
>

---

From: Scott G Kelly <[email-masked]>
Date: Sun, 16 Apr 2006 06:29:38 -0700

Hi Saravanan,

> looking for - exchanging statistics through Echo Request substantially 

I saw Richard's presentation (and I just reviewed it again in the
proceedings), but it doesn't actually do the math I asked for. Instead, 
it presents a graph that shows two diverging lines, and makes no attempt 
to explain what is being measured, or why it is reasonable to expect 
that these values should diverge over time when plotted linearly.

An important point: this plot is the result of a simulation. What are 
the assumptions upon which that simulation is based?

I think it probably looks at packet header savings when you eliminate 
the separate transport headers (which, incidentally, assumes you want to 
send these statistics at the same interval you want to send echoes), but 
that doesn't account for the divergence. Maybe Richard can enlighten us 
a bit here.

It also seems to assume a perfect processing world - that is, it ignores 
the increased processing overhead and complexity at either end when you 
combine these. And based on Richard's accompanying comments, it also 
seems to assume a very small statistics payload. As an aside, I think 
real-world network trace data would be far more enlightening.

As a practical matter, there are more than a few questions I have about 
this. For example, Richard's presentation the size of a statistics 
element is 4-8 bytes. What are the contents of these 4-8 bytes?

One of Richard's emails to the list says the element should look like this:

+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-\
| Network Congestion                    |  Traffic Loading
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-\
| Channel interferences             |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

(sorry, but it was apparently posted in html, and didn't render well 
when I cut-pasted it)

This is indeed compact (6 bytes?), but what is the meaning of these 
values (how are they computed), why is this the best representation for 
those quantities, and why are these the only relevant statistics?

Dorothy Stanley pointed out that we are also interested in transmission 
attempts, beacon and probe counts, decryption errors, and other things. 
Where will those values go?

I think (and I believe Dorothy already suggested this) that we need a 
comprehensive enumeration of all relevant statistics, along with some 
estimation of the appropriate reporting interval(s).

> statistics. This is not the case.

I didn't mean to say it can't be done. Of course it can, but that 
doesn't mean it's a good design choice. I think this will become more 
evident once we have an enumeration of necessary statistics and some 
idea of typical collection intervals (which, by the way, may not be 
uniform across statistics).

--Scott

>> We've seen substantial overhead reduction in exchanging statistics 
>> with Echo Request. This alone should be enough to for its inclusion in 
>> CAPWAP.
> 
> 
>> fastpath (without bothering the control processor), but if you add 
>> stats to this message, that is no longer the case. The WTP will have 
>> to run around and collect everything to assemble the messages, and the 
>> AC will have to punt these to the control processor. This does not 
>> sound like a scalable design.
>>