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

From: "Pat Calhoun (pacalhou)" <[email-masked]>
Date: Thu, 4 May 2006 15:54:22 -0700

But we seem to be ignoring the state machine. Keep in mind that this
scheme has to co-exist with the state machine, so a discovery received
while in the Run state is not a valid packet to reset the timer. All
other packets would.

Pat Calhoun
CTO, Wireless Networking Business Unit
Cisco Systems

> -----Original Message-----
> From: sujay [mailto:[email-masked]] 
> Sent: Thursday, May 04, 2006 5:25 AM
> To: 'Saravanan Govindan'; Pat Calhoun (pacalhou); 'Dorothy Stanley'
> Cc: 'capwap'
> Subject: RE: [Capwap] Proposed Resolution to Issue 45 
> -Issueoncombiningmessages
> 
> Saravanan,
> 
> A valid point, yet ALL control messages should be monitored 
> for which are VALID in the RUN state.
> 
> There is no reason for giving special treatment to statistics 
> messages alone.
> 
> Considering an implementation, I see no significant overhead 
> in assuming  say a Configure Request packet as a keepalive 
> packet from the peer.
> 
> Regds,
> Sujay
> 
> 
> 
> -----Original Message-----
> From: Saravanan Govindan [mailto:[email-masked]]
> Sent: Thursday, May 04, 2006 2:29 PM
> To: Pat Calhoun (pacalhou); Dorothy Stanley
> Cc: capwap
> Subject: RE: [Capwap] Proposed Resolution to Issue 45 
> -Issueoncombiningmessages
> 
> 
> Without the text below, the specifications will require an AC 
> to monitor
> the arrival of "all" control packet with respect to the 
> EchoInterval and
> NeighbourDeadInterval timers. There were concerns earlier on 
> this thread
> that this is not ideal.  
>  
>  
> Furthermore, not all control packets indicate that a WTP is alive and
> doing well. A WTP could fail, re-start and then send 
> Discovery Requests
> to an AC. This should not be construed as an indication that 
> the WTP is
> well. On the other hand, by focusing only on Statistics (WTP Event
> Request) control messages, it is unambiguous that a WTP is 
> operational. 
>  
> So the text in the specifications should reflect this by having Echo
> Requests sent in the absence of Statistics (WTP Event 
> Request) messages.
> 
>  
> Saravanan 
>  
>  
>  
> 
> 
> 
> From: Pat Calhoun (pacalhou) [mailto:[email-masked]] 
> Sent: Thursday, May 04, 2006 12:50 PM
> To: Saravanan Govindan; Dorothy Stanley
> Cc: Scott G Kelly; capwap
> Subject: RE: [Capwap] Proposed Resolution to Issue 45
> -Issueoncombiningmessages
>  
> The text you are proposing doesn't change the behavior of the 
> protocol.
> I'm not sure that it really adds anything since we are stating that an
> echo is sent if no control packets are sent. You are free to send
> periodic Statistics messages, which with the new language would not
> require any Echos to be sent.
>  
> Pat Calhoun
> CTO, Wireless Networking Business Unit
> Cisco Systems
>  
>  
> 
> 
> 
> From: Saravanan Govindan [mailto:[email-masked]] 
> Sent: Wednesday, May 03, 2006 8:18 PM
> To: Dorothy Stanley; Pat Calhoun (pacalhou)
> Cc: Scott G Kelly; capwap
> Subject: RE: [Capwap] Proposed Resolution to Issue 45
> -Issueoncombiningmessages
> Hi Dorothy,
>  
> I suggest that the Echo Request MAY only be send in the absence of
> specifically Statistics control packets as opposed to any control
> packets. The reason for this is that Statistics packets are the only
> regular exchanges, so the AC has just one type of packet to 
> monitor for
> the timer. 
>  
> So I'd like to suggest the following text:
>  
> From:
> "If another Echo Request or other control message is not 
> received by the
> AC when the timer expires, the AC
> SHOULD consider the WTP to be unreachable"
>  
> To:
> "If another Echo Request or Statistics message is not 
> received by the AC
> when the timer expires, the AC
> SHOULD consider the WTP to be unreachable"
>  
> Cheers,
> 
> Saravanan
>  
>  
>  
>  
>  
> 
> 
> 
> From: Dorothy Stanley [mailto:[email-masked]] 
> Sent: Thursday, May 04, 2006 3:03 AM
> To: Pat Calhoun (pacalhou)
> Cc: Scott G Kelly; Saravanan Govindan; capwap
> Subject: Re: [Capwap] Proposed Resolution to Issue 45
> -Issueoncombiningmessages
>  
> All,
> 
> After the lengthy discussion on this topic, I believe that the
> conclusion is
> still to reject the comment, and as Pat summarized, the echo remains,
> does not include any
> statistics, and MAY only be sent in the absence of any 
> control packets. 
> 
> Changes to the text:
> 
> Change text in 6.2" Echo Response" from:
> "If another Echo Request message is not received by the AC when the
> timer expires, the AC
> SHOULD consider the WTP to be unreachable" to 
> 
> "If another Echo Request or other control message is not 
> received by the
> AC when the timer expires, the AC
> SHOULD consider the WTP to be unreachable" 
> 
> and from
> 
> "If the NeighborDeadInterval timer expires prior to receiving an Echo
> Response message, 
> message, the WTP enters the Reset State."
> to
> "If the NeighborDeadInterval timer expires prior to receiving an Echo
> Response message, or other control
> message, the WTP enters the Reset State."
> 
> 
> Thanks,
> 
> Dorothy
> 
> 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
> On 4/28/06, Pat Calhoun (pacalhou) < [email-masked]> wrote:
> I will summarize my thoughts here and not try to inject in 
> the various 
> threads, but I agree that the echo remains, does not include any
> statistics, and MAY only be sent in the absence of any 
> control packets.
> I say MAY because an implementation could send them if it wishes, but
> the receiver must take into account control packets in 
> addition to the 
> echo prior to declaring a link dead.
> 
> Pat Calhoun
> CTO, Wireless Networking Business Unit
> Cisco Systems
> 
> 
> 
> > -----Original Message-----
> > From: Scott G Kelly [mailto: [email-masked]]
> > Sent: Friday, April 21, 2006 5:52 AM
> > To: Saravanan Govindan
> > Cc: capwap
> > Subject: Re: [Capwap] Proposed Resolution to Issue 45
> > -Issueoncombiningmessages
> >
> > Hi Saravanan,
> >
> > Saravanan Govindan wrote:
> > > Hi Scott,
> > >
> > > I think David's note does address the issue on hand.
> > >
> > > To formalize;
> > > 
> > > The exchange of control messages between a WTP and AC implicitly
> > > indicates that the WTP is operational. For the purpose of protocol
> > > simplicity, I suggest that we focus on statistics messages 
> > alone for
> > > this purpose, reason being that statistics are periodically
> > exchanged.
> > >
> > > My concern is that by using "any" control message to indicate
> > > keepalive (Echo), the AC processing will be complicated. This is 
> > > because the AC will need to process each control message
> > for both its own value (e.g.
> > > Configure Request) and also keepalive value.
> >
> > Of course, complexity is a function of many factors, but 
> > there is a straightforward way to implement an echo trigger
> > with a flag and timer:
> > when you receive a control message, unconditionally raise the flag.
> > Periodically (according to your keepalive interval timer) 
> > check the flag; If it's up, put it down, else send a
> > keepalive. There are more complicated ways to implement, but
> > this works just fine.
> >
> > On the AC this can easily be implemented by having the 
> > fastpath raise the flag, and having the cp lower it and/or do
> > whatever it is your AC does if a WTP doesn't report in a
> > given echo interval (which may be nothing). Pretty basic stuff.
> >
> > On the WTP, implementation is similar, except that if the 
> > flag is down, you send the keepalive. Again, very simple and basic.
> >
> > > So I suggest keeping it simple - arrival of statistics 
> message from
> > > WTP means WTP is alive.
> >
> > Certainly, a statistics message qualifies as a control 
> > message, so I have no issues with this statement when taken
> > alone. I'm concerned with the earlier suggestion that the
> > echo req/reply message be discarded and replaced by the
> > statistics message. 
> >
> > In some cases, the keepalive interval must be *very* brief in
> > order to facilitate rapid link loss detection and recovery. I
> > know of one vendor who routinely uses a one second interval,
> > and it's conceivable that in some scenarios one might choose
> > to use even less.
> >
> > And keep in mind that WTP and AC requirements are typically
> > asymmetric in this regard: the WTP needs to react quickly 
> > (maybe try to find another AC), whereas the AC simply needs
> > to somehow report the event.
> > While in some cases reporting might be considered urgent,
> > this is not the typical (or average) case. 
> >
> > The granularity requirements for reporting are typically much
> > coarser than those of recovery. That is, the AC may, at it's
> > option, only check every 10,20,30,... seconds for WTP
> > liveness, and it may very well do that via the stats message, 
> > rather than the echo, since this allows echo processing to
> > remain wholly in the AC fastpath.
> >
> > But say we eliminate the echo: what happens when, say, 500
> > WTPs send stats potentially every second or less? 
> >
> > I think we still need the echo req/rsp.
> >
> > Scott
> >
> > >
> > > Saravanan
> > >
> > >
> > >
> > >
> > >
> > > -----Original Message----- 
> > > From: Scott G. Kelly [mailto:[email-masked]]
> > > Sent: Wednesday, April 19, 2006 1:51 AM
> > > To: capwap
> > > Subject: RE: [Capwap] Proposed Resolution to Issue 45 
> > > -Issueoncombiningmessages
> > >
> > > Just trying to close the loop: I think David's point (i.e.
> > that echoes
> > > should only be sent in the absence of other control
> > traffic) is dead 
> > > on, and that this effectively closes the question as to
> > whether echoes
> > > and stats should be combined in the same messages.
> > >
> > > Does anyone disagree?
> > >
> > > Scott
> > >
> > >
> > > _________________________________________________________________
> > > 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
> >
> _________________________________________________________________
> 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: sujay <[email-masked]>
Date: Fri, 05 May 2006 11:52:09 +0530

Nevertheless, a discovery recvd in the run state should ideally indicate
the peer has gone down, 
Probably a reboot. It may turn out to be a faster way of detecting Nbr
Down than waiting for
Nbr dead interval.
(Of course subject to the packet being authentic)

In general, perhaps the draft should specify about "treatment of
messages when recvd in the incorrect state".
i.e should it be dropped or any action is to be taken.

Comments?

Regds,
Sujay

-----Original Message-----
From: Pat Calhoun (pacalhou) [mailto:[email-masked]] 
Sent: Friday, May 05, 2006 4:24 AM
To: sujay; Saravanan Govindan; Dorothy Stanley
Cc: capwap
Subject: RE: [Capwap] Proposed Resolution to Issue 45

Pat Calhoun

> doing well. A WTP could fail, re-start and then send Discovery 
> Requests to an AC. This should not be construed as an indication that
> the WTP is
> regular exchanges, so the AC has just one type of packet to monitor 
> for the timer.
>  
> conclusion is still to reject the comment, and as Pat summarized, the 
> echo remains, does not include any
> timer expires, the AC SHOULD consider the WTP to be unreachable" to
> 
> Response message, message, the WTP enters the Reset State."
> to
> discussion in the issues database: Currently, the keepalive and 
> statistics messages are separated. Separate
> 
> 
> 
> 
> 
> 
>  
>  
> keep-alive purposes, and do not carry message elements.
> 
> several CAPWAP statistics related measurement elements: decryption 
> error report, WTP descriptor, WTP radio
> echo/keep-alive mechanism from the statistics reporting. There is some

> benefit in keeping the echo messages simple,

> > In some cases, the keepalive interval must be *very* brief in order 
> > to facilitate rapid link loss detection and recovery. I know of one 
> > vendor who routinely uses a one second interval, and it's 
> > conceivable that in some scenarios one might choose to use even 
> > less.
> >
> > asymmetric in this regard: the WTP needs to react quickly (maybe try

> > to find another AC), whereas the AC simply needs to somehow report 
> > the event. While in some cases reporting might be considered urgent,
> > coarser than those of recovery. That is, the AC may, at it's option,

> > only check every 10,20,30,... seconds for WTP liveness, and it may 
> > very well do that via the stats message, rather than the echo, since

> > this allows echo processing to remain wholly in the AC fastpath.
> >
> > But say we eliminate the echo: what happens when, say, 500 WTPs send

> > stats potentially every second or less?
> >