Capwap Mailing List: Re: [CAPWAP] reasonably bounding our QoS ambitions for the base protocol

[Bob O'Hara (boohara) (boohara]

Scott, 

Perhaps separating the topics is a reasonable thing to do.  

Addressing your points below...

1. Characterizing the "vast majority" of hotspot deployments as local
MAC is incorrect.  The vast majority of hotspots fall outside the
architectures encompassed by CAPWAP.  They are classical, stand-alone
APs without any AC, at all.  Of those hotspot deployments that are not
stand-alone APs, there is a good mix of both local-MAC and split-MAC
hotspot deployments.  

2. The fact that users of today's hotspots have no expectation of QoS is
irrelevant to the discussion

3. The problem is real, regardless of whether you believe it to be, or
not.  An actual service provider has posted several more than once on
this list, saying exactly that.  Simply claiming that their problem is
irrelevant does not make it so.

4. The WTP is only in a unique position to take the actions you cite
(throttling down user traffic) only if the problem can be detected by
the WTP.  If the traffic is dropped beyond the link outbound from the
WTP, how does it learn what packets were dropped and where?  There is no
mechanism to provide this feedback to the WTP.

5. There are many implementation-specific features, such as those you
attribute to a potential local-MAC implementation, that are possible.
But, this strands the split-Mac architecture.

6. Being unable to imagine the problem does not invalidate it.  Again, a
service provider has validated exactly this problem and provided
specific support and examples for it.  The claim is that the WTP and AC
"*know*" that data flooding is causing loss of control channel packets.
The claim that this is so, is not proof of it.  Neither the AC nor the
WTP can know why any particular packet is dropped, or even if it was
dropped.  There is no feedback mechanism in CAPWAP providing such
feedback.  All that the WTP or AC know is that an expected packet did
not arrive, causing the state machine to change states.  There is no
ability to determine why that packet did not arrive.

7. A recurring point in this discussion, not only this email, is the
increased costs and complexity of the two port approach.  This is
incorrect.  There is no additional cost or complexity to this approach
in the AC or WTP implementation, even for NAT traversal.  NAT traversal
is required for even a single port.  If it can be accomplished for a
single port, it is no more difficult or costly to do it for one or more
additional ports.  The actual cost is in requiring
change/replacement/upgrading of intermediate networking equipment to
adapt to a new protocol, while providing the same services as are
provided to other protocols.

8. You state that the "vast majority" of deployments that might expect
reliable QoS are within a single domain of control.  Would you please
state the references of this data?

Many of the arguments presented below seem to be leading to a reduction
of the market to which the full capabilities of CAPWAP would apply.  I
believe that this is not appropriate.  In particular, the hotspot will
soon have expectations of QoS that are similar to those of an
enterprise.  The growth of VOIP on WLAN will drive the QoS requirement.
Designing a protocol, now, that does not encompass this requirement is
very short sighted.

 -Bob
 
-----Original Message-----
From: Scott G. Kelly [mailto:s.kelly [at] ix.netcom.com] 
Sent: Tuesday, June 13, 2006 5:27 PM
To: Bob O'Hara (boohara); capwap
Subject: reasonably bounding our QoS ambitions for the base protocol

I wanted to limit my earlier reply to the question the thread originally
was addressing (getting the premises straight), but I also think the
response below needs more attention. I've changed the subject line to
keep the two threads distinct.

Comments inline...

-----Original Message-----
>From: "Bob O'Hara (boohara)" <boohara [at] cisco.com>
>Sent: Jun 13, 2006 11:11 AM
>To: capwap <capwap [at] frascone.com>
>Subject: Re: [Capwap] capwap transport analysis: QoS vs multiport
>
>
>
>Scott wrote:
>
>>So if the AC and WTP were to mark control packets 
>>so as to make them distinguishable from data packets 
>>(using one of the marking methods suggested above, 
>>and without relying on client truthfulness), what 
>>problems remain? 
>
>As Pat points out in a separate email, the problem of controlling how
>the WTP marks those packets remains to be solved.  But, that discussion
>can continue in Pat's thread.
>
>Another problem is that the WTP, itself, is not trusted by the network
>to which it is attached.  A widespread example is a network of WLAN
>hotspots.  The WTPs at the hotspot are connected to the AC over a third
>party's network.  
>
>In some of those hotspots, the WTP will be local-MAC.  A hotspot user's
>packets from a local-MAC WTP will be able to be inspected at ingress to
>the third party's network, since the 5-tuple is clearly available in
>those packets.  QoS can be applied to those user data packets, without
>requiring any changes to the third party's network equipment.

Currently, the vast majority (if not all) of the deployed hotspots are
local MAC, and users of those hotspots have no expectation of QoS. If
the access point requires QoS for control traffic, then it also needs it
for the 802.11 mgmt traffic that it's forwarding to the AC, and the
hotspot provider would negotiate an appropriate agreement with the ISP -
but in this case, *both* the capwap control and data channels would
require QoS. However, there is a much simpler solution (assuming this
ever becomes a real problem).

If user data *were* choking the Internet link and hence causing control
traffic starvation, the WTP is in a unique position to detect this and
defend itself by throttling down user traffic while it attempts to
re-establish its control linkage. Also, there is no requirement that a
local-MAC WTP reset just because the control channel is temporarily lost
- indeed, isn't it common (in fact, demanded by customers) today for
local MAC WTP's to switch into a restricted mode upon loss of the
control channel connection, and to maintain existing user sessions while
rejecting new ones? That is, this particular problem is already being
effectively addressed in other ways.
 
>However, if those same packets are sent to the AC by a split-MAC WTP,
>the third party network will not be able to distinguish control packets
>from data packets, unless they are sent on separate ports.  In the
>CAPWAP packet, the 5-tuple is the same for both control and data.

I'm having a really hard time with this one - forwarding user data back
to the AC in a hotspot scenario, and doing it over an untrusting (and
untrusted) 3rd party network, and expecting to provide QoS to boot? It's
hard to imagine this happening in practice, but the fact is that the
same argument applies with respect to control channel traffic, i.e. if a
flooded data channel is causing control channel starvation, the WTP or
AC *knows* this - it's immediately evident - and the WTP or AC can
throttle back the data channel flow in favor of the control channel. And
this requires no 3rd party intervention.

I'm sure that if we put our minds to it, we can dream up corner cases
which might not be addressed by a single port protocol,  but there are
other ways to solve the problems above that don't entail the complexity
and costs of the multiport approach. And as an aside, this would appear
to be one of the cases where NAT is most likely to occur, further
complicating things. 

----

I think it's important to acknowledge that none of the proposed
solutions is perfect, or will service all possible scenarios that we
might dream up. I think it's also important to realize that there are
many problems to be solved in wlan deployments, and we are not, indeed
cannot be chartered to solve each and every one of them here. We need to
solve a reasonable subset of them, and address other problems in later
efforts. 

The vast majority of real-world deployments where reliable provision of
QoS might be reasonably expected are within a single domain of control,
and those that are not present very challenging problems - problems
which should not within the charter of this working group at this time,
if we are to accomplish anything useful within a meaningful time frame. 

Scott