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

From: "Pat Calhoun (pacalhou)" <[email-masked]>
Date: Fri, 28 Apr 2006 16:19:59 -0700

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

---

From: "David T. Perkins" <[email-masked]>
Date: Fri, 28 Apr 2006 17:14:21 -0700 (PDT)

HI

I'm having some problems understanding the "MAY only", which
seems much more restrictive than needs be.

Are you saying that an AC or WTP can only seen an ECHO
request when it hasn't seen any control traffic after
X amount of time?

For example, if an AC sends, say, a config update request,
then it cannot send an echo request before X
ammount of time has elapsed?

> CTO, Wireless Networking Business Unit

Regards,
/david t. perkins