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

From: "Richard Gwee" <[email-masked]>
Date: Sun, 16 Apr 2006 23:18:30 +0800

Hi Scott and Saravanan,

Sorry that I cannot get into the discussion earlier. Please see my
comments inline.

Thanks and regards
Richard

-----Original Message-----
From: Scott G Kelly [mailto:[email-masked]] 
Sent: Sunday, April 16, 2006 9:30 PM
To: Saravanan Govindan
Cc: [email-masked]
Subject: Re: [Capwap] Proposed Resolution to Issue 45
-Issueoncombiningmessages

Hi Saravanan,

Saravanan Govindan wrote:
> 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.

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.

<Richard> 
Hi Scott, I am not sure what maths are you really asking for. Is it
queueing analysis you are referring to? I am not really clear about your
maths requirement. Appreciate if you can enlighten me on this aspect.

My simulation results mainly show a comparison between two scenarios.
The first scenario denotes a case in which I have separate statistics
messages and Echo request messages being exchanged between AC and WTP.
The second scenario denotes a case in which I have combined both
statistics and echo messages being exchanged between AC and WTP. Over a
long period of time, it is reasonable that these values should diverge
due to the reduction in overhead when the two messages are combined.
<Richard-End>

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

<Richard>
The simulation is based on a basic scenario in which I have a model of
AC connected to a model of WTP and assume no mobile terminals. I mainly
focus on the basic interaction between an AC and a WTP.
<Richard-End>

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.

<Richard>
I am a bit confused over your reasoning that the packet header savings
doesn't account for the divergence. My thinking (as well as my results
have shown) has been that if I have managed to reduce some overhead due
to packet header savings, I will definitely see a divergence.

Appreciate if you can share with me more specifically your reasoning
behind this. I am interested to know. Thanks.
<Richard-End>

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.

<Richard>
I do agree that we have to consider many factors such as processing
overhead and complexity. Unfortunately, my resources are limited. But to
be fair, there are few simulations that can really model a real
scenario. If you feel my simulation is insufficient, I will appreciate
if you can propose some scenarios for me to simulate and study or can
point me to some resources where I can gather more enlightening data.
Thanks.
<Richard-End> 

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?

<Richard>
I believe I have mentioned how my parameters are computed. I will repeat
them again.

For network congestion, we should consider the wireless aspect. The
metric to be used is frame loss at the WTP end due to channel
interference.

For traffic loading, the metric to be used is volume of data traffic in
both uplink and downlink through the WTP.

For channel interference, 802.11k is technology-specific and we should
consider general statistics independent of technologies. I will suggest
the metric to be used is number of retransmission attempts which can be
used to infer the level of channel interference.

I have not really claimed that they are the best representations as far
as I can remember. I choose them as I felt that they can be sufficiently
effective representations for my proposed parameters. I believe I have
asked for comments and I will look forward to your counterproposal if
any. I am sure that we can discuss and work this out somehow.
<Richard-End> 

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?

<Richard>
I will definitely look forward to any of your proposal regarding the
above if you have any. I believe that we can always discuss this more in
details in our working group.
<Richard-End>

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).

> Your note seems to suggests that Echo signals cannot be configured
with 
> 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

> 
> 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,
> 
> 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
> 
>>
>> 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-----
>>  >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
>>
>> _________________________________________________________________
>> Get MSN Hotmail alerts on your mobile. 
>> http://mobile.msn.com/ac.aspx?cid=uuhp_hotmail
>>
>>
> 
> _________________________________________________________________
> Get MSN Hotmail alerts on your mobile. 
> http://mobile.msn.com/ac.aspx?cid=uuhp_hotmail
> 
> 

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

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

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: Scott G Kelly <[email-masked]>
Date: Sun, 16 Apr 2006 10:57:46 -0700

Hi Richard,

This is a very difficult conversation to have in email, due to its 
complexity. I'll try to be succinct. I'm trimming much of the 
surrounding context below, as the mixed reply styles (some with '>' 
preceding reply lines, some not) is becoming really confusing. Comments 
inlined below.

> maths requirement. Appreciate if you can enlighten me on this aspect.

See response below regarding scenarios...

<trimmed...>

> due to the reduction in overhead when the two messages are combined.

To put this simply, the graph only shows bytes received. There are other 
interesting quantities relating to overhead - for example, the 
additional processing requirements this imposes under various 
conditions. You have to think about scaling on the AC side. That would 
be very difficult to account for in a simulation, and depends on the 
implementation.

> focus on the basic interaction between an AC and a WTP.

First, is this really a valid model, with no STA's connected? Adding 
STAs will increase congestion on the LAN side, and perhaps even 
contribute to dropped echo frames.

> behind this. I am interested to know. Thanks.

Your assumptions aren't clear from the graph. Here's a simple summary of 
a few ways to look at this:

Scenario 1:
echoes and stats are sent at the same intervals. The redundancy here is 
in L2, L3, L4, and capwap transport headers. In this case, combining the 
messages should produce a precisely linear result across time (e.g. 52 
bytes saved per combined message). No divergence.

Scenario 2:
echoes are sent more frequently than stats. Combining these may be worse 
if your echo interval is much shorter than your stats interval, because 
now you're sending way more stats than you would have been otherwise, 
for a net loss in efficiency (convergence with crossover, followed by 
negative divergence).

Scenario 3:
stats are sent more frequently than echos. Combining these may better in 
some scenarios (looking only at bits on the wire), but this seems like 
an unrealistic approach. Assuming you really would want to do this, 
you'd get divergence with crossover.

What assumptions did you make in your simulation? It is not clear from 
the graph. The only thing I think is clear is that it could not have 
been scenario 1, because this would clearly yield a linear result (i.e. 
parallel lines with no divergence).

> scenario. 

...which is why we shouldn't base our decision on simulation results alone.

> If you feel my simulation is insufficient, I will appreciate

Well, this may seem a bit tongue-in-cheek, but perhaps you could try 
running and measuring real traffic? Short of that, it would be nice to 
see results for all three scenarios described above.

------------------
I've trimmed the rest, because I think we're going rather far afield 
here. Dorothy Stanley suggested that we should set aside the question of 
combining these questions and first discuss what stats we are interested 
in. You have suggested a few, as has Saravan. I am in the process of 
polling folks I work with to see if anything is missing. I would suggest 
that all interested vendors do this, and that we try to close on that 
question within a day or two (say, Tuesday?)

I think a critical question we have to answer is, which of the 3 
scenarios I described above is the average case for capwap, i.e. stats 
with every echo, more echoes than stats, or more stats than echoes?

Personally, I think more echoes than stats is the most likely, but I'd 
like to hear other points of view. Only when we know the answer to that 
question can we reasonably discuss the implications of any particular 
optimization strategy.

Scott

---

From: "David T. Perkins" <[email-masked]>
Date: Sun, 16 Apr 2006 16:09:15 -0700 (PDT)

HI,

There are a few issues that seem to be over looked in
this discussion about echos.

First, in other protocols, a keep alive (which is the
primary purpose for the Echo Request/Response) is
sent only after no network traffic has been sent
and is not sent periodically as specified in CAPWAP-00.

I believe that CAPWAP-00 should be changed so that
an echo request is sent only after no traffic has
been sent or received.

Also note that CAPWAP-00 appears (but I can't really
determine) to have application level timeout and
retry for operations. That is, if no operation
confirmation is received after the configured timeout,
then the operation is retried upto a configured count.
If the retry is not successful, then the AC (and WTP)
mark the connection as down and a WTP restarts the
Discovery cycle.

So, please, let's clean up these issues, and when we do
I believe that the answer for whether or not statistics
should be piggy backed on echo responses will be very
clear.

Regards,
/david t. perkins

---

From: Philip Rakity <[email-masked]>
Date: Sun, 16 Apr 2006 23:29:46 -0700

David,

I concur.  Also, the link should NOT be timed out if traffic is  
happening on the data path even if no echo requests get though.  I am  
reminded of a frame relay test I failed (in an earlier life) where  
the link was 100% saturated and the LMI traffic got dropped.  We  
failed the test and modified the code to pass but at the 100,000 foot  
level it was totally wrong.  If bi-directional traffic was working  
THE link WAS UP.

Philip

> should be piggy backed on echo responses will be very

Philip Rakity
[email-masked]

This message is hereby marked U4EA CONFIDENTIAL, is intended only for  
the use of the individual or individuals to which it is addressed and  
shall notbe disclose or made available to any other party except with  
the prior written consent of the sender. If the reader of this  
message is not the intended recipient, you are hereby notified that  
any dissemination, distribution or copying of this message is  
strictly prohibited. If you have received this communication in  
error, please notify us immediately by replying to the sender of this  
E-Mail.

---

From: Scott G Kelly <[email-masked]>
Date: Mon, 17 Apr 2006 06:21:34 -0700

Philip Rakity wrote:
> reminded of a frame relay test I failed (in an earlier life) where  the 
> link was 100% saturated and the LMI traffic got dropped.  We  failed the 
> test and modified the code to pass but at the 100,000 foot  level it was 
> totally wrong.  If bi-directional traffic was working  THE link WAS UP.
> 
> Philip

I've been thinking about this ever since David posted. While I think 
this is sound reasoning under many conditions, I think there are reasons 
we may want to look slightly differently at things in our case. In 
particular, I don't think we can (securely) infer AC liveness based on 
the presence of data traffic.

Assume we don't have a separate statistics message (which is the case 
today): in this case there will be relatively sporadic control channel 
data after initial join and configuration traffic (802.11 associates, 
event requests), and if no STA's are associating, there will likely be 
no control (or data) traffic. Also note that in the case of local MAC, 
there will be no data channel traffic in any case.

Second, in the non-local MAC cases note that the control channel is 
authenticated, while the data channel is not. I think this means that 
under some circumstances we could be seeing what, from the perspective 
of the WTP, is data traffic (proof of AC liveness?), but in fact, is 
well-formatted garbage.

I haven't thought all the way through the implications of 'properly 
formatted' 802.11i garbage at the STA (would it dissasociate?), but if 
802.11i is terminated at the WTP, it could also be real traffic flowing 
to/from a session hijacker. Alternatively, a STA could be sending 
unidirectional (i.e. syslog) traffic, which meets the 'traffic on the 
link test'.

That is, the AC could be down, but the WTP would not know it based on 
this metric. Am I missing something here? If not, this means we can't 
use data traffic to infer AC liveness.

However, it doesn't address David's point, which I think I agree is a 
good one. We really don't need to be sending echoes if control traffic 
is present during the echo interval. And as David suggests, that answers 
the question about combining echoes and stats.

Scott

> the prior written consent of the sender. If the reader of this  message 
> is not the intended recipient, you are hereby notified that  any 
> dissemination, distribution or copying of this message is  strictly 
> prohibited. If you have received this communication in  error, please 
> notify us immediately by replying to the sender of this  E-Mail.
> 
> 
>