Capwap Mailing List: RE: to mux or not to mux?

[Bob O'Hara (boohara) (boohara]

Philip,

NAT would certainly introduce a complication.  But, expecting QoS to be
maintained over the general internet without an SLA from your service
provider is a bit of pie in the sky, today.

 -Bob
 
-----Original Message-----
From: Philip Rakity [mailto:philip.rakity [at] u4eatech.com] 
Sent: Wednesday, May 10, 2006 5:08 PM
To: Bob O'Hara (boohara)
Cc: capwap
Subject: Re: [Capwap] to mux or not to mux?


Bob,

Good summary.

One point I am a little confused about is how NAT is handled when we  
use different ports etc.  I would have thought that the devices a  
long the way would need to be changed to handle this.  Another ALG.   
Did I miss understand something?

regards,

Philip

On May 10, 2006, at 2:10 PM, Bob O'Hara (boohara) wrote:

>
>
> The issue is that the AC is not generally the edge device, i.e., the
> first device that encounters a packet sent from the WTP.  We are not
> mandating (and, in fact, cannot mandate) that the AC live in the  
> wiring
> closet and connect directly to the WTPs.  Therefore, the packets from
> the WTPs pass through an arbitrary number of layer 2 and layer 3  
> devices
> before arriving at the AC.
>
> It is at one or more, possibly every one, of these existing  
> intermediate
> devices that the QoS ACLs are currently applied.  By hiding the
> distinction between data and control inside the mux header, we
> immediately prevent all of those existing devices from applying QoS to
> the CAPWAP protocol control and data transmissions, differentially.
>
> As has been pointed out in previous postings, there are valid reasons
> for desiring to apply this differential QoS to control and data.  The
> mux header prevents this and therefore is not a viable solution for
> CAPWAP.  If we persist on this path, we will wind up with a protocol
> that will find little acceptance.
>
>  -Bob
>
> -----Original Message-----
> From: Scott G. Kelly [mailto:s.kelly [at] ix.netcom.com]
> Sent: Wednesday, May 10, 2006 12:38 PM
> To: Pat Calhoun (pacalhou); capwap
> Subject: RE: RE: [Capwap] to mux or not to mux?
>
> Hi Pat,
>
>>> From: Scott G. Kelly [mailto:s.kelly [at] ix.netcom.com]
>>>> Currently deployed Internet gear uses these standardized
>>> techniques to implement QoS, and we've heard no compelling
>>> arguments as to why these standards are insufficient for our
> purposes.
>>
>> I disagree with your assessment, and don't believe we have rough
>> consensus.
>>
>> A packet is received by the AP. The AP will have to mark the outer
>> header to replicate the inner header. The AP doesn't have all of the
>> complex QoS policies that are required to determine how to deal with
> the
>> packet - so the best it can do is replication. The edge device will
> have
>> to police, and optionally remark. It may have a separate set of
> policies
>> for data vs. control, because the admin knows that control is more
>> important.
>>
>> I honestly don't see how the edge device does this job without  
>> knowing
>> the difference between a data packet and a control packet.
>
> Actually, I don't agree that the WTP can't enforce QoS policies -  
> that's
> an implementation choice, but it's also beside the point.
>
> Your earlier arguments seemed to indicate that intermediate devices  
> need
> the UDP header to apply some sort of "QoS ACLs". We saw in  
> discussion on
> this list that this is not the case.
>
> This current comment suggests that some "edge device" may need to
> re-mark packets.  Since these packets are tunneled to the AC, the AC
> must be the edge device we're talking about here, and if this is true,
> I'm not understanding is why the AC can't look at a mux header to make
> the decision. Modern NPUs can easily scan 64 bytes into the packet,  
> and
> many can go as far as you like.
>
> Are you saying your hardware has some limitation which precludes this?
>
> 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
>

Philip Rakity
prakity [at] u4eatech.com


This message is hereby marked U4EA CONFIDENTIAL, is intended only for  
the use of the individual or individuals to which it is addressed and  
shall notbe disclose or made available to any other party except with  
the prior written consent of the sender. If the reader of this  
message is not the intended recipient, you are hereby notified that  
any dissemination, distribution or copying of this message is  
strictly prohibited. If you have received this communication in  
error, please notify us immediately by replying to the sender of this  
E-Mail.