Subject: Re: [Capwap] mux redux

From: "David Melman" <[email-masked]>
Date: Tue, 16 May 2006 10:53:38 +0300

I support keeping the separation of data and control based on the
standard UDP header port, rather than adding a CAPWAP specific mux
header after the UDP header.

As already been stated, classification engines today typically support
the standard UDP header fields.  By keeping the separation of data and
control in the standard UDP header, it allows standard based
classification, and independent policy to be applied to each type of
traffic.  QoS is just one type of policy, but of course, many other
policies can be applied independently to data and control traffic.
There is definitely value in *not* making the mux CAPWAP specific.

David

-----Original Message-----
From: Scott G. Kelly [mailto:[email-masked]] 
Sent: Tuesday, May 16, 2006 1:01 AM
To: capwap
Subject: [Capwap] mux redux
Importance: Low

We've been going around in circles on this mux header discussion, and we
need to close on it. Many of us are working on implementations right
now, and we need this decided in order to to get on with it.

This is becoming tiresome, but we must reach a conclusion.

The only ones to object to using a single UDP channel here have been
Pat, Bob, and Nancy. The technical benefits of mux'ing over one UDP
channel have been clearly established, and are not in dispute. The only
arguments still standing against this approach have all been based on
the following assertions:

(1) middleboxes must be able to alter capwap QoS markings in transit

(2) these middleboxes must alter capwap data packet markings differently
than capwap control packet markings

(3) these middleboxes cannot see beyond the UDP header, and must make
their decisions based on UDP header ACLs

It seems clear that this whole QoS discussion is a red herring, because
the assertions above, taken together, are simply not accurate. While it
has been convincingly argued that control and data traffic should be
treated differently, we have yet to hear why the current QoS standards
are not up to this task. When this question is asked, it is met with
silence.

We have widely implemented standards in place for providing QoS
functionality, and these standards do not include the use of UDP header
ACLs. Rather, they include L2 and L3 packet markings. Nobody has made a
convincing argument as to why these standards fall short of our needs.
Absent persuasive arguments, contrary claims are simply not compelling.

So far, a number of us have posted to the list in support of the mux
header, and a few people who coincidentally all work together have
argued forcefully, though unconvincingly, against this approach. Of
course, ideally we are all here as independent, individual contributors,
but it nevertheless does not serve us well to ignore the realities.

I think, based on the discussion we've seen here, that we have rough
consensus, with representatives of one product approach (and vendor) not
agreeing, and representatives of various other product approaches (and
vendors) roughly agreeing. It's not unanimous, but I think we have more
yeas than nays - and I think that constitutes "rough" consensus. I think
we should note the objections, accept the mux header, and move on.

--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

---

From: Scott G Kelly <[email-masked]>
Date: Tue, 16 May 2006 05:42:54 -0700

Hi David,

> There is definitely value in *not* making the mux CAPWAP specific.

We've seen that QoS policy is properly applied using standard QoS 
markings, and not UDP headers. Can you give any explicit use cases and 
justification for other forms of differential treatment of the 
tightly-bound capwap control and data channels?

Thanks,

Scott

---

From: Chris Stradtman <[email-masked]>
Date: Tue, 16 May 2006 15:02:09 -0400

>> we should note the objections, accept the mux header, and move on.

from an service provider point of view I can think of 2 off the top of
my head.

1. A service provider may not choose to trustingly pass through the QOS
markings and may wish to rewrite the QOS markings
based on other policies internal to the service provider.
2. The service provider may wish to send the data and control channels
down different physical paths based on economic factors.

If the streams are muxed then the service provider need to have
equipment in the middle that understands the capwap protocol out of the
gate (although some gear can use explicity bitstrings and offsets into
the packet).  This is unlikely to happen and in my opinion would slow
down the adoption and implementation of the protocol in the "real world".

Chris Stradtman

Chris Stradtman