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

[Bob O'Hara (boohara) (boohara]

Michael, 

You make several good points.  In particular, point number three would
be very troublesome.

 -Bob
 
-----Original Message-----
From: Michael.G.Williams [at] nokia.com [mailto:Michael.G.Williams [at] 
nokia.com]

Sent: Wednesday, May 10, 2006 12:50 PM
To: scott [at] hyperthought.com; Pat Calhoun (pacalhou); capwap [at] 
frascone.com
Subject: RE: RE: [Capwap] to mux or not to mux?

Colleagues,

It seems we are wanting to take QoS seriously ;^)
Several issues to consider:

1) The QoS of the STA's packet should influence the QoS of the packet
encapsulating it
2) Any device in the path that is honoring QoS marks (as opposed to
ignoring them) or performing remarking is effectively enforcing a
security policy and a QoS policy
3) In some media, there might not be a one to one correspondence between
CAPWAP packets and mobile node packets, correct? If so, and we assign
different QoS to the encapsulating packet than is assigned to the
packet(s) within, we may cause ordering problems.

Best Regards,
Michael


-----Original Message-----
From: ext 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