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

From: "Kraus, Michael" <[email-masked]>
Date: Fri, 5 May 2006 08:35:45 -0500

I know of many enterprises who have multiple 54Mbps access points all run back
to the same switch, which have a 100Mbps uplink.  In the future, I am
anticipating multiple 802.11n access points with a single 1Gbps uplink.  For
temporary uses(conferences), I have even setup a WTP having a WAN link back to
the AC.  My point being, is that there will always be environments where
congestion will occur between the WTP and the AC.  In a perfect world, there is
no over-subscription and no congestion. 

When congestion occurs, typically you want to ensure that the data traffic is
dropped, not the control traffic.  I agree with your statement that the WTP or
AC could apply the appropriate DSCP or 802.1q marking, and I had too suggested
that earlier:  

">>  One possible method could be for the WTP to assign the CoS/DSCP 
>> values for each traffic type so the administrator would have the 
>> ability to trust the markings provided by the WTP, or later perform a 
>> DSCP-mutation.?"

However, I have not seen any mention that if we are going to pursue using a mux
header that this would be incorporated into the changes.  If this was to be

done, it would really make sense for the CAPWAP WG to make CoS/DSCP
recommendations for these values.  Vendor interoperability is somewhat hampered
from a usability perspective if you need to do different DSCP mutations based
upon which vendor WTP/AC you are using.

Thanks,
  Mike

-----Original Message-----
From: Scott G. Kelly [mailto:[email-masked]] 
Sent: Thursday, May 04, 2006 9:04 PM
To: Pat Calhoun (pacalhou); Kraus, Michael; [email-masked]
Cc: [email-masked]
Subject: RE: [Capwap] to mux or not to mux?

Please explain what problem is encountered if the same QoS policy is applied to
both control and data traffic. Also explain why any such problems cannot be

solved by having the WTP and/or AC apply appropriate DSCP or 802.1q marking.

-----Original Message-----
>From: "Pat Calhoun (pacalhou)" <[email-masked]>
>Sent: May 4, 2006 4:11 PM
>To: "Kraus, Michael" <[email-masked]>, 
>[email-masked]
>Cc: [email-masked]
>Subject: RE: [Capwap] to mux or not to mux?
>
>The point Michael makes here is the same one I was making. Nearly every 
>enterprise class system, router or switch, is capable of providing QoS 
>enforcement using simple ACLs, which rely on IP addresses and ports. 
>QoS is just one of many features that can be (and are) implemented 
>through ACLs that would be very useful to CAPWAP.
>
>The use of the MUX makes all of the deployed equipment out there no 
>longer capable of applying QoS based on control/data plane. I think 
>this is a serious issue, and justifies the need for two ports.
>
>Pat Calhoun
>CTO, Wireless Networking Business Unit
>Cisco Systems
>
> 
>
>> -----Original Message-----
>> From: Kraus, Michael [mailto:[email-masked]]
>> Sent: Thursday, May 04, 2006 8:17 AM
>> To: [email-masked]
>> Cc: [email-masked]
>> Subject: Re: [Capwap] to mux or not to mux?
>> 
>> David,
>>   
>>   Maybe I'm misinterpreting something here and may be somewhat 
>> off-topic, but often in QoS you try to classify traffic by 
>> source/destination IP/port or by some higher level interpreter (such 
>> as NBAR in the cisco world).  If the same UDP port number is being 
>> used for both control/data, how will intermediate switches/routers be 
>> able to determine what is control vs. data traffic?  This relates 
>> back to your comment below of:
>> 
>>  "So, it all comes down to whether or not we want intermediate 
>> network devices to distinguish between control and data."
>> 
>>  One possible method could be for the WTP to assign the CoS/DSCP 
>> values for each traffic type so the administrator would have the 
>> ability to trust the markings provided by the WTP, or later perform a 
>> DSCP-mutation.
>> 
>>   I don't pretend to be a QoS expert, and I'm sure many products can 
>> classify traffic by data outside of known IP/UDP headers.  However, I 
>> would argue that this would likely be platform dependent.  For 
>> example, Cisco could create a PDLM for NBAR for these mux values.  
>> But, obviously this support does not exist today, and NBAR is 
>> dependent upon firmware/hardware support.
>> 
>>   We probably need a "neutral" person on this topic to summarize the 
>> Pros/Cons that have been already stated on this issue...
>> 
>> 
>>   Thanks,
>>      Mike
>> 
>> ------------------------------
>> 
>> Message: 2
>> Date: Thu, 4 May 2006 07:19:53 -0700 (PDT)
>> From: "David T. Perkins" <[email-masked]>
>> Subject: Re: [Capwap] to mux or not to mux?
>> To: "Kraus, Michael" <[email-masked]>
>> Cc: [email-masked]
>> Message-ID:
>> 	<[email-masked]>
>> Content-Type: TEXT/PLAIN; charset=US-ASCII
>> 
>> HI,
>> 
>> Since UDP is being used, why cannot the data traffic packets be 
>> marked with a different QoS values than control traffic packets.
>> 
>> Would you explain and provide an example of use of "current QoS 
>> tools".
>> 
>> Regards,
>> /david t. perkins
>> 
>> On Thu, 4 May 2006, Kraus, Michael wrote:
>> > One additional upside to using separate ports would be that
>> different
>> > QoS
>> 
>> > policies can be applied against data/control data.  With
>> mux values,
>> > this
>> 
>> would
>> > be more difficult to accomplish with current QoS tools.  
>> With 802.11n
>> > data
>> rates
>> > being quoted, having the ability to do some "control plane
>> policing" 
>> > for the APs, might be advantageous.
>> > 
>> > 
>> ---------------------------------------------------------------------
>> -
>> > 
>> > Message: 1
>> > Date: Wed, 3 May 2006 15:16:21 -0700 (PDT)
>> > From: "David T. Perkins" <[email-masked]>
>> > Subject: Re: [Capwap] to mux or not to mux?
>> > To: Charles Clancy <[email-masked]>
>> > Cc: capwap <[email-masked]>
>> > Message-ID:
>> > 	<[email-masked]>
>> > Content-Type: TEXT/PLAIN; charset=US-ASCII
>> > 
>> > HI,
>> > 
>> > Please don't forget about the discovery message. With it,
>> you have 3
>> > values
>> for
>> > MUX. See below..
>> > 
>> > Also, please note that in the prototype that I'm
>> developing, I'm using
>> > the UNMODIFIED DTLS implementation in openSSL.
>> > That is, adding the MUX header does not require any modification of 
>> > the
>> openSSL.
>> > By the way,my two wishes are:
>> > 1) an Ethereal decode for the below
>> > 2) the addition of the NULL encryption type to the
>> >    CAPWAP protocol for debugging
>> > 
>> > On Wed, 3 May 2006, Charles Clancy wrote:
>> > > The DTLS tunnels would NOT be merged.  You'd have something like:
>> > 
>> > +---------+------------+------------------------
>> > | UDP hdr | MUX = 0x00 |  Discovery Request or Response
>> > +---------+------------+-----------
>> > 
>> > 
>> > > +---------+------------+------------------------
>> > > | UDP hdr | MUX = 0x01 |  DTLS(CAPWAP Control)
>> > > +---------+------------+-----------
>> > >
>> > > or
>> > >
>> > > +---------+------------+------------------------
>> > > | UDP hdr | MUX = 0x02 |  CAPWAP Data
>> > > +---------+------------+-----------
>> > >
>> > > UDP is indeed a MUX header, but it's a MUX header that everything 
>> > > already understands.  So, it all comes down to whether or not we 
>> > > want intermediate network devices to distinguish between
>> control and data.
>> > > For NAT traversal, it's easier if the NAT treats everything the 
>> > > same, and doesn't have to know that the two ports are
>> related.  Same
>> > > for firewall / port forwarding.  I think intermediate network 
>> > > devices should treat everything as "CAPWAP", and we
>> should therefore do our own MUX.
>> > >
>> > > --
>> > > t. charles clancy, ph.d.  |  [email-masked]  |
>> www.cs.umd.edu/~clancy
>> > >
>> > > Nancy Winget (ncamwing) wrote:
>> > > > Charles,
>> > > >
>> > > > With a MUX, yes they are logical channels, but I believe the 
>> > > > implication is that these channels are merged into a
>> single DTLS
>> > > > tunnel...are you saying they are not?
>> > > >
>> > > > But as you state, if UDP is a MUX header, why the need to 
>> > > > introduce yet another one instead of just using UDP for
>> separation?
>> > > >
>> > > > 	Nancy.
>> > > >
>> 
>_________________________________________________________________
>To unsubscribe or modify your subscription options, please visit:
>http://lists.frascone.com/mailman/listinfo/capwap
>
>Archives: http://lists.frascone.com/pipermail/capwap

The information transmitted (including attachments) is covered by the Electronic Communications Privacy Act, 18 U.S.C. 2510-2521, is intended only for the person(s) or entity/entities to which it is addressed and may contain confidential and/or privileged material.  Any review, retransmission, dissemination or other use of, or taking of any action in reliance upon, this information by persons or entities other than the intended recipient(s) is prohibited.  If you received this in error, please contact the sender and delete the material from any computer.
_________________________________________________________________
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:27:26 -0700

> upon which vendor WTP/AC you are using.

I thought the draft did make CoS DSCP recommendations for the control
channel. From Section 4.3.3.  Quality of Service.

   802.1P:  The precedence value of 7 SHOULD be used.

   DSCP:  The DSCP tag value of 46 SHOULD be used.

so if we use the MUX header, and also specify these DSCP/802.1P
values, then is there still any QoS related benefit in breaking up the
control and data channels into two different ports?

Thanks,
Puneet