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

From: "Bob O'Hara (boohara)" <[email-masked]>
Date: Thu, 11 May 2006 17:34:42 -0700

Michael, 

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

 -Bob
 
-----Original Message-----
From: [email-masked] [mailto:[email-masked]]

Sent: Wednesday, May 10, 2006 12:50 PM
To: [email-masked]; Pat Calhoun (pacalhou); [email-masked]
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:[email-masked]] 
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:[email-masked]]
>> >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
_________________________________________________________________
To unsubscribe or modify your subscription options, please visit:
http://lists.frascone.com/mailman/listinfo/capwap

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

---

From: <[email-masked]>
Date: Mon, 15 May 2006 07:55:26 -0700

Hi Bob,

Are we intending to fully support wireless connection from WTP to AC
with a variety of wireless media? If so the QoS issue is broader, and
would include...

- remarking/re-acquiring QoS reservations at L2 on that "backhaul" link
- elevated priority and transmission order for management frames
- link aggregation 

For example it's likely the "backhaul" will need to "dis-aggregate" from
the STA and "re-aggregate" upstream if we are talking about a general
solution that would support .11n capabilities, or two radios.

Best Regards,
Michael

-----Original Message-----
From: ext Bob O'Hara (boohara) [mailto:[email-masked]] 
Sent: Thursday, May 11, 2006 5:35 PM
To: [email-masked]
Subject: RE: RE: [Capwap] to mux or not to mux?

Michael, 

 -Bob
 
-----Original Message-----

Colleagues,

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

Best Regards,
Michael

-----Original Message-----
From: ext Scott G. Kelly [mailto:[email-masked]]
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,

Scott