Subject: RE: [Capwap] to mux or not to mux?

From: "Pat Calhoun (pacalhou)" <[email-masked]>
Date: Fri, 5 May 2006 07:15:30 -0700

> - there will certainly be issues with NAT traversal; you now 
> need to run keepalives over two channels, and even at that, 
> the behavior will not be deterministic; busy NAT devices 
> throw out existing dgram sessions when they need the 
> resources, and this will result in one channel up, and one down; 

If the NAT behaves this way, it can happen even with a single UDP port,
so we can't win here. I agree that we will need some form of keepalive
on the data channel, and that's the cost of solving this problem.

> 
> - channel binding is ambiguous; it is not clear what data 
> channel goes with what control channel unless we add explicit 
> signalling, and this adds considerable complexity to the protocol.

There is a clear binding, which is the BSSID (or equivalent terminology
for other wireless technologies).

> 
> - all of the added corner and race conditions and error 
> handling requirements add *significant* complexity to the 
> state machines in both ends of the connection. That's bad.

I think you are overstating the complexity of the issue here.

> 
> And all of this for what? I've heard some nebulous concerns 
> about QoS, but nobody is offering a detailed and persuasive 
> explanation of why all this added complexity is warranted. 
> Please explain exactly what architectures are being 
> precluded, and why this represents a loss that justifies the 
> added effort the dual-port (actually, tri-port, as discover 
> will require it's own port too) path requires.

I believe I have made my case about QoS. Perhaps you are not satisfied
with the fact that there are millions of Ethernet and routed ports in
the world that have specific capabilities that operate at the UDP port
level that we do not get to leverage by creating this multiplexed
header. However, it is reality, and something that I truly believe we
need to take advantage of. 

Assume a NAT, where a WAN router exists which provides QoS capabilities.
Let's also assume that the WAN router has to handle much more than just
CAPWAP data. By multiplexing the data, we are eliminating the
possibility for the WAN router to apply the necessary policies to
minimize congestion over the link, while ensuring that the CAPWAP
control session stays up.

Pat Calhoun
CTO, Wireless Networking Business Unit
Cisco Systems

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

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

---

From: Puneet <[email-masked]>
Date: Fri, 5 May 2006 09:43:34 -0700

> for other wireless technologies).

I am not sure I understand: Does every control message also contain
the BSSID? If not, then how is BSSID the binding between the control
and data messages? With a single port approach all traffic on that
<src_ip,src_port,dst_ip,dst_port> is one bound channel.

> need to take advantage of.

I thought the DSCP/ToS values in the IP header was the standard way to
do QoS (and the 802.1p priorities), not based on UDP port numbers.
WiFi WMM tests for example dont map wired traffic to wireless access
categories depending on what UDP port number that traffic came on,
they use DSCP/802.1p.

> control session stays up.

So the WAN router looks at the DSCP values of the packets, and
provides better service to the CAPWAP control frames. In fact this
should work without any configuration on a networking device that
honors DSCP/ToS bits. With the UDP port QoS proposal every device
between the AC and the WTP would have to be configured to understand
that there are two port numbers here and one of them is of higher
priority than the other.

Thanks,
Puneet